README.md

☕ Expresso

A simple expressions language with polymorphic extensible row types.

Introduction

Expresso is a minimal statically-typed functional programming language, designed with embedding and/or extensibility in mind.
Possible use cases for such a minimal language include configuration (à la Nix), data exchange (à la JSON) or even a starting point for a custom external DSL.

Expresso has the following features:

A small and simple implementation

Statically typed with type inference

Structural typing with extensible records and variants

Lazy evaluation

Convenient use from Haskell (a type class for marshalling values)

Haskell-inspired syntax

Type annotations to support first-class modules and schema validation use cases

Built-in support for ints, double, bools, chars, maybes and lists

Installation

Expresso the library and executable (the REPL) is currently built and tested using cabal.

Functions

Expresso is a functional language and so we use lambda terms as our basic means of abstraction. To create a named function, we simply bind a lambda using let. I toyed with the idea of using Nix-style lambda syntax, e.g. x: x for the identity function, but many mainstream languages, not just Haskell, use an arrow to denote a lambda term. An arrow is also consistent with the notation we use for types.
Expresso therefore uses the arrow -> to denote lambdas, with the parameters to bind on the left and the expression body on the right, for example x -> x for identity.

Note that multiple juxtaposed arguments is sugar for currying. For example:

f x -> f x

is the same as:

f -> x -> f x

The function composition operators are >> and << for forwards and backwards composition respectively.

Records

Expresso records are built upon row-types with row extension as the fundamental primitive. This gives a very simple and easy-to-use type system when compared to more advanced systems built upon concatenation as a primitive. However, even in this simple system, concatenation can be encoded quite easily using difference records.

Records can of course contain arbitrary types and be arbitrarily nested. They can also be compared for equality. The dot operator (select) is used to project out values.

Records with polymorphic functions can be passed as lambda arguments and remain polymorphic using higher-rank polymorphism. To accomplish this, we must provide Expresso with a suitable type annotation of the argument. For example:

The function f above takes a "module" m containing a polymorphic function reverse. We annotate m with a type by using a single colon : followed by the type we are expecting.
Note the underscore _ in the tail of the record. This is a type wildcard, meaning we have specified a partial type signature. This type wildcard allows us to pass an arbitrary module containing a reverse function with this signature. To see the full type signature of f, we can use the Expresso REPL:

Note that the r, representing the rest of the module fields, is a top-level quantifier. The type wildcard is especially useful here, as it allows us to avoid creating a top-level signature for the entire function and explicitly naming this row variable. More generally, type wildcards allow us to leave parts of a type signature unspecified.

Function f can now of course be applied to any module satisfying the type signature:

λ> f (import "Prelude.x")
{l = [False, True], r = "cba"}

Difference records and concatenation

To encode concatenation, we can use functions that extend records and compose them using straightforward function composition:

The Unit type

The type {} is an example of a Unit type. It has only one inhabitant, the empty record {}:

λ> :type {}
{}

Variants

The dual of records are variants, which are also polymorphic and extensible since they use the same underlying row-types.
Variants are introduced via injection (the dual of record selection), for example:

λ> Foo 1
Foo 1

Unlike literal records, literal variants are open.

λ> :type Foo 1
forall r. (r\Foo) => <Foo : Int | r>

Variants are eliminated using the case construct, for example:

λ> case Foo 1 of { Foo x -> x, Bar{x,y} -> x+y }
1

The above case expression eliminates a closed variant, meaning any value other than Foo or Bar with their expected payloads would lead to a type error. To eliminate an open variant, we use a syntax analogous to extension:

Here the unmatched variant is passed to a lambda (with otherwise as the parameter). The expression after the bar | typically either ignores the variant or delegates it to another function.

Closed variants

We will often need to create closed variant types. For example, we may want to create a structural type analogous to Haskell's Maybe a, having only two constructors: Nothing and Just. This can be accomplished using smart constructors with type annotations. In the Prelude, we define the equivalent constructors just and nothing, as well as a fold maybe over this closed set:

Variant embedding

The dual of record restriction is variant embedding. This allows us to restrict the behaviour exposed by a case expression, by exploiting the non-overlapping field constraints.
For example, to prevent use of the Bar alternative of function f above, we can define a new function g as follows:

The Void type

Internally, the syntax to eliminate a closed variant uses the empty variant type <>, also known as Void. The Void type has no inhabitants, but we can use it to define a function absurd:

λ> :type absurd
forall a. <> -> a

Absurd is an example of Ex Falso Quodlibet from classical logic (anything can be proven using a contradiction as a premise).

As an example of the above, the following closed case expression:

case x of { Foo{} -> 1, Bar{} -> 2 }

is actually sugar for:

case x of { Foo{} -> 1 | x' -> case x' of { Bar{} -> 2 | absurd } }

A data-exchange format with schemas

We could use Expresso as a lightweight data-exchange format (i.e. JSON with types). But how might be validate terms against a schema?

A simple type annotation <term> : <type> , will not suffice for "schema validation". For example, consider this attempt at validating an integer against a schema that permits everything:

1 : forall a. a -- FAILS

The above fails to type check since the left-hand-side is inferred as the most general type (here a concrete int) and the right-hand-side must be less so.

Instead we need something like this:

(id : forall a. a -> a) 1

A nice syntactic sugar for this is a signature section, although the version in Expresso is slightly different from the Haskell proposal. We write (:T) to mean id : T -> T, where any quantifiers are kept at the top-level. We can now use:

(: forall a. a) 1

If we really do have places in our schema where we want to permit arbitrary data, we should use the equality constraint to guarantee the absence of partially-applied functions. For example: