Claude
Claude
Talk with Claude, an AI assistant from Anthropic
·claude.ai·
Claude
RFD / Oxide
RFD / Oxide
·rfd.shared.oxide.computer·
RFD / Oxide
Effects and Coeffects in Call-By-Push-Value (Extended Version) - 2311.11795v2.pdf
Effects and Coeffects in Call-By-Push-Value (Extended Version) - 2311.11795v2.pdf
Effects and Coeffects in Call-By-Push-Value
Some extensions of CBPV annotate effects on F A instead of U B . These systems isolate ef- fects so that they need not be tracked by the typing judgement. Extended Call-by-Push-Value (ECBPV) [ McDermott and Mycroft 2019 ] adds call-by-need evaluation to CBPV and layers an ef- fect system to augment equational reasoning. This system uses an operation 〈 𝜙 〉 𝐵 to extend the effect annotation to other computation types, combining effects in returner types and pushing ef- fects to the result type of functions and inside with-products. Rioux and Zdancewic [ 2020 ] tracks divergence. In this system, the sequencing operation requires that the annotation on the returner type be less than or equal to any annotation on the result of the continuation.
·arxiv.org·
Effects and Coeffects in Call-By-Push-Value (Extended Version) - 2311.11795v2.pdf
Claude
Claude
Talk with Claude, an AI assistant from Anthropic
·claude.ai·
Claude
cargo-call-stack - crates.io: Rust Package Registry
cargo-call-stack - crates.io: Rust Package Registry

Features

The tool produces the full call graph of a program as a dot file.

A start point can be specified to analyze only the call graph that begins at that function.

Each node (function) in the call graph includes the local stack usage of the function, if available (see -Z emit-stack-sizes).

The maximum stack usage of each function is also computed, or at least a lower bound is provided. Maximum stack usage of a function here refers to the stack usage that includes the stack used by functions that the function may invoke.

The tool has imperfect support for calls through function pointers (fn()) and dynamic dispatch (dyn Trait). You will get a call graph from programs that do indirect calls but it will likely be missing edges or contain incorrect edges. It's best to use this tool on programs that only do direct function calls.
Features The tool produces the full call graph of a program as a dot file. A start point can be specified to analyze only the call graph that begins at that function. Each node (function) in the call graph includes the local stack usage of the function, if available (see -Z emit-stack-sizes). The maximum stack usage of each function is also computed, or at least a lower bound is provided. Maximum stack usage of a function here refers to the stack usage that includes the stack used by functions that the function may invoke. The tool has imperfect support for calls through function pointers (fn()) and dynamic dispatch (dyn Trait). You will get a call graph from programs that do indirect calls but it will likely be missing edges or contain incorrect edges. It's best to use this tool on programs that only do direct function calls.
·crates.io·
cargo-call-stack - crates.io: Rust Package Registry
Category Theory in Programming
Category Theory in Programming

Welcome to Category Theory in Programming, a journey into the conceptual world where mathematics meets software development. This tutorial is designed for Racket programmers who are curious about the mathematical ideas underlying computational systems. It offers insights into how familiar programming concepts can be reinterpreted through the lens of category theory, and even goes further to directly borrow from category theory, using programming language constructs to describe these abstract concepts.

        In addition to this tutorial, you may find the following resources helpful for further exploration of category theory:

            Category Theory for Computing Science by Michael Barr & Charles Wells

            Computational Category Theory by D.E. Rydeheard & R.M. Burstall

            Category Theory in Context by Emily Riehl

            Category Theory by Steve Awodey

            Categories for the Working Mathematician by Saunders Mac Lane

            nLab

            TheCatsters YouTube Channel

Category theory, a branch of mathematics that deals with abstract structures and relationships, may seem esoteric at first glance. However, its principles are deeply intertwined with the concepts and patterns we encounter in programming. Through this tutorial, we aim to bridge the gap between these two worlds, offering a unique perspective that enriches the programmer’s toolkit with new ways of thinking, problem-solving, and system design.

In the following chapters, we will explore the core concepts of category theory — objects, morphisms, categories, functors, natural transformations, Yoneda Lemma, 2-categories, (co)limits, sketches, Cartesion closed categories & typed lambda, Curry–Howard–Lambek corresponding, adjunctions, (co)monads, kan-extensions, toposes, and more — and how these can be represented and utilized within the Racket programming language. The goal is not to exhaustively cover category theory or to transform you into a category theorist. Instead, we will focus on mapping these abstract concepts into programming constructs, providing a foundation that you, the reader, can build upon and apply in your work.

Why study category theory as a programmer? The answer lies in the abstraction and generalization capabilities provided by category theory. It allows us to see beyond the specifics of a particular programming language, problem, or system, revealing the underlying structures that are common across different domains. By identifying connections between a system and the constructs of category theory, you can leverage existing categorical results and structures to expand and improve the system, applying well-established theories and techniques to refine and extend your design. This tutorial aims to open the door to this broader perspective, enriching your approach to programming.

As you embark on this journey, keep in mind that the real value of understanding category theory in the context of programming is not merely in acquiring new knowledge but in developing a new way of thinking about problems or systems. We encourage you to approach the material with an open mind and to explore how the concepts presented here can be applied or extended in your programming endeavors.

Category Theory in Programming is an invitation to explore, to question, and to discover. It is a starting point for a deeper inquiry into the vast and fascinating intersection of mathematics and programming. We hope this tutorial will inspire you to delve further into both fields, exploring new ideas and forging connections that will enhance your work as a programmer.

Let the journey begin.

·docs.racket-lang.org·
Category Theory in Programming
Logical_Relations_Notes.pdf
Logical_Relations_Notes.pdf

These are lecture notes for the Logical Relations course at OPLSS 2023. The notes cover an introduction to logical relations, along with detailed examples, namely: normalization and type safety for simply-typed lambda calculus (STLC), step-indexed logical relation for recursive types, and a brief look at binary logical relations for parametric polymorphism.

·cs.uoregon.edu·
Logical_Relations_Notes.pdf
The algebra (and calculus!) of algebraic data types
The algebra (and calculus!) of algebraic data types
Just as algebra is fundamental to the whole of mathematics, algebraic data types (ADTs) are fundamental to many common functional programming languages. They’re the primitives upon which all of our richer data structures are built, including everything from sets, maps, and queues, to bloom filters and neural networks.
·codewords.recurse.com·
The algebra (and calculus!) of algebraic data types
The Flix Programming Language
The Flix Programming Language

A powerful effect-oriented programming language

Flix is a principled effect-oriented functional, imperative, and logic programming language developed at Aarhus University and by a community of open source contributors. Why effect-oriented? And why Flix?

Why Effects? Effect systems represent the next major evolution in statically typed programming languages. By explicitly modeling side effects, effect-oriented programming enforces modularity and helps program reasoning. User-defined effects and handlers allow programmers to implement their own control structures.

Why Flix? We claim that of all the upcoming effect-oriented programming languages, Flix offers the most complete language implementation, the most extensive standard library, the most detailed documentation, and the best tool support.

Moreover, Flix builds on proven programming language technology, including: algebraic data types and pattern matching, extensible records, traits, higher-kinded types, associated types and effects, structured concurrency, and more.

·flix.dev·
The Flix Programming Language
Polarized Subtyping: Code/Artifact
Polarized Subtyping: Code/Artifact
Artifact accompanying the paper Polarized Subtyping, published in the proceedings of ESOP 2022. We've included an extended version of the paper with this submission (2201.10998.pdf), which is also available directly on arXiv.  Docker Image: The artifact is packaged as a docker container. The docker image is available on Github Packages, under the esop22 tag. We've also included the docker image as a .tar file (polite-esop:esop22.docker.tar), which can be loaded directly via: % docker load polite-esop:esop22.docker.tar Source Code: All of the software, source code (the Polite programming language), and related files are packaged within the docker container (available on Github Packages and in this submission). Follow the steps below (or in README.txt), to pull the docker image, run it, and run the paper-related examples, i.e. the `.polsub` files. We've also included these files as part of this submission for posterity: bin.polsub emptyfull.polsub examples.polsub omega.polsub stream.polsub   Getting Started Guide 1. Pull down the public docker image: % docker pull ghcr.io/zeeshanlakhani/polite-esop:esop22 2. Run the docker container interactively: % docker run --rm -it --name polite-esop ghcr.io/zeeshanlakhani/polite-esop:esop22 Of note, this is a x86-64/amd64 (Intel) built container. The artifact will not run on arm64 hosts (e.g. an M1 macbook). 3. After running step 2., you'll enter into the designated `/polite/esop22` directory within the container, where there are 5 example `.polsub` files to run, associated with the paper submission. You can use the `polite` executable (already in the PATH) to view the output of each example: % polite bin.polsub % polite emptyfull.polsub % polite examples.polsub % polite omega.polsub % polite stream.polsub 4. To run examples and view purposeful typechecking errors in relation to subtyping, then run any of the examples above with the `-d` debug flag: % polite -d bin.polsub 5. Additionally, you can run the examples interactively in SML/NJ (by first running `sml`): CM.make "../src/sources.cm"; Top.polite "bin.polsub"; Top.polite "emptyfull.polsub"; Top.polite "examples.polsub"; Top.polite "omega.polsub"; Top.polite "stream.polsub"; Step by Step Instructions Now, we'll walk through each of the `polsub` programs in `/polite/esop22`, which exhibit key examples in and claims made by the paper. Throughout the example programs, `[stream0]` and `(thunk stream0)` are interchangeable, as is `y` and `return y`, where using `thunk` and `return` matches to how we express thunk values and return computations in the paper. As in the paper, our bidirectional typechecking algorithm is polarized. As is evident from the bidirectional rules, A : B, for positive types A and B, will hold exactly when `fun x = x : A - B`. Similarly, for negative types A and B, A : B is true exactly if `fun x = force x : [A] - B`. We use this in some of the examples to verify or refute some subtyping relations. 1. % polite -d examples.polsub This program demonstrates general type examples used throughout the paper, including much of what exists in Appendix A (in the extended version of the paper). Samples include: `nat` and `bool` (positive) variant records types, how `list` or `queue` datatypes would be constructed, identity functions mutually recursive `even` and `odd` datatypes, a simple, incorrect function type computation in `succ'` 2. % polite -d bin.polsub This program demonstrates our first example in Section 2.2, where we expect the subtyping relationships `pos` = `std` = `bin` to hold, as every positive standard number is a standard number, and every standard number is a binary number. The `fail` keyword showcases where subtyping is expected to fail. The precise locations of the errors are propagated when using the `-d` flag, e.g. ./esop22/bin.polsub:31.38-31.44:error:subtyping fails: std not : pos | 'b1 x2 = 'b0 x2 } `eval` evaluates computation expression, e.g. `ten`, `eleven`, etc. The `inc`, `dec0` functions match up with our claims in the paper, where `dec0` should indeed fail. Of note, the `dec` example in the first version of our paper had a typo, which we demonstrate the failure of in `dectypo`. We show the correct version with the computation `dec` and have already made the change in the available submission. 3. % polite stream.polsub This program demonstrates our second example in Section 2.2, where we have an example of a type with mixed polarities: a stream of `std` binary numbers with a finite amount of padding between consecutive numbers. As in the paper, we present padded streams as mutually dependent type definitions, one positive and one negative. `zstream` demonstrates the usefulness of variant records with one alternative `'some`. The expressions `compress` and `omit` are two mutually recursive functions used to generate a stream with zero padding from a stream of arbitrary (but finite) padding. `compress'`, `omit'` and the evaluation of `stream0'` are used here just to establish how the language implementation can interchangeably use `[a]` for `thunk a` and `b` for `return b`, where the latter of each is used in the paper, but is more cumbersome for writing programs. Evaluated expressions `stream0` and `stream1` validate how we can actuallycompress a padded stream into one with zero padding! 4. % polite omega.polsub This program demonstrates our third example in Section 2.2, where we consider the embedding of the untyped lambda calculus in a polarized setting, e.g. (U^- : [U] - U), and highlight the notion of semantic typing and how it ensures behavioral soundness. As in the paper, `omega` and `Omega` are equirecursive type definitions and well-typed even though the evaluation of `Omega` would diverge (i.e. never terminate). The commented-out `eval nontermination` showcases this and, indeed, would never terminate if actually executed. 5. % polite -d emptyfull.polsub Here we demonstrate examples in relation to our presentation of "emptiness" and "fullness" in the paper (Semantic Subtyping, Section 4.1). In this program, we showcase how to check for the emptiness and fullness of types with our implementation. For positive types, we check that a type t is empty by typechecking an identity function from t into an empty type (`ex1`, `ex3`). If typechecking the identity function from a positive type t to an empty type fails, we conclude that the type is not empty (`ex2`, `ex4`). For negative types, we can use our implementation to check when full types are supertypes of other types (`inf_sub_top`, `inf_sub_emp`) and when a type (e.g. `inf`) is not full by checking that the typechecking of an identity function from a full type fails (`top_nsub_inf`, `comp emp_nsub_inf`). The 5 programs above illustrate various examples related to our paper and show that our language implementation, Polite, works faithfully and as expected. Outside of the esop22 directory, (e.g. % cd /polite), we include all of the source code for the implementation, as well as more examples and regression tests, which include our ongoing and future work: adding intersections and unions to polarizing subtyping. The `polite.readme.txt` in the `/polite` directory also shows our language's grammar. Files (in the container) /polite/esop22/                       -- ESOP22 paper-related examples and documentation /polite/src/                               -- implementation in SML /polite/examples/                   -- some example programs, some of which include intersection and union (sub)typing /polite/tests/                           -- regression tests /polite/polite.readme.txt        -- general documentation for the Polite programming language implementation Description An implementation of the Polite programming language based on call-by-push-value, equirecursive types, subtyping, and intersection and union types.  The language version with subtyping but without intersections and unions is described in: Polarized Subtyping Zeeshan Lakhani, Ankush Das, Henry DeYoung, Andreia Mordido, Frank Pfenning European Symposium on Programming (ESOP 2022) Contributors (implementation): Zeeshan Lakhani Frank Pfenning Contributors (theory): Ankush Das Henry DeYoung Andreia Mordido
·zenodo.org·
Polarized Subtyping: Code/Artifact
[Haskell'23] The Evolution of Effects
[Haskell'23] The Evolution of Effects
The Evolution of Effects (Keynote) (Video, Haskell 2023) Nicolas Wu (Imperial College London, UK) Abstract: Functional programming has been celebrated for its promise of pure functions, delivering referential transparency and elegant reasoning about programs. However, real-world applications are not pure, and necessitate interaction with the outside world, introducing computational effects such as IO, state, and exceptions. The journey to harmonize these seemingly contradictory paradigms has led to a fascinating evolution of effectful programming in Haskell. The introduction of monads as a practical programming tool was a pivotal discovery, enabling controlled sequencing of effectful computations and addressing the challenge of handling side effects in a pure language. However, it soon became evident that the lack of modularity in composing effects using monads posed a limitation to effectful programming. To overcome this obstacle, monad transformers emerged as a solution, providing a composable manner of building effects on top of one another. More recent advancements have led to algebraic effects as an alternative framework that is easy to extend, particularly as domain-specific languages crafted to work in specific contexts. Nevertheless, these effects are not without quirks and limitations, leading to the development of higher-order effects. These higher-order effects extend the capabilities of algebraic effects, providing greater flexibility for expressing effectful computations, while also shedding light on the connection between the monad approach and the algebraic approach to effects. This talk will survey the historical milestones that have shaped the landscape of effectful programming in Haskell, exploring the transition from monads to monad transformers and the emergence of algebraic and higher-order effects. Article: https://doi.org/10.1145/3609026.3615581 ORCID: https://orcid.org/0000-0002-4161-985X Video Tags: icfpws23haskellmain-key2-p, doi:10.1145/3609026.3615581, orcid:0000-0002-4161-985X Presentation at the Haskell 2023 conference, September 8–9, 2023, https://icfp23.sigplan.org/home/haskellsymp-2023 Sponsored by ACM SIGPLAN, https://www.sigplan.org/
·youtu.be·
[Haskell'23] The Evolution of Effects
Semantic Subtyping in Luau
Semantic Subtyping in Luau
Luau is the first programming language to put the power of semantic subtyping in the hands of millions of creators.
Off-the-shelf semantic subtyping is slightly different from what is implemented in Luau, because it requires models to be set-theoretic, which requires that inhabitants of function types “act like functions.” There are two reasons why we drop this requirement.
Set-theoretic semantic subtyping does not support this normalization, and instead normalizes functions to disjunctive normal form (unions of intersections of functions). We do not do this for ergonomic reasons: overloaded functions are idiomatic in Luau, but DNF is not, and we do not want to present users with such non-idiomatic types.
For these two reasons (which are largely about ergonomics rather than anything technical) we drop the set-theoretic requirement, and use pragmatic semantic subtyping.
Unexpectedly, this is not always true in set-theoretic models, due to uninhabited types. In set-theoretic models, if x has type never then f(x) has type never. We do not want to burden users with the idea that function application has a special corner case, especially since that corner case can only arise in dead code.
The other difference between Luau’s type system and off-the-shelf semantic subtyping is that Luau does not support all negated types.
·luau-lang.org·
Semantic Subtyping in Luau