On 11/22/10 06:41, Ian Lynagh wrote:
On Sun, Nov 21, 2010 at 06:25:38PM -0800, Iavor Diatchki wrote:
* 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.
In functions with typeclass overloading, the typeclass must be picked in order to call the function, even if this means resorting to defaulting. In functions with parametric polymorphism (no (context)=>), it never needs to be decided. For example, "exitFailure :: IO a" can be called on a line where the return value is never used (besides being unified with (>>=) types and stuff); it can remain "a". So I don't think that analogy works for me. Still not sure whether we should allow "forall a . Int" or not (no strong opinions either way). I think it would compile and type-inference fine (although GHC experts may correct me.. and/or people familiar with other compiler implementations too).
* 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.
It looks odd, but it would be annoying (to tools and otherwise) to exclude it from being allowed, even if it's not used much. P.S. IMHO capitalization, ExplicitForAll vs ExplicitForall, let's stick to one. The extension is written ExplicitForall. -Isaac