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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Reply via email to