( )

Trait-Constrained Enums in Rust

2025-11-07T00:00:00-00:00

Overview

A simple expression language
More precise types with GADTs
More flexible types with GADTs
Encoding GADTs in Rust
Limitations
Conclusion

Rust doesn’t have GADTs (generalised algebraic data types), but we can get surprisingly close with some creative type-level tricks.

This post might look like a departure from my usual (in the sense of typical, not frequent) Haskell posts since we’ll be writing Rust today. Don’t let that fool you; we’ll just be writing Haskell in Rust.

GADTs are a Haskell feature that let constructors carry richer type information. They can enforce constraints or refine type parameters per constructor – which is what we’ll achieve here in Rust.

As this post is mainly for Rust programmers, I’ll start by motivating why GADTs are useful. For that, we’ll build a small expression language and see where plain algebraic data types fall short. Then we’ll introduce GADTs to fix the problem, first through type refinement and then with per-constructor constraints. After that, we’ll move to Rust and reconstruct both mechanisms: type equality witnesses (a known trick) and constraint witnesses (the new bit this post is really about). You’ll know when we’ve switched from Haskell to Rust — the syntax gets ugly.

A simple expression language

Let’s start with a small expression language, encoded as a Haskell datatype. It supports defining integer literals, and adding them together.

data Expr
  = LitInt Int
  | Add Expr Expr

The Rust equivalent of this is an enum with two constructors and more parentheses (and explicit heap indirection).

We can evaluate expressions recursively:

eval :: Expr -> Int
eval (LitInt n) = n
eval (Add a b) = eval a + eval b

Evaluating eval (Add (LitInt 3) (Add (LitInt 4) (LitInt 5))) yields 12.

This is not a very useful expression language, so let’s add another literal type and another binary operator:

data Expr
  = LitInt Int
  | Add Expr Expr
  | LitBool Bool
  | Or Expr Expr

Now we can write expressions like Add (LitInt 1) (LitInt 2) and Or (LitBool False) (LitBool True). But we can also write Add (LitInt 1) (LitBool False), which shouldn’t type-check!

Worse, we’re in trouble when writing the return type of eval :: Expr -> ???. What it should return depends on the input, but the input type doesn’t contain enough information.

More precise types with GADTs

GADTs let us say more about each constructor’s result type. We can extend our Expr definition so that Add only exists for integers, and Or only for booleans.

{-# LANGUAGE GADTs #-}

data Expr a where
  LitInt :: Int -> Expr Int
  Add :: Expr Int -> Expr Int -> Expr Int
  LitBool :: Bool -> Expr Bool
  Or :: Expr Bool -> Expr Bool -> Expr Bool

Notice that Expr a is now parameterised (this would read Expr<A> in Rust), and each constructor specifies the type of expression it builds. LitInt takes an Int and produces an Expr Int, and Add combines two Expr Ints into another Expr Int.

As a result, Add (LitInt 1) (LitBool False) is rejected at compile time because the second operand has the wrong type.

The evaluation function can now have a precise type:

eval :: Expr a -> a
eval (LitInt n) = n
eval (Add a b) = eval a + eval b
eval (LitBool b) = b
eval (Or a b) = eval a || eval b

eval now takes an expression of any type, and returns a value of that type. When pattern matching on Expr a, if we see a LitInt, we learn that a is Int, so the result must be an integer. In the Add branch, both sub-expressions are Expr Int, so eval produces two Ints which can be added together.

In other words, we not only restrict what types of expressions can be used when constructing Add, but also learn type information when destructuring it.

So far, every constructor fixes a concrete return type. But what if we wanted to support other types that can also be added together?

More flexible types with GADTs

Let’s say we want to support Doubles in our language too:

data Expr a where
  LitInt :: Int  -> Expr Int
  LitDouble :: Double  -> Expr Double
  Add :: Expr Int -> Expr Int  -> Expr Int
  ...

Doubles, being numeric values, can also be added together, but the current Add constructor only works on integers. We can relax this by constraining the a type parameter just in this constructor:

data Expr a where
  LitInt     :: Int  -> Expr Int
  LitDouble  :: Double -> Expr Double
  Add        :: Num a => Expr a -> Expr a -> Expr a
  ...

The Num a => part is a type class constraint in Haskell, equivalent to a trait bound in Rust. In other words, Add can now take any two expressions of the same type, as long as that type supports numeric operations.

The eval function simply gains one extra case:

eval :: Expr a -> a
eval (LitInt n) = n
eval (LitDouble n) = n
eval (Add a b) = eval a + eval b
eval (LitBool b) = b
eval (Or a b) = eval a || eval b

Add now supports Add (LitDouble 1.0) (LitDouble 2.0) and Add (LitInt 1) (LitInt 2). Crucially, the Num a constraint is attached to just the Add constructor, not the entire type. It’s still possible to construct LitBool values, even though booleans don’t support addition.

Each Add value carries evidence that its type parameter a satisfies Num. When we pattern match on Add, the type checker brings that constraint into scope automatically, allowing us to use (+) in the corresponding branch.

This is a subtle but powerful idea: constraints can be local to a constructor. Even the precise return types we saw earlier are another form of locality — LitInt locally records that a is equal to Int.

Next, we’ll rebuild the expression language in Rust, and see how to emulate both of these features: constructor-local type equalities and constructor-local constraints. To start adopting the Rust nomenclature, we’ll build an enum whose constructors are trait-constrained.

Encoding GADTs in Rust

We’ll be encoding both properties of GADTs:

Constructor-local type equalities — like LitInt refining a ~ Int.
Constructor-local constraints — like Add requiring Num a.

We’ll start with the first one, since the idea is already well known in the Rust community.

As a baseline, here’s the simple expression language, with the promised parentheses and heap indirections:

enum Expr {
    LitInt(i64),
    Add(Box<Expr>, Box<Expr>),
    LitBool(bool),
    Or(Box<Expr>, Box<Expr>),
}

As things stand, we have the same issues as the original Haskell version, namely that we can construct invalid combinations, and can’t give a precise type to eval.

Type equality witnesses

In Haskell, specifying the return type of a GADT allowed us to express a type equality which the typechecker could then automatically use to unify the type variable with the concrete type.

This relies on the type checker’s ability to make progress with locally learned information, which Rust doesn’t natively support. Our encoding will instead rely on an explicit witness of type equality, which we then use where Haskell would use the GADT constraint.

In Rust, we can encode this concept as a zero-sized type: ¹

use core::marker::PhantomData;

struct Is<A, B>(PhantomData<(A, B)>);

impl<A> Is<A, A> {
    fn refl() -> Self {
        Is(PhantomData)
    }
}

Is<A, B> is our equality witness: a value of type Is<A, B> is only constructible when A and B are equal. refl is the only safe way to construct values of type Is.

If you’ve seen this trick before, you can safely skim this part. The more interesting bit is how to do the same thing for trait bounds, not just type equalities.

We can now write Expr<A> where each constructor stores a type equality witness:

enum Expr<A> {
    LitInt(Is<i64, A>, i64),
    Add(Is<i64, A>, Box<Expr<i64>>, Box<Expr<i64>>),
    LitBool(Is<bool, A>, bool),
    Or(Is<bool, A>, Box<Expr<bool>>, Box<Expr<bool>>),
}

Expr::LitInt(Is::refl(), 42) has type Expr<i64>, because the refl() constructor forces the A variable to unify with i64.

Expr::Add(
    Is::refl(),
    Box::new(Expr::LitInt(Is::refl(), 1)),
    Box::new(Expr::LitInt(Is::refl(), 2)),
)

typechecks, but

Expr::Add(
    Is::refl(),
    Box::new(Expr::LitInt(Is::refl(), 1)),
    // wrong type, expected an Expr<i64> but got Expr<bool>
    Box::new(Expr::LitBool(Is::refl(), false)),
)

doesn’t.

This machinery allows us to restrict the types of expressions that can be used in Add, but how do we learn type information?

fn eval<A>(expr: Expr<A>) -> A {
    match expr {
        Expr::LitInt(p, n) => ??? // n is of type 'i64', we need to return 'A'
        ...
    }
}

In the Haskell version, the type equality bound by the GADT constructor is a native language feature that the typechecker knows about, so it freely converts between a and Int under a pattern match.

In Rust, we created a custom encoding of type equality, and the typechecker doesn’t (and shouldn’t, in general) use it to unify types.

This means that we need to write a function that actually performs the conversion:

impl<A, B> Is<A, B> {
    fn convert(self, a: A) -> B {
        unsafe { std::intrinsics::transmute_unchecked(a) }
    }
}

transmute_unchecked is a very unsafe function in general, but in our case, we only invoke it when we have a type equality witness available (which can only be constructed via refl), so we know the types A and B are actually equal.

With this, we can now use the equality witnesses in the constructors to rewrite the results into the desired A:

fn eval<A>(expr: Expr<A>) -> A {
    match expr {
        Expr::LitInt(p, n) => p.convert(n), // i64 -> A
        Expr::Add(p, left, right) => p.convert(eval(*left) + eval(*right)),
        Expr::LitBool(p, b) => p.convert(b),
        Expr::Or(p, left, right) => p.convert(eval(*left) || eval(*right)),
    }
}

Trait constraint witnesses

The type equality witnesses from the previous section are relatively simple, because the only thing we need to record about our type parameter is that it’s equal to a known type in the local context.

Trait implementations are more complicated, because we need to know how certain functionality is implemented for our type parameter.

Haskell’s GADTs store references to type class dictionaries in their constructors – essentially dynamic dispatch. While Rust supports dynamic dispatch via dyn Trait, it’s severely limited (requiring “object safe” traits), so we’ll need a different approach.

We’ll start with a similar witness idea, but this time, the witness will record the fact that a trait implementation exists for a type.

We’ll define a witness for the existence of a Add-like capability, corresponding to the Num constraint in the Haskell version.

struct CanAdd<T: ?Sized> {
    _phantom: PhantomData<T>,
}

impl<T: std::ops::Add<Output = T>> CanAdd<T> {
    fn new() -> Self {
        CanAdd { _phantom: PhantomData }
    }
}

fn can_add<T: std::ops::Add<Output = T>>() -> CanAdd<T> {
    CanAdd::new()
}

CanAdd<T> can only be constructed (via can_add) if T supports the Add operation with result type T. This mirrors the Num a => constraint on the Haskell side.

We can now extend our expression type with a constructor that carries this constraint witness:

enum Expr<A> {
    LitInt(Is<i64, A>, i64),
    LitDouble(Is<f64, A>, f64),
    Add(CanAdd<A>, Box<Expr<A>>, Box<Expr<A>>),
    LitBool(Is<bool, A>, bool),
    Or(Is<bool, A>, Box<Expr<bool>>, Box<Expr<bool>>),
}

This version of Expr is the Rust analogue of the final Haskell GADT. The Add constructor now carries a CanAdd<A> witness that proves A implements Add<Output = A>.

So far this handles the construction side of the story, but not the destruction side. When we pattern match on an Expr<A>, Rust doesn’t know that A satisfies the constraint carried by CanAdd<A>.

fn eval<A>(expr: Expr<A>) -> A {
    match expr {
        ...
        Expr::Add(w, a, b) => eval(*a) + eval(*b), // cannot add `A` to `A`
        ...
    }
}

To recover that information, we’ll need to encode it in a trait that can selectively enable the operation based on the presence of a witness.

Using specialisation to recover constraints

We now want to use the information stored in CanAdd<A> when pattern matching on an expression. In Haskell, this happens automatically: matching on Add brings the Num a constraint into scope. Rust has no mechanism for this, so we’ll need an indirection.

We’ll introduce a helper trait MaybeAdd that acts like a type class dictionary. It provides an operation maybe_add, which only exists when the type supports addition. We’ll use specialisation to make that conditional.

#![feature(specialization)]

trait MaybeAdd {
    fn maybe_add(self, rhs: Self) -> Self;
}

We define a default implementation for all types:

impl<T> MaybeAdd for T {
    default fn maybe_add(self, _rhs: Self) -> Self
    {
        unreachable!("no Add implementation for this type")
    }
}

and a specialised implementation for types that implement Add:

impl<T: std::ops::Add<Output = T>> MaybeAdd for T {
    fn maybe_add(self, rhs: Self) -> Self
    {
        self + rhs
    }
}

With this machinery, we can now use the constraint witness inside eval:

fn eval<A>(expr: Expr<A>) -> A {
    match expr {
        Expr::LitInt(p, n) => p.convert(n),
        Expr::LitDouble(p, d) => p.convert(d),
        Expr::LitBool(p, b) => p.convert(b),
        Expr::Add(w, a, b) => eval(*a).maybe_add(eval(*b)),
        Expr::Or(p, a, b) => p.convert(eval(*a) || eval(*b)),
    }
}

Rather than directly using + (which we can’t, since A isn’t known to implement std::ops::Add in this context), we delegate to maybe_add, which uses specialisation to select the correct implementation at monomorphisation time.

#[test]
fn eval_test() {
    let expr_int = {
        let a = Expr::LitInt(Is::refl(), 3);
        let b = Expr::LitInt(Is::refl(), 4);
        Expr::Add(can_add(), Box::new(a), Box::new(b))
    };
    assert_eq!(eval(expr_int), 7);

    let expr_double = {
        let a = Expr::LitDouble(Is::refl(), 2.5);
        let b = Expr::LitDouble(Is::refl(), 4.0);
        Expr::Add(can_add(), Box::new(a), Box::new(b))
    };

    assert_eq!(eval(expr_double), 6.5);
}

Why this works

If you’re coming from Haskell, it might be surprising that eval works at all. In Haskell, type class resolution is coupled with evidence generation: when the compiler decides that a type satisfies a constraint, it also produces a reference to the corresponding dictionary. If Rust worked the same, then that algorithm would pick the catch-all default implementation of MaybeAdd under the Expr::Add arm of eval, because at that point, no information is known about the type (and our CanAdd witness is invisible to the typechecker).

However, Rust’s specialisation works differently. During type checking, the compiler only checks that some implementation of MaybeAdd exists – it doesn’t commit to which one. This step is proof-irrelevant: the fact that a trait is implemented matters, but not which implementation it resolves to.

The actual selection happens later, during monomorphisation, once all type parameters are concrete. At that point, the specialiser sees that A = i64 (or A = f64, etc.) and picks the more specific implementation that performs real addition. The default unreachable!() version is never instantiated, precisely because our witness mechanism disallows constructing expressions that try to add values without Add implementations.

This is the crucial distinction between Haskell and Rust: in Haskell, dictionary resolution is part of type checking; in Rust, it’s deferred until code generation. The specialiser makes the final decision once it knows the concrete types, and because our witness types restrict what can actually be constructed, the correct implementation is always chosen.

In effect, Rust’s specialisation system lets us recover local constraint learning at compile time, without runtime dictionaries or dynamic dispatch. Everything is resolved statically and erased before code generation. A truly zero-cost abstraction!²

Limitations

This technique has a few obvious caveats.

First, it relies on specialisation, which is still unstable and only available on nightly Rust. The feature also has some unsound edge cases that the compiler can’t currently detect, though this particular usage is benign because it doesn’t overlap implementations in unsafe ways.

Second, the design doesn’t generalise to existential types — Rust simply has no equivalent. We can simulate type refinement (as with Expr<A>), but not “forgetting” type information safely.

Finally, while the runtime cost is zero, the cognitive cost certainly isn’t. The type signatures are verbose, the ergonomics are questionable, and the amount of ceremony required to recover what Haskell gives you by default is non-trivial.

Conclusion

Until now we’ve been preoccupied with whether or not we could. Now it’s time to stop and think if we should.

Using PhantomData<fn(A) -> B> would make A and B invariant, which is slightly more robust if lifetimes are involved. For this post, PhantomData<(A, B)> is simpler and works fine. ↩
Luckily the cost analysis of abstractions doesn’t include developer ergonomics. ↩

Trait-Constrained Enums in Rust was originally published by Csongor Kiss at ( ) on June 10, 2025.

Announcing generic-optics (& generic-lens 2.0.0.0)

2020-02-11T00:00:00-00:00

I’m happy to announce a new library, generic-optics, accompanied by version 2.0.0.0 of generic-lens.

Background

A few months ago, the folks at Well-Typed announced the optics library, which aims to improve on the user experience compared to the lens library. Oleg Grenrus has written an excellent migration guide from lens to optics, so please have a look there for some more background.

generic-optics is essentially a port of generic-lens that is compatible with optics, and is designed to be a drop-in replacement for generic-lens. This means that if you’re already using generic-lens with lens and decide to migrate to optics, you should be able to replace the generic-lens dependency with generic-optics and expect things to just work.

Examples

To explain why I’m so excited about optics, I’m going to compare a real-life workflow between generic-lens and generic-optics.

First, language pragmas and imports:

{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE DeriveGeneric #-}

import Data.Generics.Product
import GHC.Generics

Note that the module Data.Generics.Product is shared between generic-lens and generic-optics.

When using generic-lens with the lens library, we would import

import Control.Lens

When using generic-optics with optics, the import becomes

import Optics.Core

Now we define a simple record:

data MyRecord = MyRecord { a :: Int, b :: Int, c :: (Bool, Int) }
  deriving (Generic, Show)

myRecord1 :: MyRecord
myRecord1 = MyRecord 0 1 (False, 2)

With either library, we can view the a field using the field lens:

lens|optics> myRecord1 ^. field @"a"
0

If we ask what the type of field @"a" is in GHCi, we already see the advantage of optics’s opaque representation.

Compare

lens> :t field @"a"
field @"a"
  :: (HasField "a" s t a b, Functor f) => (a -> f b) -> s -> f t

with

optics> :t field @"a"
field @"a" :: HasField "a" s t a b => Lens s t a b

Now let us use the typed lens, which performs a type-directed lookup in a product type, as long as there is a unique field with that type:

lens|optics> myRecord1 ^. typed @(Bool, Int)
(False,2)

When the type of the field is not unique (such as if we tried to retrieve a field of type Int), both generic-optics and generic-lens provides a helpful type error:

lens|optics> myRecord1 ^. typed @Int

<interactive> error:
    • The type MyRecord contains multiple values of type Int.
      The choice of value is thus ambiguous. The offending constructors are:
      • MyRecord

For situation likes this, both libraries provide a traversal called types that focuses on all values of the given type.

Let’s see what happens if we replace typed with types in the above example when using lens:

lens> myRecord1 ^. types @Int

<interactive>:43:14-23: error:
    • No instance for (Monoid Int) arising from a use of ‘types’

This error is rather puzzling. Unless we know what’s going on under the hood, it’s not obvious where the Monoid constraint is coming from.

Compare this with generic-optics:

optics> myRecord1 ^. types @Int

<interactive>:32:1-23: error:
    • A_Traversal cannot be used as A_Getter

Right! types @Int is a traversal, but ^. takes a getter! Arguably this is a more helpful message. Consulting the documentation of optics, we find the combinator we’re looking for: ^.., which returns all the values focused on by a traversal:

lens|optics> myRecord1 ^.. types @Int
[0,1,2]

This now of course works in both libraries.

To summarise, using the two libraries should be nearly identical as long as everything goes well and we’re not hitting type errors. Where generic-optics (but really, optics itself) shines is when things do not go all that well, in which case the resulting error messages are a lot more comprehensible.

Differences

The above was just to give a little taste of using generic-optics. The interface of generic-optics is intended to be largely identical to that of generic-lens.

Labels

At the time of writing, the main difference is the support for overloaded labels in generic-lens, which allows writing

lens> import Data.Generics.Labels ()
lens> myRecord1 ^. #a
0

I intend to add support for this for generic-optics too, but it isn’t implemented yet.

Changes in generic-lens

To support this new interface, generic-lens itself has undergone a major reorganisation. I thought this was a good opportunity to clean some things up and change the interface at places, which ultimately resulted in a new major version bump.

Most notably, GHC versions below 8.4 are no longer supported. generic-lens (and generic-optics too) promises good performance by making sure that the generic overhead is eliminated at compile time. Doing so requires really careful coding practices, and GHC’s optimiser changes between every version, which meant that certain tricks that worked for 8.2 didn’t work for 8.6 and vice versa. The result was horrible CPP macros to enable certain hacks on certain versions of GHC. In the end, I decided it wasn’t worth the effort to maintain these hacks for older versions of the compiler.

I intend to write a blog post in the near future describing some of these hacks, as they are quite interesting and potentially educational.

For a more comprehensive list of changes, refer to the changelog.

Conclusion

Thanks for reading this blog post, and I’m hope you’re as excited about generic-optics as I am! Since this release required a major refactoring and moving things around, it is possible that some documentation is out of date, or certain functions are not exported from where you would expect. If you find anything that looks off, please either open a pull request or let me know on the issue tracker!

Finally, if you find generic-lens or generic-optics useful, consider buying me a coffee!

Announcing generic-optics (& generic-lens 2.0.0.0) was originally published by Csongor Kiss at ( ) on February 11, 2020.

Opaque constraint synonyms

2019-09-25T00:00:00+00:00

Overview

Constraints newtypes (kind of)
A real world example
Acknowledgements

The list of type class constraints in a function signature can sometimes get out of hand. In these situations, we can introduce a type synonym (thanks to ConstraintKinds) to avoid repetition.

Say we want to group together the Show and Read constraints:

type Serialise a = (Show a, Read a)

Now Serialise a can be used anywhere where we require both constraints:

roundtrip :: Serialise a => a -> a
roundtrip = read . show

This is great, because it means we no longer have to spell out (Show a, Read a) whenever we need both, and we also improved readability, because Serialise conveys some additional domain-specific meaning.

There’s a problem with this, however. If we ask GHCi about the type of roundtrip:

>>> :t roundtrip
roundtrip :: (Show a, Read a) => a -> a

it will eagerly expand the type synonym, removing all traces of Serialise. Of course this is a well known problem of type synonyms, so we generally avoid them in favour of newtypes.

But there’s no analogous construction for constraints. Or is there?

Constraints newtypes (kind of)

To begin, we’re going to drop the type synonym in favour of the “constraint synonym” technique, which is essentially the following:

class (Show a, Read a) => Serialise a
instance (Show a, Read a) => Serialise a

In other words, we introduce a new type class with the required superclass constraints, and a single catchall instance.

So far, the status quo hasn’t improved though. GHC is quite renitent:

>>> :t roundtrip
roundtrip :: (Show a, Read a) => a -> a

This happens because the compiler sees that there’s only one matching instance, so it’s safe to pick that one, and it will do so. This point is the important one: that there’s only one instance. So, if we could somehow trick GHC into thinking that there are other options, then maybe it wouldn’t be so eager to expand our constraints.

So, we create an empty data type, only to be used internally:

data Opaque

Next, we satisfy the superclass constraints

instance Read Opaque where
  readsPrec = undefined

instance Show Opaque where
  showsPrec = undefined

Note that these two instances only exist so that the constraint is satisfied, but since the type is internal, the actual functions are never going to be invoked.

Finally, the key ingredient: an overlapping instance for Serialise Opaque.

instance {-# OVERLAPPING #-} Serialise Opaque

Now, every time GHC sees a Serialise a constraint, it will no longer be able to pick the catchall instance, in case a gets instantiated to Opaque later. Of course, this won’t happen, because we don’t export Opaque, but it’s good enough for GHC.

>>> :t roundtrip
roundtrip :: Serialise a => a -> a

A real world example

You might say that the (Show a, Read a) example is perhaps overly simplistic. I came up with this technique to solve a very real problem in the generic-lens library. This problem shows up at many places in the library, but to pick one, consider the AsType class:

class AsType a s where
  _Typed :: Prism' s a

The exact meaning of the class is irrelevant here (but see the documentation if you’re interested). What matters is that there’s a catchall instance defined for all types (using GHC.Generics), which in turn requires a large number of other constraints and predicates to hold. Since this catchall instance is the only one defined by the library, asking for the type of _Typed in GHCi eagerly expands the constraints to those of the instance.

>>> :t _Typed
_Typed
  :: (ErrorUnlessOne
        a s (CollectPartialType (TupleToList a) (Rep s)),
      Defined (Rep s) (TypeError ...) (() :: Constraint), Generic s,
      ListTuple a (TupleToList a), GAsType (Rep s) (TupleToList a),
      Data.Profunctor.Choice.Choice p, Applicative f) =>
     p a (f a) -> p s (f s)

Not great. All the internal implementation details leak out. By employing the opaque constraint trick above, we can define overlapping instances for the AsType class, which results in the following type signature:

>>> :t _Typed
_Typed :: AsType a s => Prism' s a

which is much nicer!

Acknowledgements

I wrote most of this post a while time ago, but never published it. Thanks to Rob Rix for bringing up this topic and thus reminding me to publish it. It’s good to see library authors care about the user experience of their library down to this level of detail, and I hope this technique will be useful for many others!

Opaque constraint synonyms was originally published by Csongor Kiss at ( ) on September 25, 2019.

Tripping up type inference

2019-09-18T00:00:00-00:00

One of the main selling points of Haskell is that despite (or because) of its strong static type system, it frees us from the burden of having to spell out tedious type signatures everywhere.

Type inference is a blessing, but sometimes it can also be a curse. Inference too good can hinder the readability of code, because the compiler knows what the type of an identifier is even when we don’t. It’s not just readability though: correctness can be imperilled too.

As an example, consider the Tagged type, which allows us to attach type information to some other type.

newtype Tagged (s :: k) a = MkTagged a

Then we might want to define a Person type consisting of a first name and a last name, both of type String, tagged by (type-level) symbols accordingly:

data Person = MkPerson
  (Tagged "firstName" String)
  (Tagged "lastName" String)

We can then construct values of this type:

joseph :: Person
joseph = MkPerson
  (MkTagged "Joseph")
  (MkTagged "Knecht")

And here is the problem. Since both fields are constructed just with the MkTagged constructor, nothing is stopping us from mixing up the field names if we misremember the ordering:

joseph' :: Person
joseph' = MkPerson
  (MkTagged "Knecht")
  (MkTagged "Joseph")

We would wish to get a type error, but GHC happily infers that MkTagged "Joseph" indeed has type Tagged t String for any t, thus it fits perfectly into the "lastName" field.

We can fix this example by providing explicit type applications to the MkTagged constructor. Then, mixing up the order is a type error.

joseph' :: Person
joseph' = MkPerson
  (MkTagged @"lastName" "Knecht")
  (MkTagged @"firstName" "Joseph")

results in:

    • Couldn't match type ‘"lastName"’ with ‘"firstName"’

This works, but these annotations are entirely optional, and if we forget about them, we’re in trouble once again.

To summarise, the problem is that GHC can infer the type of MkTagged "Joseph", and due to the generality of the result, it can also unify it with any arbitrary tag.

So the question is this: how do we stop GHC from inferring the type of expressions like MkTagged "Joseph"? In other words, how do we enforce that the tag must be provided by explicit type annotation?

An ambiguous smart constructor

We’re going to write a smart constructor that can only be invoked by explicit type annotation of the tag type.

mkTagged :: forall t a. a -> Tagged (???) a
mkTagged = MkTagged

What to put in the ??? hole? The idea is that we want t in this type to be ambiguous, in other words, it should be impossible to infer t even if we know what Tagged (???) a is. If it can’t be inferred, then GHC will insist that we specify a type annotation at the use site for what t should be.

The obvious thing to plug into ??? would be t itself, but that doesn’t work of course, because from knowing Tagged t a, t can be trivially inferred. For example, when given a value of type Tagged "firstName" String, we can infer that t must be "firstName".

As always (at least this seems to be a recurring theme here on my blog), we reach for type families to solve this problem. In particular, we define a rather funny-looking variant of the identity type family, which I’m going to call Ambiguous:

type family Ambiguous (a :: k) :: j where
  Ambiguous x = x

The first thing that might strike you is the kind signature: Ambiguous takes an argument of kind k, and returns something of kind j. It helps to think of these kind parameters as additional inputs to the type family.

That is, Ambiguous "firstName" will get stuck:

>>> :kind! Ambiguous "firstName"
Ambiguous "firstName" :: j
= Ambiguous "firstName"

because GHC doesn’t know at which j we want to evaluate the type family (and indeed, in principle this choice could change the behaviour of the type family, since in GHC, type families are not parametric).

In order to properly reduce the family, we must provide the result kind as an input, like so:

>>> :kind! (Ambiguous "firstName" :: Symbol)
(Ambiguous "firstName" :: Symbol) :: Symbol
= "firstName"

Now let us plug this type family into the type of mkTagged, and see what happens.

mkTagged :: forall t a. a -> Tagged (Ambiguous t) a
mkTagged = MkTagged

Now, when GHC’s given Ambiguous t, it can’t work out what t is. Why? Suppose we know that Ambiguous t :: Symbol, that is, we expect it to reduce to a symbol. That still doesn’t tell us anything about the kind of t! According to the kind signature of Ambiguous, the kind of t could be anything. Indeed, the only way to disambiguate this is to provide the kind of t. As the signature of mkTagged does not have an explicit kind annotation on t, the only way to provide the kind of t is to provide t itself (since only visibly quantified variables can be applied with visible type applications).

Now, the following code

joseph :: Person
joseph = MkPerson
  (mkTagged "Joseph")
  (mkTagged "Knecht")

results in the error:

    • Couldn't match type ‘Ambiguous t0’ with ‘"firstName"’

To fix it, we now must provide type applications:

joseph :: Person
joseph = MkPerson
  (mkTagged @"firstName" "Joseph")
  (mkTagged @"lastName" "Knecht")

Tripping up type inference was originally published by Csongor Kiss at ( ) on September 18, 2019.

Most underrated vim features: C-a

2019-09-12T00:00:00-00:00

The aim of this series of blog posts is to shed light on some of the darker corners of the vim text editor that I have encountered over the years. Each post will focus on one particular feature, and should take no longer than a couple of minutes to read.

Today, I’d like to talk about the <C-a> key sequence (that is, control+a). It is extremely simple: pressing <C-a> searches the current line (starting at the cursor position) for a number, then increments it.

For example:

this is a number: 10.
^

<C-a>

this is a number: 11.
                   ^

where ^ marks the cursor position.

Its inverse is <C-x>, which decrements the number. We can also specify a count, for example 20<C-x> will result in:

this is a number: -9.
                   ^

Hexadecimal and binary numbers are supported too. For example, to convert 192 to hex, we can do

this is a hexadecimal number: 0x0.
^

192<C-a>

this is a hexadecimal number: 0xc0.
                                 ^

Most underrated vim features: C-a was originally published by Csongor Kiss at ( ) on September 12, 2019.

Global Implicit Parameters

2019-07-11T00:00:00-00:00

Overview

Under the hood
Barewords

Implicit parameters (enabled with the {-# LANGUAGE ImplicitParams #-} pragma) provide a way to dynamically bind variables in Haskell.

For example, the following function can be called in any context where ?x is bound:

foo :: (?x :: Int) => Int
foo = ?x

bar :: Int
bar = let ?x = 10 in foo

Unlike type classes, implicit parameters are bound locally. But what if we want to bind one in the global scope? This would allow a global “default” value, which could then be shadowed locally.

Unfortunately, the following is syntactically invalid:

?x = 21

We turn to the GHC User Manual, only to be further discouraged:

A group of implicit-parameter bindings may occur anywhere a normal group of Haskell bindings can occur, except at top level.

Of course, we won’t let mere syntactic restrictions to get in our way.

Under the hood

Since global binding of implicit parameters is officially not possible, we need to turn to unofficial methods. To begin, we pass the -ddump-tc-trace flag to GHC and recompile the module containing foo and bar. This makes GHC dump information about what it’s doing during typechecking the module. There is quite a lot of output, but one line looks interesting:

canEvNC:cls ghc-prim-0.5.3:GHC.Classes.IP ["x", Int]

Good software engineering practice dictates code reuse, and we all know that GHC is a well-engineered piece of software. Therefore, it is not surprising to find that implicit parameters are implemented by piggybacking off of type class resolution with some additional rules to disregard issues like global coherence.

As the above line suggests, implicit parameter resolution is desugared into the resolution of the GHC.Classes.IP type class from ghc-prim.

Even though this module is not documented, we can import it and ask GHCi for more information:

class IP (s :: Symbol) a | s -> a where
  ip :: a
  {-# MINIMAL ip #-}

It looks like GHC generates instances of the IP class on the fly whenever it sees a binder for an implicit parameter. The name of the parameter is represented as a type-level symbol. The functional dependency allows the variable’s type to be resolved just from its name.

Let’s try to write an instance for this class by hand:

-- ?x = 21
instance IP "x" Int where
  ip = 21

GHC happily accepts this definition. Indeed, we can now write

baz :: Int
baz = ?x

which evaluates to 21, by picking up the ?x variable from the top-level scope. As expected, let ?x = 10 in foo still evaluates to 10, as it shadows the top-level binding.

Barewords

Perhaps this is a good place to stop. But we can go further: above, we defined only the ?x variable. It turns out that we can define an instance for all symbols at once:

instance KnownSymbol s => IP s String where
  ip = symbolVal (Proxy :: Proxy s)

This instance brings all possible implicit variables into scope, and assigns their name their value by reflecting the symbol into a string.

bye :: String
bye = ?thanks ++ " " ++ ?for ++ " " ++ ?reading

Which almost feels like writing Perl!

Global Implicit Parameters was originally published by Csongor Kiss at ( ) on July 11, 2019.

Detecting the undetectable: custom type errors for stuck type families

2018-11-30T00:00:00-00:00

Overview

Type family evaluation semantics
Custom type errors
Conclusion

Custom type errors are a great way to improve the usability of Haskell libraries that utilise some of the more recent language extensions. Yet anyone who has written or used one of these libraries will know that despite the authors’ best efforts, there are still many occasions where a wall of text jumps out, leaving us puzzled as to what went wrong.

This post is about one particular class of such errors that have been troubling users of many modern Haskell libraries: stuck type families.

The following type error perfectly illustrates the problem. It is an actual error reported on the issue tracker of the generic-lens library.

• No instance for (Data.Generics.Product.Types.HasTypes'
                     (Data.Generics.Product.Types.Snd
                        (Data.Generics.Product.Types.InterestingOr
                           Description
                           (Data.Generics.Product.Types.InterestingOr
                              Description
                              (Data.Generics.Product.Types.Interesting'
                                 Description
                                 (Rep Text)
                                 Name
                                 '[Text, Sirname, None, Description])
                              (M1
                                 S
                                 ('MetaSel
                                    ('Just "name")
                                    'NoSourceUnpackedness
                                    'NoSourceStrictness
                                    'DecidedLazy)
                                 (Rec0 Name))
                              Name)
                           (M1
                              C
                              ('MetaCons "M" 'PrefixI 'False)
                              (S1
                                 ('MetaSel
                                    'Nothing
                                    'NoSourceUnpackedness
                                    'NoSourceStrictness
                                    'DecidedLazy)
                                 (Rec0 Multiple)))
                           Name))
                     Description
                     Name)
    arising from a use of ‘types’

Can you spot the problem? Even if you know what to look for, it takes a good few seconds to locate the culprit. The goal of this post is to turn the above into the following:

• No instance for Generic Text
   arising from a traversal over Description.

How could we possibly identify a lack of Generic instance from the above? Let us have a closer look at that large type error. It is a nested chain function of calls, such as Snd and Interesting, which are type families leaking out of the library’s implementation. The reason we see these type families (as opposed to the result they evaluate to), is because the computation is stuck. The culprit is the Rep Text part somewhere in the middle.

It turns out that Rep is an associated type family of the Generic class:

class Generic a where
  type Rep a :: Type -> Type
  ...

Thus, the reason Rep Text is not defined is that Text has no Generic instance. Clearly, it’s unreasonable to expect users to keep such implementation details in mind and hunt for unreduced occurrences of Rep in their type errors to find out what the issue is!

Yet, reporting this is not so easy. To explain why, we need to understand the behaviour of type families.

As things stand today, the associated family Rep is not actually connected to the Generic class as far as the type checker is concerned. This is why unreduced occurrences will not result in error messages mentioning anything about Generic in the first place. Constrained type families offer a solution to this problem, but they are not (yet) implemented in GHC.

Type family evaluation semantics

The reduction of type families is driven by the constraint solver. To the best of my knowledge, there is no formal specification for their semantics, so I’m not going to attempt to give a comprehensive account here either. Instead, let us just make some key observations about how type families reduce.

A type involving a type family is said to be stuck if none of the type family’s equations can be selected for the provided arguments. Since Texts have no Generic instance, there is consequently no Rep Text instance defined either. Thus, Rep Text is stuck.

How does “stuckness” propagate up a chain of function calls? Consider the following type family:

type family Foo a where
  Foo a = a

No matter what we pass in as the argument, the single equation will always match. This means that even if we pass in a stuck type, such as Rep Text, the equation can reduce to the right hand side (and get stuck afterwards):

>>> :kind! Foo (Rep Text)
= Rep Text

In other words, we can think of Foo as a type family that’s “lazy” in its argument. Now consider the Bar type family:

type family Bar a where
  Bar Maybe = Maybe
  Bar a = a

Here, we first check if the argument is Maybe, in which case Maybe is returned, otherwise we pick the second equation. Perhaps surprisingly, Bar behaves the same as Foo:

>>> :kind! Bar (Rep Text)
= Rep Text

The two equations of Bar agree with each other, because the first one is a substitution instance of the second. GHC recognises this, and decides that it is safe to drop the first equation in favour of the second one.

We can of course write disagreeing equations:

data T1 x
data T2 x

type family FooBar a where
  FooBar T1 = T2
  FooBar a = a

This time, notice that the first equation is not a substitution instance of the second: it returns something other than the argument.

GHC won’t optimise this case away anymore, and now instance matching will have to consider both equations. A given equation matches, if the argument unifies with the pattern, and is apart from all of the preceding patterns (i.e. doesn’t match any of them). The important thing here is that a stuck type is not apart from any other type, but neither does it match any other type. This means that

>>> :kind! FooBar (Rep Text)
= FooBar (Rep Text)

FooBar gets stuck just when its argument does. We can think of FooBar as a type family that is “strict” in its argument.

If we pass in a non-stuck value, evaluation proceeds as normal:

>>> :kind! FooBar Maybe
= Maybe

Since Maybe is apart from T1 (they are different ground types), and it unifies with the catch-all pattern a.

So, if a type family that inspects its argument is given a stuck type, then the resulting type will be stuck itself. Notice that we can’t proceed any further: there is no way to detect if the argument was stuck or not. This is why the type error above is so impenetrable. If we ignore our argument like Foo does, then it just slips by, but if we try to do something with it like FooBar does, we get stuck.

Of course, I wouldn’t have written down all of these low-level details about type family reduction if they didn’t lead to a solution!

Custom type errors

The mechanism of custom type errors is quite simple. The constraint solver proceeds normally, reducing all type family equations and solving all type class instances. If at the end, there are any constraints of the form TypeError ..., then the payload of the error gets printed, otherwise any unsolved constraints are reported.

As an example

foo :: TypeError ('Text "Ouch") => ()
foo = 10

yields

• Ouch

even though 10 clearly doesn’t have type ().

We want to produce a custom type error when the Rep type family gets stuck, and we’d like to continue normally otherwise. As discussed above, there is no way to branch on whether a type family is stuck or not.

However, we now have all the necessary pieces: all we need to do is to make sure that when Rep gets stuck, we leave a TypeError in the residual constraints. To do this, we’re going to wrap the call to Rep in another type family, which will get stuck just when Rep is stuck. When Rep reduces, our wrapper reduces too. The additional piece is that the wrapper will also hold a type error as its argument, which will reside in the unsolved constraint in the stuck case, but disappear otherwise.

type family Break (c :: Constraint) (rep :: Type -> Type) :: Constraint where
  Break _ T1 = ((), ())
  Break _ _  = ()

Break is the wrapper family. It takes a constraint, which will be our type error. Then it forces its argument by testing against T1. Note that in both equations, the type family reduces to the trivial constraint (), but in the first case, we use ((), ()) (a tuple of two trivial constraints) to ensure that the equations don’t optimise away, like they did with Bar.

Finally, we introduce a type family to construct a custom error message:

type family NoGeneric t where
  NoGeneric x = TypeError ('Text "No instance for " ':<>: 'ShowType (Generic x))

Now, consider what happens when we call Break with the stuck argument Rep Text:

>>> :kind! Break (NoGeneric Int) (Rep Text)
= Break (TypeError ...) (Rep Text)

the type gets stuck, with a TypeError inside! However, when called with a type where Rep is defined, such as Bool, the type reduces to the unit constraint, no mention of the type error.

>>> :kind! Break (NoGeneric Bool) (Rep Bool)
= () :: Constraint

And with this, we can report errors for any stuck type family.

bar :: Break (NoGeneric Text) (Rep Text) => ()
bar = ()

yields

• No instance for Generic Text
• In the expression: bar

Conclusion

Using this technique, we can place custom type errors right where our stuck type families are, and provide more contextual information about what went wrong. We can even generalise the above to the following type family:

type family Any :: k

type family Assert (err :: Constraint) (break :: Type -> Type) (a :: k) :: k where
  Assert _ T1 _ = Any
  Assert _ _ k = k

which we can use at any point in a computation, not just in constraints. Assert takes a type error, a potentially stuck computation, and a value. If the computation is stuck, then the custom error is presented, otherwise the value is passed through without any errors. Here, strictness is forced by the same T1 trick, but this time, to ensure that the right hand sides are also different, we return the Any type family in the first case.

Detecting the undetectable: custom type errors for stuck type families was originally published by Csongor Kiss at ( ) on November 29, 2018.

Parsing type-level strings in Haskell

2018-11-28T00:00:00-00:00

Overview

Motivation
Primitives
- AppendSymbol
- CmpSymbol
Decomposition
- Head
- Uncons
Conclusion

Haskell, as implemented in GHC, has a very rich language for expressing computations in types. Thanks to the DataKinds extension, any inductively defined data type can be used not only at the term level, but also at the type level. A notable exception are strings, which provide the main theme for today’s blog post.

The String type in Haskell is defined as a list of Chars. However, the type-level equivalent, Symbol, is defined as a primitive in GHC, presumably for efficiency. After all, the type checker passes these types around, and the simpler their structure, the less potential work the constraint solver needs to do.

The problem is this: since Symbol is defined as a primitive, there is no way to pattern match on its structure, and the only way to interact with them are by using the built-in primitive operations, namely appending and (efficient, constant-time) comparison.

In this blog post, I will show how these primitives can be used to recover the ability to do arbitrary introspection of these type-level string literals, thereby enabling a whole range of applications where statically known information can be exploited.

The technique presented here was inspired by Daniel Winograd-Cort’s pull request for the generic-lens library.

All of this is packaged into the symbols library.

Motivation

I have written about type-level symbol parsing in PureScript to implement a type-safe printf function. (There, I achieved symbol decomposition by patching the compiler, but no such thing is required here.)

Reusing that example, we will be able to write

>>> :t printf @"Wurble %d %d %s"
printf @"Wurble %d %d %s" :: Int -> Int -> String -> String

>>> printf @"Wurble %d %d %s" 10 20 "foo"
"Wurble 10 20 foo"

The implementation of the printf example using the technique described in this blog post can be found on github.

Primitives

First, let’s have a look at the primitives GHC provides for manipulating type of kind Symbol, namely AppendSymbol and CmpSymbol.

These functions are implemented in the compiler, and exported from the GHC.TypeLits module:

type family AppendSymbol (m :: Symbol) (n :: Symbol) :: Symbol
type family CmpSymbol (m :: Symbol) (n :: Symbol) :: Ordering

Note that there is no Uncons primitive that returns the head (first character) and the tail of the symbol. It turns out that we can implement Uncons using the two primitives above.

AppendSymbol

The fact that AppendSymbol is a type family suggests a rather straightforward semantics. It appends two symbols together resulting in a third one:

>>> :kind! AppendSymbol "foo" "bar"
= "foobar"

That is to say, it should only go in one way, so to speak.

However, if we have a look at the implementation in GHC, we can see that there’s more going on. There are special rules for the interaction of AppendSymbol constraints with equality constraints. In concrete terms, GHC will solve the following constraint:

(AppendSymbol "foo" b ~ "foobar") => (b ~ "bar")

That is, if we know a prefix of a symbol, we can decompose it to get the matching suffix. Morally, the actual signature of AppendSymbol would be closer to

type family AppendSymbol m n = r | r m -> n, r n -> m

But this can’t be expressed today in GHC (type family dependencies only allow the inputs to be decided solely by the result, and no such combination of inputs and outputs are allowed), so AppendSymbol really is a lot more powerful than what the type system would like to admit!

Even with the ability to decompose symbols, there is a problem, however. This decomposition only works if we know what the prefix is. And in general, we need to know two out of the three symbols involved in the constraint to get the third.

As a result, the following won’t work:

bad :: AppendSymbol prefix suffix ~ "hello world" => Proxy suffix
bad = Proxy

>>> :t bad
bad :: (AppendSymbol prefix suffix ~ "hello world") => Proxy suffix

that is, suffix is unsolved.

We might think that we can just try all possible characters as potential prefixes until one matches, but that would require backtracking in the constraint solver, and GHC’s constraint solver doesn’t backtrack.

That is, trying a prefix that doesn’t match results in an unsolvable constraint:

bad' :: AppendSymbol "a" suffix ~ "hello world" => Proxy suffix
bad' = Proxy

>>> :t bad'
bad' :: (AppendSymbol "a" suffix ~ "hello world") => Proxy suffix

But since we can’t backtrack, there is no way to try a different character once we’ve committed to a particular prefix.

If we knew what the first character was, we could strip it off and get the remaining symbol this way, which would allow us to treat Symbols as a list of characters essentially.

CmpSymbol

It turns out that we can simply use alphabetical ordering to find out what the first character of a string is. CmpSymbol compares two symbols, and returns one of LT, EQ, or GT as a result.

Observe that for any string longer than one, it’s always true that the string follows its first character alphabetically, and precedes any character after its first one. As an example, consider the string "hello world", whose first character is h, and the letter after h is i. Then we have

"h" < "hello world" < "i"

For strings of length one, they will simply return EQ when compared with their first character (themselves).

Decomposition

We now put the pieces together to implement an uncons function for symbols. First, we need Head, a function that returns the first character of a symbol. Second, we will use Head to interact with AppendSymbol to retrieve the tail of the symbol. Doing this repeatedly will allow us to turn a symbol into a list of characters, which in turn can be consumed by ordinary type families.

Head

So, to find out what the first character of a symbol is, we just need to find the last character in the ASCII table that precedes our symbol. To do this reasonably efficiently, we use binary search. Since indexing into a type-level list takes linear time, we use a balanced binary search tree instead. Recall that symbol comparisons are constant-time, so the whole operation is constant time (as we’re working with a fixed size alphabet), so this optimisation simply improves the constant factor by an order of magnitude.

data Tree a
  = Leaf
  | Node (Tree a) a (Tree a)
  deriving Show

The printable subset of the ASCII character set can be encoded as the following tree:

type Chars
 = 'Node
  ('Node
  ('Node
    ('Node
      ('Node
        ('Node ('Node 'Leaf '(" ", "!") 'Leaf) '("!", "\"") 'Leaf)
        '("\"", "#")
        ('Node ('Node 'Leaf '("#", "$") 'Leaf) '("$", "%") 'Leaf))
      '("%", "&")
      ('Node
        ('Node ('Node 'Leaf '("&", "'") 'Leaf) '("'", "(") 'Leaf)
        '("(", ")")
        ('Node ('Node 'Leaf '(")", "*") 'Leaf) '("*", "+") 'Leaf)))
    '("+", ",")
    ('Node
      ('Node
        ('Node ('Node 'Leaf '(",", "-") 'Leaf) '("-", ".") 'Leaf)
        '(".", "/")
        ('Node ('Node 'Leaf '("/", "0") 'Leaf) '("0", "1") 'Leaf))
      '("1", "2")
      ('Node
        ('Node ('Node 'Leaf '("2", "3") 'Leaf) '("3", "4") 'Leaf)
        '("4", "5")
        ('Node ('Node 'Leaf '("5", "6") 'Leaf) '("6", "7") 'Leaf))))
  '("7", "8")
  ('Node
    ('Node
      ('Node
        ('Node ('Node 'Leaf '("8", "9") 'Leaf) '("9", ":") 'Leaf)
        '(":", ";")
        ('Node ('Node 'Leaf '(";", "<") 'Leaf) '("<", "=") 'Leaf))
      '("=", ">")
      ('Node
        ('Node ('Node 'Leaf '(">", "?") 'Leaf) '("?", "@") 'Leaf)
        '("@", "A")
        ('Node ('Node 'Leaf '("A", "B") 'Leaf) '("B", "C") 'Leaf)))
    '("C", "D")
    ('Node
      ('Node
        ('Node ('Node 'Leaf '("D", "E") 'Leaf) '("E", "F") 'Leaf)
        '("F", "G")
        ('Node ('Node 'Leaf '("G", "H") 'Leaf) '("H", "I") 'Leaf))
      '("I", "J")
      ('Node
        ('Node ('Node 'Leaf '("J", "K") 'Leaf) '("K", "L") 'Leaf)
        '("L", "M")
        ('Node ('Node 'Leaf '("M", "N") 'Leaf) '("N", "O") 'Leaf)))))
  '("O", "P")
  ('Node
  ('Node
    ('Node
      ('Node
        ('Node ('Node 'Leaf '("P", "Q") 'Leaf) '("Q", "R") 'Leaf)
        '("R", "S")
        ('Node ('Node 'Leaf '("S", "T") 'Leaf) '("T", "U") 'Leaf))
      '("U", "V")
      ('Node
        ('Node ('Node 'Leaf '("V", "W") 'Leaf) '("W", "X") 'Leaf)
        '("X", "Y")
        ('Node ('Node 'Leaf '("Y", "Z") 'Leaf) '("Z", "[") 'Leaf)))
    '("[", "\\")
    ('Node
      ('Node
        ('Node ('Node 'Leaf '("\\", "]") 'Leaf) '("]", "^") 'Leaf)
        '("^", "_")
        ('Node ('Node 'Leaf '("_", "`") 'Leaf) '("`", "a") 'Leaf))
      '("a", "b")
      ('Node
        ('Node ('Node 'Leaf '("b", "c") 'Leaf) '("c", "d") 'Leaf)
        '("d", "e")
        ('Node ('Node 'Leaf '("e", "f") 'Leaf) '("f", "g") 'Leaf))))
  '("g", "h")
  ('Node
    ('Node
      ('Node
        ('Node ('Node 'Leaf '("h", "i") 'Leaf) '("i", "j") 'Leaf)
        '("j", "k")
        ('Node ('Node 'Leaf '("k", "l") 'Leaf) '("l", "m") 'Leaf))
      '("m", "n")
      ('Node
        ('Node ('Node 'Leaf '("n", "o") 'Leaf) '("o", "p") 'Leaf)
        '("p", "q")
        ('Node ('Node 'Leaf '("q", "r") 'Leaf) '("r", "s") 'Leaf)))
    '("s", "t")
    ('Node
      ('Node
        ('Node ('Node 'Leaf '("t", "u") 'Leaf) '("u", "v") 'Leaf)
        '("v", "w")
        ('Node ('Node 'Leaf '("w", "x") 'Leaf) '("x", "y") 'Leaf))
      '("y", "z")
      ('Node
        ('Node ('Node 'Leaf '("z", "{") 'Leaf) '("{", "|") 'Leaf)
        '("|", "}")
        ('Node ('Node 'Leaf '("}", "~") 'Leaf) '("~", "~") 'Leaf)))))

(I generated this structure with the help of other type families, but found that inlining the result into the source file results in much faster lookups.)

Note that each node contains two consecutive characters: this is so that we can easily decide when to stop: when the first element is less than, and the second element is greater than our input string.

The Lookup type family (and Lookup2, to make up for a lack of local declarations in type families) implements a standard binary search.

type LookupTable = Tree (Symbol, Symbol)

type family Lookup (x :: Symbol) (xs :: LookupTable) :: Symbol where
  Lookup x (Node l '(cl, cr) r)
    = Lookup2 (CmpSymbol cl x) (CmpSymbol cr x) x cl l r

type family Lookup2 ol or x cl l r :: Symbol where
  Lookup2 'EQ _ _ cl _ _     = cl -- character matches
  Lookup2 'LT 'GT _ cl _ r   = cl -- found the right node
  Lookup2 'LT _ _ cl _ 'Leaf = cl -- we're at the rightmost node (~)
  Lookup2 'LT _ x _ _ r      = Lookup x r -- go right
  Lookup2 'GT _ x _ l _      = Lookup x l -- go left

Finally, Head is just a lookup in the binary tree.

type Head sym = Lookup sym Chars

>>> :kind! Head "Wurble"
= "W"

Uncons

Next, we need to interact the AppendSymbol constraint with Head. We now turn to a type class, Uncons:

class Uncons (sym :: Symbol) (h :: Symbol) (t :: Symbol) where
  uncons :: Proxy '(h, t)

sym is our symbol, h is the head, and t is the tail. It would be nice to have a functional dependency sym -> h t, but unfortunately we can’t make that pass, as recall that the backwards dependencies of AppendSymbol are essentially hidden from the type system.

We write a single instance, which sets up the right constraints:

instance ( h ~ Head sym
	 , AppendSymbol h t ~ sym
	 ) => Uncons sym h t where
  uncons = Proxy

First, we write h ~ Head sym, which unifies h with the first element of the symbol using the binary lookup defined previously. Then, the AppendSymbol h t ~ sym constraint will trigger the solution of t, due to the now known prefix h.

The uncons member is not necessary for things to work out, but it helps illustrate the working of the type class in the REPL:

>>> :t uncons @"foo"
uncons @"foo" :: Proxy '("f", "oo")

Finally, we can write the Listify class to recursively break down a symbol into a list of characters:

class Listify (sym :: Symbol) (result :: [Symbol]) where
  listify :: Proxy result

instance {-# OVERLAPPING #-} nil ~ '[] => Listify "" nil where
  listify = Proxy

instance ( Uncons sym h t
 	 , Listify t result, result' ~ (h ': result)
	 ) => Listify sym result' where
  listify = Proxy

>>> :t listify @"Hello"
listify @"Hello" :: Proxy '["H", "e", "l", "l", "o"]

And with this, we can parse anything we’d like.

Conclusion

Of course all of the above could be done a lot more efficiently with compiler support, and there’s no reason for that not to happen at some point in the future. This post is just a proof of concept that something like this is already possible today, and the presented technique is suitable for some lightweight applications. For anything larger scale, Template Haskell is probably much better suited for the job today.

Parsing type-level strings in Haskell was originally published by Csongor Kiss at ( ) on November 28, 2018.

Deriving Bifunctor with Generics

2018-01-01T00:00:00-00:00

Overview

The problem
The solution
Conclusion
Acknowledgements

Recently, I’ve been experimenting with deriving various type class instances generically, and seeing how far we can go before having to resort to TemplateHaskell. This post is a showcase of one such experiment: deriving Bifunctor, a type class that ranges over types of kind * -> * -> *, something GHC.Generics is known not to be well suited for. The accompanying source code can be found in this gist.

The problem

The GHC.Generics module defines two representations: Generic and Generic1. The former is used to describe types of kind *, while the latter is used for * -> *. For example, the Generic1 representation is used in the generic-deriving package’s Functor derivation.

class GFunctor (f :: * -> *) where
  gmap :: (a -> b) -> f a -> f b

Then instances are defined for the generic building blocks. Whenever we have a GFunctor (Rep1 f), we can turn that into a Functor f.

With this, it’s possible to derive many useful instances of classes that range over * or * -> *. However, there’s no Generic2, so if we try to adapt generic-deriving’s Functor approach to Bifunctors, we’ll run into problems.

class Bifunctor (p :: * -> * -> *) where
  bimap :: (a -> b) -> (c -> d) -> p a c -> p b d

The type parameter p takes two arguments, but the generic Rep and Rep1 representations are strictly * -> * (in the case of Rep, the type parameter is phantom – it’s only there so that much of the structure of Rep and Rep1 can be shared, and Rep1 requires * -> *). This means that even if we defined a GBifunctor, we would need to require a GBifunctor (Rep2 p) which we could then turn into a Bifunctor p. Alas, Rep2 doesn’t exist.

Indeed, the deriving mechanism in the bifunctors package uses TH.

The solution

The solution is inspired by how lenses implement polymorphic updates. The idea is that a Lens s t a b focuses on the a inside some structure s, and if we swap that a with a b, we get a t.

Since we’re talking about Bifunctors now, we need two more type variables:

class GBifunctor s t a b c d where
  gbimap :: (a -> b) -> (c -> d) -> s x -> t x

s and t will be the generic representations, which means they are of kind * -> *. However, we’re going to be using Generic instead of Generic1, so the type parameter x is not used.

Unlike the GFunctor class, which looked exactly like Functor, this one is a lot different from Bifunctor. Also important to note that gbimap’s type signature is more polymorphic than that of bimap, so we need to ensure that our instances are properly parametric.

In an earlier version of this class, I had functional dependencies on the class that expressed this interrelation between the type variables, but I had to lose them so that more interesting instances could be defined (more on this later).

The boring instances

The first instance simply looks through the metadata node.

instance GBifunctor s t a b c d
  => GBifunctor (M1 k m s) (M1 k m t) a b c d where

  gbimap f g = M1 . gbimap f g . unM1

A sum l :+: r can be turned into l' :+: r' if we can turn l into l' and r into r'.

instance
  ( GBifunctor l l' a b c d
  , GBifunctor r r' a b c d
  ) => GBifunctor (l :+: r) (l' :+: r') a b c d where

  gbimap f g (L1 l) = L1 (gbimap f g l)
  gbimap f g (R1 r) = R1 (gbimap f g r)

And similarly, for products.

instance
  ( GBifunctor l l' a b c d
  , GBifunctor r r' a b c d
  ) => GBifunctor (l :*: r) (l' :*: r') a b c d where

  gbimap f g (l :*: r) = gbimap f g l :*: gbimap f g r

The last boring instance is for unit types, these are trivially Bifunctors.

instance GBifunctor U1 U1 a b c d where
  gbimap _ _ = id

Incoherent instances

With all of the gluing out of the way, we can now get to the meat of the problem: the actual fields in the constructors. When considering a field, we have 3 cases:

The field is of type a, and we apply the first function to turn it into a b.

instance {-# INCOHERENT #-} GBifunctor (Rec0 a) (Rec0 b) a b c d where
  gbimap f _ (K1 a) = K1 (f a)

Similarly, if it’s a c, we turn it into a d using the second function.

instance {-# INCOHERENT #-} GBifunctor (Rec0 c) (Rec0 d) a b c d where
  gbimap _ g (K1 a) = K1 (g a)

Finally, the field is neither a, nor c, so we just leave it alone.

instance {-# INCOHERENT #-} GBifunctor (Rec0 x) (Rec0 x) a b c d where
  gbimap _ _ = id

Note that these instances need to be defined with {-# INCOHERENT #-} pragmas. This is required because neither of (Rec0 a) (Rec0 b) a b c d and (Rec0 c) (Rec0 d) a b c d is more specific than the other.

However, in our case, this is not a problem, because we’re going to invoke instance resolution with polymorphic arguments, so there will be exactly one instance that matches.

Default signatures

We can now revise our original class definition, and add a default signature (DefaultSignatures). This will make Bifunctor derivable with DeriveAnyClass.

class Bifunctor p where
  bimap :: (a -> b) -> (c -> d) -> p a c -> p b d

  default bimap
    :: ( Generic (p a c)
       , Generic (p b d)
       , GBifunctor (Rep (p a c)) (Rep (p b d)) a b c d
       ) => (a -> b) -> (c -> d) -> p a c -> p b d
  bimap f g = to . gbimap f g . from

Note the line GBifunctor (Rep (p a c)) (Rep (p b d)) a b c d. Here’s where we establish the relationship between the types. This now allows us to derive a Bifunctor instance for Either:

deriving instance Bifunctor Either

For example, when looking at the Left constructor, the compiler will try to find an instance for GBifunctor (Rec0 a) (Rec0 b) a b c d. There is exactly one instance that matches this, so our incoherent instance will not bite us. This is important: if instead we wanted an instance for a concrete type, say, Either Int Int, all of our incoherent instances would match, and an arbitrary one would be picked. However, we avoid this problem by ensuring that the instance is derived for the aformentioned polymorphic form.

With this, we have a correct implementation of bimap for Either:

>>> bimap show (+ 10) (Left 10)
Left "10"
>>> bimap show (+ 10) (Right 10)
Right 20

Even better, compiled with -O1, all of the overhead from using generics is optimised away:

$fBifunctorEither_$cbimap
  = \ @ a_a3EL @ b_a3EM @ c_a3EN @ d_a3EO f_X1EN g_X1EP eta_B1 ->
      case eta_B1 of {
        Left g1_a3X5 -> Left (f_X1EN g1_a3X5);
        Right g1_a3X8 -> Right (g_X1EP g1_a3X8)
      }

A few more instances

The above deriving mechanism is naive: it only looks at fields whose types is exactly a or b. But we can do better: what if the field is a Maybe a? Surely we can turn that into a Maybe b. Or if it’s an Either a b, we can turn that into an Either c d, since it has a Bifunctor instance.

The following three instances do exactly that.

instance {-# INCOHERENT #-} Bifunctor f
  => GBifunctor (Rec0 (f a c)) (Rec0 (f b d)) a b c d where
  gbimap f g (K1 a) = K1 (bimap f g a)

instance {-# INCOHERENT #-} Functor f
  => GBifunctor (Rec0 (f c)) (Rec0 (f d)) a b c d where
  gbimap _ g (K1 a) = K1 (fmap g a)

instance {-# INCOHERENT #-} Functor f
  => GBifunctor (Rec0 (f a)) (Rec0 (f b)) a b c d where
  gbimap f _ (K1 a) = K1 (fmap f a)

instance {-# INCOHERENT #-} Bifunctor f
  => GBifunctor (Rec0 (f a a)) (Rec0 (f b b)) a b c d where
  gbimap f _ (K1 a) = K1 (bimap f f a)

instance {-# INCOHERENT #-} Bifunctor f
  => GBifunctor (Rec0 (f c c)) (Rec0 (f d d)) a b c d where
  gbimap _ g (K1 b) = K1 (bimap g g b)

Now we can derive even more interesting Bifunctor instances.

data T a b = T1 (Maybe a) a (Either a b) | T2 (Maybe b)
  deriving (Generic, Bifunctor)

Conclusion

We have seen a technique for approximating a hypothetical Generic2 representation with only using Generic. Of course there was nothing specific about the number 2, we can easily generalise this to any fixed number of parameters.

I’m planning on writing a post about a further generalisation of this idea, which allows us to talk about types that have an arbitrary number type parameters (unlike here, where it’s a fixed number), which I used in the generic-lens library, to allow for type changing lenses over any type parameter (thanks to the more elaborate extra machinery, there is no need for incoherent instance resolution).

It would be interesting to see how far this can be pushed before hitting a roadblock that would truly require a bespoke GenericN representation.

Acknowledgements

Thanks to @adituv for pointing out that two instances were missing.

Deriving Bifunctor with Generics was originally published by Csongor Kiss at ( ) on December 31, 2017.

Announcing generic-lens 0.5.0.0

2017-12-10T00:00:00-00:00

Overview

Overview
- Examples
- mtl
Performance
Quick note (migration)
Acknowledgements

The generic-lens library provides utilities for deriving various optics for your datatypes, using GHC.Generics. In this post I’ll go over some of the features and provide examples of using them.

Overview

Lenses have proven to be an exteremely powerful tool in the Haskell ecosystem. generic-lens uses GHC.Generics to derive lenses and prisms on the fly, only when they are needed. These optics are highly polymorphic, and can be used with all types that are of the right shape. Extra care has been taken to keep type errors readable.

Examples

To get started, we will need the following extensions:

{-# LANGUAGE DataKinds        #-}
{-# LANGUAGE DeriveGeneric    #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE TypeFamilies     #-}

And the following imports

import Control.Lens
import Data.Generics.Product
import GHC.Generics

Consider the following datatype:

data Human a
  = Human
    { name    :: String
    , age     :: Int
    , address :: String
    , other   :: a
    } deriving (Generic, Show)

field

We can access the name field:

>>> Human "John" 18 "London" True ^. field @"name"
"John"

We can update fields too, even changing types where possible (when the type of the field is a type parameter of the datatype):

>>> Human "John" 18 "London" True & field @"other" %~ show
Human {name = "John", age = 18, address = "London", other = "True"}

In case of sum types, it only makes sense to have a lens on the fields that appear in every constructor. Trying to use field to get a lens for a partial field is a type error.

Note that the field lens works with DuplicateRecordFields, which means that record fields can actually be shared, and we can get a reusuble lens for all cases without code duplication.

typed

We can directly reference a field by its type, as long as the type is unique in the structure.

>>> Human "John" 18 "London" True ^. typed @Bool
True

>>> Human "John" 18 "London" True ^. typed @String

<interactive>:34:34: error:
    • The type Human Bool contains multiple values of type [Char].
      The choice of value is thus ambiguous. The offending constructors are:
      • Human

    • In the second argument of ‘(^.)’, namely ‘typed @String’
      In the expression: Human "John" 18 "London" True ^. typed @String
      In an equation for ‘it’:
          it = Human "John" 18 "London" True ^. typed @String

position

When the above two fail, and we have a product type, we can specify the field of interest by its position.

data MyTuple a b = MyTuple a b deriving (Generic, Show)

>>> MyTuple 10 20 & position @1 .~ "hello"
MyTuple "hello" 20

super (row polymorphism)

Given two records, where the set of fields of one is the subset of that of the other, we can talk about a structural subtype relationship. The super lens allows us to treat the subtype as the supertype - without forgetting the original structure.

data Small
  = Small
    { small :: Int
    } deriving (Generic, Show)

data Large
  = Large
    { small :: Int
    , large :: String
    } deriving (Generic, Show)

smallFun :: Small -> Small
smallFun (Small n) = Small (n + 10)

(Here, we need the {-# LANGUAGE DuplicateRecordFields #-} extension in addition to the previous ones.)

>>> Large 10 "foo" & super %~ smallFun
Large {small = 20, large = "foo"}

Or we can simply upcast:

>>> Large 10 "foo" ^. super :: Small
Small {small = 10}

>>> Small 10 ^. super :: Large

<interactive>:53:13: error:
    • The type 'Small' is not a subtype of 'Large'.
      The following fields are missing from 'Small':
      • large

_Ctor

We can also obtain prisms that focus on individual constructors:

>>> Human "John" 18 "London" True ^? _Ctor @"Human"
Just ("John",18,"London",True)

>>> Human "John" 18 "London" True ^? _Ctor @"Human" . position @3
Just "London"

mtl

So far, we haven’t provided any type signatures. Indeed, everything can be inferred by the compiler. However, because these combinators are highly polymorphic, it might be interesting to use them in a polymorphic context.

f :: (MonadReader env m, HasField' "username" env String) => m String
f = view (field @"username")

This function is now polymorphic not just in the monad stack it will eventually run in, but also in the type of the environment.

The type of field is

field :: HasField field s t a b => Lens s t a b

HasField' (similarly to Lens') is a type synonym for HasField field s s a a.

For a more comprehensive overview and more examples, please have a look at the library on hackage, or on github.

Performance

An important question when evaluating such high-level abstractions is whether the abstraction comes at the cost of performance. Fortunately, GHC optimises away all of the overhead of the generic transformations, leaving us with code that is equivalent to what we would’ve written manually.

This can be verified by comparing the generated core of both the manually written lens and the generated one. However, it happened multiple times during development that a small change (such as eta-reduction) broke the optimisation. Joachim Breitner’s excellent inspection-testing tool, which is now integrated into the automated test suite, is making sure that the optimisation happens by automatically doing this comparison. This tool has been invaluable in ensuring the performance guarantees, without having to manually inspect the generated core after every single commit. The tests can be found here.

It’s important to mention that as of this release, only the lenses are optimised away completely, the prisms still have some leftover overhead. This is planned to be fixed in a future release.

Quick note (migration)

In case you were already using the library, there are some breaking changes in 0.5.0.0. Namely, all the Has* classes have been extended from 3 type parameters to 5. Auxiliary constraint synonyms are provided, and migration should be relatively simple:

f :: HasField field a record => ...

becomes

f :: HasField' field record a => ...

Notice the ' at the end of the class name, and the swapping of the last two arguments.

Acknowledgements

Thanks to Matthew Pickering for useful comments on a draft of this post.

Announcing generic-lens 0.5.0.0 was originally published by Csongor Kiss at ( ) on December 10, 2017.

Well-typed printfs cannot go wrong

2017-9-25T00:00:00-00:00

Overview

The problem
Type-level parsing
How the sausage gets made: computing the output type
Conclusion

One of the classic examples that keeps coming up when talking about dependently typed programming languages is the “safe” printf function – one that ensures that the number and type of arguments match the requirement in the format specification.

In languages like Idris, this is just a function that takes a format string, and returns the type of arguments required for constructing the formatted output string.

  format "A number: %d, and a string: %s" : Int -> String -> String

Other languages, like rust, solve this by various means of metaprogramming: writing a program (macro) that runs at compile-time, generating the program to be executed at runtime.

What these two approaches have in common is that they both operate on strings that are statically available to the compiler. The aim of this post is to show another way of achieving the same result, with tools that are available in PureScript – a strongly-typed functional language, with no dependent types.

The problem

We want to write a program that takes a format string, some number of arguments, and returns the result of inserting the arguments at their specified places in the format string, and does all this in a type-safe way.

> :t format @"Wurble %d %d %s"
Int -> Int -> String -> String

> format @"Wurble %d %d %s" 10 20 "foo"
"Wurble 10 20 foo"

> format @"Wurble %d %d %s" 10 20 30
Error found:

  Could not match type

    String

  with type

    Int

while trying to match type Function String
  with type Function Int

The @ symbol before the string is the proxy syntax introduced in 0.12 which provides a concise way of passing types around. The format strings are actually type-level literals – but more on this later.

Crucially, we need to compute a type from some input, but because PureScript has no dependent types, values and functions in the traditional sense are not available for evaluation at compile-time. However, there is a way to interact with the compiler: via the type-checker.

The solution therefore is to encode this computation in the types, and have the type-checker evaluate it for us as part of type-checking. Luckily, PureScript allows string literals in types (these are types whose kind is Symbol).

Thus, constructing our printf function comprises two steps:

parse the input Symbol into a list of format tokens
generate the function from the format list that will then assemble the output string

Type-level parsing

For the sake of simplicity, we’re going to focus on two types of format specifiers: decimals (%d) and strings (%s).

We represent these cases with a custom kind, which is like a regular algebraic datatype, but lifted to the type-level. This means that these constructors can be used in types.

foreign import kind Specifier

foreign import data D   :: Specifier
foreign import data S   :: Specifier
foreign import data Lit :: Symbol -> Specifier

Of course, apart from the format specifiers %d and %s, everything else is a literal, which we account for by wrapping them in the Lit type constructor.

The foreign import bit means that we’re introducing types here that have no constructors. That is to say, it’s impossible to construct a value of type D and S. We’ll see later how it is still possible to carry these types around in terms (hint: proxies).

Furthermore, we need a way of representing a sequence of these specifiers, for which we introduce another kind:

foreign import kind FList

foreign import data FNil  :: FList
foreign import data FCons :: Specifier -> FList -> FList

With this, we can now write types like FCons D (FCons (Lit " foo") FNil), corresponding to the string %d foo.

Kind-polymorphism is not supported by the current version (0.12) of PureScript, so we can’t define a parametric type-level list once and for all – we need a new one for each type we want to store in lists. With this, and some syntactic sugar, we would be able to write (as we can in Haskell today) [D, "foo"]. This limitation is likely to be removed in a future version of the compiler.

With these building blocks defined, now we have a vocabulary for talking about the parser itself: it is a function that takes a Symbol as an input, and returns a FList. We encode the computation in the following type class:

class Parse (string :: Symbol) (format :: FList) | string -> format

The functional dependency string -> format states that the input string determines the ouput format. This bit is crucial, as this is what tells the compiler that knowing string is sufficient in determining what the value of format is. It is then our task to ensure that this dependency indeed holds, when writing out the instances.

To deconstruct the input symbol, we use the following type class available in 0.12:

class ConsSymbol (head :: Symbol)
                 (tail :: Symbol)
                 (sym :: Symbol) |
                 sym -> head tail, head tail -> sym

The interesting functional dependency here is the sym -> head tail, which, given some symbol, deconstructs it into its head (the first character) and its tail – the rest.

The parser is like a state machine, with the following legal states:

State 1: found a non-% character
State 2: found a % character

One possible way of representing these states is by having a separate type class to deal with each.

Since in our simplified example, we know that the specifier symbols can only be single characters, we can define the second state as:

class Parse2 (head :: Symbol) (out :: Specifier) | head -> out

That is, it takes a symbol, and returns the matching specifier. The implementation is straightforward:

instance parse2D :: Parse2 "d" D
instance parse2S :: Parse2 "s" S

This is a partial function, which means that format strings that contain unsupported specifier tokens will simply fail to compile.

The first state is more complicated, as it can consume an arbitrary number of characters, so we pass it the remaining string (tail) as well.

class Parse1 (head :: Symbol) (tail :: Symbol) (out :: FList) | head tail -> out

Parse1 represents the parsing state where we have the current character head, the rest of the input string tail, and we know that the previous character was not a %.

The first case is when the tail is empty. In this case, we just return the current character as the literal in a singleton list:

instance parse1Nil :: Parse1 a "" (FCons (Lit a) FNil)

The second case is more interesting. This is when we find a %, so we need to invoke the other function, Parse2, which handles parsing the specifier itself. To do that, we use ConsSymbol to split our current tail s into its head h and tail t. h contains the format specifier, which we pass on to Parse2. Then, recursively invoke Parse on t to parse the rest of the input. In addition to returning spec consed to rest, we also put an empty string literal at the head of the output list: this is to maintain the invariant that the head of the output list always contains a string literal. This invariant will be useful for the last case…

else instance parse1Pc ::
  ( ConsSymbol h t s
  , Parse2 h spec
  , Parse t rest
  ) => Parse1 "%" s (FCons (Lit "") (FCons spec rest))

…when we match any other character, i.e. other than %. Since we’re in Parse1, that means that the current character needs to be in a string literal. For this, we first recursively parse the tail s into FCons (Lit acc) r. The reason we want to know that at the head of parsing the remaining string is a Lit is so that we can prepend the current character to that literal – we need to rebuild long string literals character-by-character after all. This is where the invariant from the previous two cases is useful: we don’t have to handle the cases where the head is not a Lit, because the recursive calls guarantee that it is. acc is thus the tail of the string literal we’re currently parsing, so we put it together with the current character by ConsSymbol o acc rest (recall that this type class can both construct and deconstruct symbols via its functional dependencies). Then we simply return Lit rest along with r.

else instance parse1Other ::
  ( Parse s (FCons (Lit acc) r)
  , ConsSymbol o acc rest
  ) => Parse1 o s (FCons (Lit rest) r)

Notice how these instances actually overlap. In the third case, we can easily imagine a particular instantiation of o and r such that it matches the instance head in the second case. In other words, when the current character is %, both parse1Pc and parse1Other match (because parse1Other is more general).

To make sure that the instances are selected in the order we want them to be, we use instance chains. That is, by writing instance A else instance B we tell the compiler to try to match instance A first, and if it fails, then try B. This is a new feature in PureScript 0.12, and a very powerful one – it allows us to avoid the overlapping instance problem for good.

Finally, we need to actually kick off the parser. We do this by invoking it in the first state.

instance parseNil ::
  Parse "" (FCons (Lit "") FNil)
else instance parseCons ::
  ( ConsSymbol h t string
  , Parse1 h t fl
  ) => Parse string fl

How the sausage gets made: computing the output type

But how do we know how many arguments we need to pass to the formatter? It depends on the format string! No surprises here: just like all the previous type-level computations, this one will also be encoded in a type class with a functional dependency.

class FormatF (format :: FList) fun | format -> fun where
  formatF :: @format -> String -> fun

The @ symbol is special syntax, and in this case, it means that the formatF function takes an FList (format) as an input. But because FList is a custom kind, it has no value-level inhabitants. So, how can we still get something whose type mentions format? This is what @ does – it’s a proxy for a type. Its value is isomorphic to Unit, and carries no information, other than its type. Notice that it works for any kind – indeed, proxies are currently a special-cased type in PureScript, in that they are kind-polymorphic.

Thus formatF takes a format list, and an accumulator string, and returns some fun – this type depends on the actual format list.

Starting with the base case, when there’s nothing to print, simply just return the accumulated formatted string.

instance formatFNil :: FormatF FNil String where
  formatF _ str = str

When the head of the list is D, we know that we will need an Int argument, and the rest of the function’s type can be computed by recursing on the tail of the list. As for the implementation, since the return type is now refined to be of the form Int -> fun, we are allowed to construct a lambda that takes the Int, and appends it to the end of the accumulator, then recurses on the rest. The implementation of S is identical, and is omitted for brevity.

instance formatFConsD ::
  FormatF rest fun
  => FormatF (FCons D rest) (Int -> fun) where
  formatF _ str
    = \i -> formatF @rest (str <> show i)

Handling literals (Lit) is left as an exercise for the reader.

Conclusion

Finally, as a matter of convenience, we can wrap the above type classes into one, that serves as a bridge between the parser and the formatter, as such:

class Format (string :: Symbol) fun | string -> fun where
  format :: @string -> fun

instance formatFFormat ::
  ( Parse string format
  , FormatF format fun
  ) => Format string fun where
  format _ = formatF @format ""

And that’s it! It might be instructional to try and work out FormatF’s instance resolution for a few simple examples by hand, to get a better idea why this works. A fully working implementation of the code in this post can be found on github.

Well-typed printfs cannot go wrong was originally published by Csongor Kiss at ( ) on September 25, 2017.

Time travel in Haskell for dummies

2015-10-02T00:00:00-00:00

Overview

How?
The repMax problem
Wait, what?
States travelling back in time
- What are states anyway?
Finally, the time machine, TARDIS

Browsing Hackage the other day, I came across the Tardis Monad. Reading its description, it turns out that the Tardis monad is capable of sending state back in time. Yep. Back in time.

How?

No, it’s not the reification of some hypothetical time-travelling particle, rather a really clever way of exploiting Haskell’s laziness.

In this rather lengthy post, I’ll showcase some interesting consequences of lazy evaluation and the way to work ourselves up from simple examples to ’time travelling’ craziness through different levels of abstraction.

The repMax problem

Imagine you had a list, and you wanted to replace all the elements of the list with the largest element, by only passing the list once. You might say something like “Easier said than done, how do I know the largest element without having passed the list before?”

Let’s start from the beginning: – First, you ask the future for the largest element of the list, (don’t worry, this will make sense in a bit) let’s call this value rep (as in the value we replace stuff with).

Walking through the list, you do two things:

replace the current element with rep
’return’ the larger of the current element and the largest element of the remaining list.

When only one element remains, replace it with rep, and return what was there originally. (this is the base case)

Right, at the moment, we haven’t acquired the skill of seeing the future, so we just write the rest of the function with that bit left out.

repMax :: [Int] -> Int -> (Int, [Int])
repMax [] rep = (rep, [])
repMax [x] rep = (x, [rep])
repMax (l : ls) rep = (m', rep : ls')
  where (m, ls') = repMax ls rep
        m' = max m l

So, it takes a list, and the rep element, and returns (Int, [Int])

repMax [1,2,3,4,5,3] 6 gives us (5, [6,6,6,6,6,6]) which is exactly what we wanted: the elements are replaced with rep and we also have the largest element. Now, all we need to do is use that largest element as rep:

doRepMax :: [Int] -> [Int]
doRepMax xs = xs'
  where (largest, xs') = repMax xs largest

Wait, what?

This can be done thanks to lazy evaluation. Haskell systems use so-called ’thunks’ for values that are yet to be evaluated. When you say (min 5 6), the expression will form a thunk and not be evaluated until it really needs to be. Here, rep can be thought of as a reference to a thunk. When we tell GHC to put largest in all slots of the list, it will in fact put a reference to the same thunk in those slots, not the actual data. As we pass the list, this thunk is building up with nested max expressions. For [1,2,3,4], will end up with a thunk: max 1 (max 2 (max 3 4)). A reference to this thunk will be placed everywhere in the list. By the time we finished traversing the list, the thunk will be finished too, and can be evaluated. (Before finishing, the thunk has the form similar to max 1 (_something_) where _something_ is the max of the rest of the list. This obivously can not be evaluated at this point)

How about generalising this idea to other data structures?

There’s an old saying in the world of lists

“Everything’s a fold”.

Indeed, we could easily rewrite our doRepMax function using a fold:

foldmax :: (Ord a, Num a) => [a] -> [a]
foldmax ls = ls'
  where 
    (ls', largest) 
      = foldl (\(b, c) a -> (largest : b, max a c)) ([], 0) ls

Brilliant! Now we can use this technique on everything that is Foldable! Or can we?

Taking a look at the type signature of the generalised foldl (from Data.Foldable): Data.Foldable.foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b we realise that the returned value’s structure b is independent from that of the input t a. The reason we could get away with this in our fold example was that we knew we were dealing with a list, so we used the : operator explicitly to restore the structure.

No problem! There exists a type class that does just what we want, that is it lets us fold it while keeping its structure. This magical class is called Traversable.

{-# LANGUAGE DeriveFunctor,
             DeriveFoldable,
             DeriveTraversable #-}

data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a) 
  deriving (Show, Functor, Foldable, Traversable)

– Thankfully, GHC is clever enough to derive Traversable for us from this data definiton. (But it wouldn’t be too difficult to do by hand anyway)

Traversable data structures can do a really neat trick (among many others): mapAccumR :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c)

This function is like combining a map with a fold (and so all Traversables also need to be Functors and Foldables). We take a function (a -> b -> (a, c)), an initial a and a Traversable of bs (t b).

The elements will be changed with their respective cs. (the one calculated by (a -> b -> (a, c))) So c is a perfect place for us to put our rep (the largest element in this case)

Apart from the final Traversable t c, it also returns the accumulated as (that’s where we return the largest).

generalMax :: (Traversable t, Num a, Ord a) => t a -> t a
generalMax t = xs'
  where
    (largest, xs')
      = mapAccumR (\a b -> (max a b, largest)) 0 t

This generalisation gives us new options! What we’ve been doing so far is we’ve used a, b and c as the same types (as, say Ints).

For instance, if we want to replace all the elements with the average of them, then we can accumulate the sum and the count of elements in a tuple (a will then take the role of this tuple) and c will be the sum divided by the count, for which we’re going to ask the future again!

generalAvg :: (Traversable t, Integral a) => t a -> t a
generalAvg t = xs'
  where 
    avg = s `div` c
    ((s, c), xs') 
      = mapAccumR (\(s', c') b -> ((s' + b, c' + 1), avg)) (0,0) t

And so on, we can do all sorts of interesting things in a single traversal of our data structures.

States travelling back in time

What are states anyway?

In Haskell, whenever we want to write functions that operate on some sort of environment or state, we write these functions in the following form: statefulFunction :: b -> c -> d -> s -> (a, s) that is, we take some arguments (b, c, d here), a state s, and return a new, possibly modified state along with some value a. Now, this involves writing a lot of boilerplate code, both in the type signatures and in the actual code that is using the state.

For example, using the state as a counter:

statefulFunction arg1 arg2 arg3 counter =
  (arg1 + arg2 + arg3, counter + 1)

bindStatefulFunctions ::
  (s -> (a, s)) ->
  (a -> s -> (b, s)) ->
  s -> (b, s)
bindStatefulFunctions f1 f2 = \initialState ->
  let (result, updatedState) = f1 initialState
  in f2 result updatedState

Note that f2 takes an extra a, that’s the output of the first function. That’s why this function is called bind, we bind the output of the first function to the input of the second while passing the modified state.

The State monad essentially does something like the above code, but hides it all and makes the state passing implicit. Also, being a monad, gives us the all so convenient do notation!

State s a is basically just a type synonym for s -> (a, s), so our previous example could be written as statefulFunction :: b -> c -> d -> State s a

and bindStatefulFunctions we get for free from State (known as >>= for monads)

Now we can do:

statefulFunction arg1 arg2 arg3 = do
  counter <- get
  put (counter + 1)
  return (arg1 + arg2 + arg3)

(Did you know that Haskell is also the best imperative language?) Notice how the state is not explicitly passed as an argument (thus our function is partially applied), but is bound to counter by the get function. Put then puts the updated counter back in the state. Return then just makes sure that what we get out of is wrapped back in the State monad.

The nice thing about the State monad is that all the computations we do within it are essentially just partially applied functions, so they can’t be evaluated until provided with an initial state, which will then magically flow through the pipeline of computations, each doing their respective modifications in the meantime.

mapAccumR does a series of stateful computations (in nature, but it’s not using the State monad), where it takes a value and a state, then returns a new value with a modified state. (Accum refers to the fact that this state can be used as an accumulator as we traverse the data)

mapAccumR :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c)

a is that state here, that is what we used to store the largest element. This state, however, travels forward in time, so to speak, as we go through the list. The trick we do only happens at the end, when we feed it its own output. We can do so thanks to lazy evaluation.

So the State monad passes its s from computation to computation, that’s how these computations are bound.

Imagine using the same laziness self-feeding trick, but for passing the state:

reverseBind stateful1 stateful2
  = \s -> (x', s'')
  where (x, s'') = stateful1 s'
        (x', s') = stateful2 x s

So first we run stateful1 with the state modified by stateful2! Then we run stateful2 with stateful1’s output. Finally, we return the state after running stateful1 along with the value x' from stateful2. Note that because of the way this binding is done, stateful1’s ouput state will actually be the past of stateful1. (That is, whatever we do with the state in stateful1, will be visible to the computations preceding stateful1, just like how stateful2’s effects are seen in stateful1. Lazy evaluation rocks!)

Coming from an imperative background, this can be thought of as stateful1 putting forward references to the values it uses from the state, and once those values are actually calculated in the future, stateful1 will be able to do whatever it wanted. These references are not explicit though as they would be in C (using pointers, for example), but implicitly placed there by GHC as thunks.

That also means whatever we do with these values has to be done lazily. (an example below)

The above code is a modified version of the monadic binding found in the rev-state package (which is in turn a modification of the original State monad by reversing the flow of state).

Finally, the time machine, TARDIS

So we have the State monad, of which the state flows forwards, then we have the Rev-State, which sends the state backwards. So what do we get if we combine these two? Yes, a time machine! Also known as the Tardis monad: it is in fact a combination of the State and Rev-State monads with some nice functions to deal with the bidirectional states.

I say states, because naturally, we have data coming from the future and data coming from the past, and those make two (a backwards travelling and a forwards travelling state).

These could be of different types, say we can send Strings back in time and Ints to the future.

A single-pass assembler: an example

Writing an assembler is relatively straightforward. We go through a list of assembly instructions and turn them into their binary equivalent for the given CPU architecture.

However, there are some instructions that we can’t immediately convert. One of such instructions is a label for branching. (jumps) For these labels, we need a symbol table.

import qualified Data.Map.Strict as M

type Addr = Int
type SymTable = M.Map String Addr -- map label names to their addresses


data Instr = Add
            | Mov
            | ToLabel String
            | ToAddr Addr
            | Label String
            | Err
            deriving (Show)

Instr is a rather rudimentary representation of assembly instructions, but it does the job for us now.

What we want to have is a function that takes a list of Instrs and returns a list of [(Addr, Instr)] and also replace all the ToLabels with ToAddrs that point to the address of the label. If the label is never defined, we put an Err there. (In real life, you would use some ExceptT monad transformer to handle such errors.)

runAssembler :: [Instr] -> [(Addr, Instr)]

Jumping to a label that is already defined is easy, we look it up in our SymTable and convert ToLabel to ToAddr. This sounds like an application of the State monad, doesn’t it? When we encounter a label definition, just add it to the state (SymTable). Done!

The problem arises from the fact that some labels might be defined after they are used. The ‘else’ block of an if statement will typically be done like this. Implementing this in C, you could remember these positions and at the end, fill in the gaps with the knowledge you have acquired. Thunks, anyone?

I’ll just use a Rev-State monad and send these definitions back in time. Simple enough, right?

So at this point, we can see that we will need both types of these states: one that’s travelling forward and one that is going backwards. And that is exactly what the Tardis monad is!

Labels will not be turned into any binary, instead the next actual instruction’s address will be used.

type Assembler a = Tardis SymTable SymTable a

Right, our runAssembler function will run some assemble function in the Tardis monad. (That is, it will give it the initial states and extract the final value at the end).

runAssembler asm = instructions
  where (instructions, _)
          = runTardis (assemble 0 asm) (M.empty, M.empty)

The assemble function turns a list of instructions to [(Addr, Instr)] in the Assembler monad (which is a synonym for Tardis SymTable SymTable). What’s that 0 doing there, you ask?

We need to keep track of the address we will use for the next instruction. This is because of labels. When we encounter a regular instruction, we put that at the provided address, then increment that address by 1. If a label comes around, we put it in the State then continue without incrementing the address.

assemble :: Addr -> [Instr] -> Assembler [(Addr, Instr)]
assemble _ [] = return []
-- label found, update state then go on
assemble addr (Label label : is') = do
  modifyBackwards (M.insert label addr) -- send to past
  modifyForwards (M.insert label addr)  -- send to future
  assemble addr is' -- assemble the rest of the instructions
-- jump to label found, replace with
-- jump to address
-- then do the rest starting at (addr + 1)
assemble addr (ToLabel label : is') = do
  bw <- getFuture
  fw <- getPast
  let union = M.union bw fw -- take union of the two symbol tables
      this = case M.lookup label union of
                Just a' -> (addr, ToAddr a')
                Nothing -> (addr, Err)
  rest <- assemble (addr + 1) is'
  return $ this : rest
-- regular instruction found,
-- assign it to the address
-- then do the rest starting at (addr + 1)
assemble addr (instr : is') = do
  rest <- assemble (addr + 1) is'
  return $ (addr, instr) : rest

Now we come up with some test instructions:

input :: [Instr]
input = [Add,
         Add,
         ToLabel "my_label",
         Mov,
         Mov,
         Label "my_label",
         Label "second_label",
         Mov,
         ToLabel "second_label",
         Mov]

…and we can try running the assembler on this data:

> runAssembler input

> [(0,Add),(1,Add),(2,ToAddr 5),(3,Mov),(4,Mov),(5,Mov),(6,ToAddr 5),(7,Mov)]

Yay! Just what we wanted!

IO doesn’t mix with the future! (The past is fine)

Be careful about what you do with the state coming from the future. Everything has to be lazily passed through.

You might be tempted to use the TardisT monad transformer to interleave IO effects in your time-travelling code. Most IO computations, however are strict.

Let’s say you want to get the label from the future and print its address. IO’s print will try to evaluate its argument (which is a partial thunk at this point). It will block the thread until the evaluation is completed, which will result in the program breaking, as the thread block prevents it from progressing further. In this case, I’d advise the use of a Writer monad which has a lazy mechanism, and the results can be printed at the end using IO.

Thanks

Thanks for reading this lengthy post, in which we saw how we can mimic the use of references in pure Haskell code (altough time-travel is an arguably better name for this). This comes at a price though: accumulating unevaluated thunks can use up quite a bit of memory, so be careful if you want to use these techniques in a memory critical environment.

If you find any bugs or mistakes, please make sure to let me know!

Time travel in Haskell for dummies was originally published by Csongor Kiss at ( ) on October 02, 2015.