ExplicitForAll complete

[Ian Lynagh]

Hi Iavor,

Thanks for your comments.

On Sun, Nov 21, 2010 at 06:25:38PM -0800, Iavor Diatchki wrote:
> 
> * Why is "forall" promoted to a keyword, rather then just being
> special in types as is in all implementations?  I like the current
> status quo where "forall" can still be used in value expressions.

You can't use "case" as a type variable, so I don't see why you should
be able to use "forall" as an expression variable.

I imagine that the reason implementations currently allow it is to
minimise the chance of an extension breaking existing programs, but I
believe that when making new versions of the standard we should, where
feasible, write them in the way that they would have been written if the
previous versions had never existed.

> * It seems that allowing "superflous" values in "foralls" could be
> useful for some future extensions.  For example, if we had scoped type
> variables and explicit type application, then it may make sense to
> have quantified variables that do not appear
> in the rest of the type (but do appear in the definition of the
> function).  I guess, we could revise things again if that was to ever
> happen but still, it seems to me that this might be more appropriate
> as an "unused variable" warning, rather then an error?

"Eq a => Int" isn't a valid type, so I don't think "forall a . Int"
should be either. As you say, it's possible that future extensions will
generalise this.

> *  Is there any case where an empty "forall" is useful, and if not,
> why allow it?  I guess it is a way to make it explicit that a value is
> monomorphic but i think that types like "forall. Int" look odd.

I don't mind either way.


Thanks
Ian