Freqently Asked Questions

Will EH syntax support feature XXX, also present in Haskell?

EH syntax is kept simple for the following reasons:

• It is designed to closely resemble the abstract syntax over which relevant analyses take place, like type checking. It is kept as simple as possible, as to allow the implementation of sucn analyses to be simple as well. Stuff is already complicated enough.
• Experimentation can be done in a barebones setting.
• Haskell syntax provides a richer syntax, that is the place to make our notational life easier.

So, in general the answer is no if the syntax can be broken down to simpler syntactic constructs with sugar on top.

Why are bindings in EH syntax not generalized properly?

Bindings in EH syntax are not split up in smaller chunks when they are mutual exclusive. Dependency analysis is assumed to have taken place already (for example, by the translation from HS to EH). Again, the reason is simplicity.

For example, the following expression does not type-check:

let id = \x -> x
    y = id 3
    z = id (3,3)
in 0

The reason is that id, y and z are generalized together, which means that the uses of the id function in y and z use the non-generalized type of id. So, suppose that the type of id is v1 -> v1 (with monomorhpic v1). Then y causes a unification of v1 with Int and z causes a unification of v1 to (Int,Int), which does not match.

However, if we put the id function in a separate binding-group:

let id = \x -> x
in let
    y = id 3
    z = id (3,3)
in 0

The following happens: id is generalized to forall a . a -> a. In y, id is instantiated to some fresh v1 -> v1, where v1 is unified with Int (is ok). Then, in z, id is instantiated again to some fresh v2 -> v2, where v2 is unified with (Int,Int) (which is ok).

What is the relationship with UHC, the Utrecht Haskell Compiler?

UHC has been subsumed by the EHC project. A stable version of a EHC variant supporting Haskell plus extensions will be available under the name UHC.

-- AtzeDijkstra - 20 Nov 2006