Navigation

We present a closed dependent type theory whose inductive types
are given not by a scheme for generative declarations, but by encoding
in a universe. Each inductive datatype arises by interpreting its
description—a first-class value in a datatype of descriptions. Moreover,
the latter itself has a description. Datatype-generic programming
thus becomes ordinary programming. We show some of the
resulting generic operations and deploy them in particular, useful
ways on the datatype of datatype descriptions itself. Surprisingly
this apparently self-supporting setup is achievable without paradox
or infinite regress.

Ringad comprehensions represent a convenient notation for expressing
database queries. The ringad structure alone does not provide
a good explanation or an efficient implementation of relational joins;
but by allowing heterogeneous comprehensions, involving both bag and
indexed table ringads, we show how to accommodate these too.

Indexed/parametric/graded monads are the key (read the paper to understand the pun).

The typed λ-calculus arises canonically as the term language for a logic called natural deduction, using the Curry-Howard isomorphism: the pervasive connection between logic and programming languages asserting that propositions are types and proofs are programs. Indeed, for many people, the λ-calculus is the living embodiment of Curry-Howard.

But natural deduction is not the only logic! Conspicuously, natural deduction has a twin, born in the very same paper, called the sequent calculus. Thanks to the Curry-Howard isomorphism, terms of the sequent calculus can also be seen as a programming language with an emphasis on control flow.

This paper details how folklore notions of hygiene and referential transparency
of R5RS macros are defeated by a systematic attack. We demonstrate
syntax-rules that seem to capture user identifiers and allow their own identifiers
to be captured by the closest lexical bindings. In other words, we have written
R5RS macros that accomplish what commonly believed to be impossible.

We are nearing the day someone quips that C is an improvement on most of its successors (smirk). So reading this page from the SQLite website is instructive, as is reading the page on the tooling and coding practices that make this approach work.

I think none of this is news, and these approaches have been on the books for quite a bit. But still, as I said: an improvement on most of its successors. Hat tip: HN discussion.

We present a resource-management model for ML-style programming languages, designed to be compatible with the OCaml philosophy and runtime model. This is a proposal to extend the OCaml language with destructors, move semantics, and resource polymorphism, to improve its safety, efficiency, interoperability, and expressiveness. It builds on the ownership-and-borrowing models of systems programming languages (Cyclone, C++11, Rust) and on linear types in functional programming (Linear Lisp, Clean, Alms). It continues a synthesis of resources from systems programming and resources in linear logic initiated by Baker.

It is a combination of many known and some new ideas. On the novel side, it highlights the good mathematical structure of Stroustrup's "Resource acquisition is initialisation" (RAII) idiom for resource management based on destructors, a notion sometimes confused with finalizers, and builds on it a notion of resource polymorphism, inspired by polarisation in proof theory, that mixes C++'s RAII and a tracing garbage collector (GC).
The proposal targets a new spot in the design space, with an automatic and predictable resource-management model, at the same time based on lightweight and expressive language abstractions. It is backwards-compatible: current code is expected to run with the same performance, the new abstractions fully combine with the current ones, and it supports a resource-polymorphic extension of libraries. It does so with only a few additions to the runtime, and it integrates with the current GC implementation. It is also compatible with the upcoming multicore extension, and suggests that the Rust model for eliminating data-races applies.

Interesting questions arise for a safe and practical type system, many of which have already been thoroughly investigated in the languages and prototypes Cyclone, Rust, and Alms.

An ambitious goal, and it would be an incredibly useful addition to OCaml. Might even displace Rust in some places, since you can theoretically avoid triggering the GC, but you have the excellent GC available when needed. This is definitely a pain point for Rust.

When is one object equal to another object? While object identity is fundamental to object-oriented systems, object equality, although tightly intertwined with identity, is harder to pin down. The distinction between identity and equality is reflected in object-oriented languages, almost all of which provide two variants of “equality”, while some provide many more. Programmers can usually override at least one of these forms of equality, and can always define their own methods to distinguish their own objects.

This essay takes a reflexive journey through fifty years of identity and equality in object-oriented languages, and ends somewhere we did not expect: a “left-handed” equality relying on trust and grace.

This covers a lot of ground, not only historical, but conceptual, like the meaning of equality and objects. For instance, they consider Ralph Johnson on what object oriented programming means:

I explain three views of OO programming. The Scandinavian view is that an OO system is one whose creators realise that programming is modelling. The mystical view is that an OO system is one that is built out of objects that communicate by sending messages to each other, and computation is the messages flying from object to object. The software engineering view is that an OO system is one that supports data abstraction, polymorphism by late-binding of function calls, and inheritance.

And constrast with William Cook's autognosis/procedural-abstraction view, which we've discussed here before.

The paper's goal then becomes clear: "What can we do to provide an equality operator for a pure, autognostic object-oriented language?" They answer this question in the context of the Grace programming language. As you might expect from some of the authors, security and trust are important considerations.

Traditionally, APL is an interpreted language
...
In this paper, we present a compiler that compiles a subset of
APL into a typed intermediate representation, which should serve
as a practical and well-defined intermediate format for targeting
parallel-architectures through a large number of existing tools and
frameworks. The intermediate language is conceptually close to
the language Repa. It supports shape-polymorphic functions
and types that classify shapes. The compiler takes a simplified approach
to certain aspects of APL. Following other APL compilation
approaches, the compiler is based on lexical (i.e., static) identifier
scoping and has no support for dynamic compilation (APL execute).

Terseness of APL is legendary, for good or bad. I keep finding more and more papers by Haskell community (and especially GHC contributors) working on efficient (parallel) arrays in Haskell.