| For example hugs does not allow the following two examples:
|
| type HashFun = (forall el. el -> Int)
|
| type Parms el = el -> (forall el. el -> Int)
|
| but ghc compiles it just fine.
Nothing in the Hugs manual suggests that you can use forall in a type
synonym, so I don't regard this as a bug. But I agree that it would
be useful to allow this kind of behavior, so let's take your message
as a request for a new extension.
In fact it's not the first, and the same point came up in another
discussion that I had a few days ago. My comments then might also be
interesting for you here:
The reasons for this restriction in Hugs were primarily implementation
oriented. Intuitively, if you allow type synonyms to contain foralls,
then the implementation must expand all synoynms whenever it sees one
to ensure that types of the appropriate form are used whenever possible.
This isn't difficult to do, but I thought that it would be more
attractive to define a kind system extension to reflect this in a more
direct manner. For example, * is the normal set of monotypes, [types
like forall a. a -> a] have kind *1 and [types like (forall a. [a])->Int]
have kind *2. These kinds are related by subkinding, * < *1 < *2, and
the (->) constructor for function types is overloaded at the following
kinds:
* -> * -> * (standard function space constructor)
*1 -> *2 -> *2 (rank 2 constructor)
To cut a long story short, I never finished exploring this idea. Perhaps
it is easier simply to expand all type synoynms. Whichever solution is
adopted, I share your view that it would be very useful to allow uses of
forall in type synonyms. Alas, because of the representations that Hugs
uses, there is no quick fix for this.
All the best,
Mark
