ml at isaac.cedarswampstudios.org
Mon Nov 22 14:36:51 EST 2010
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
>> * 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.
More information about the Haskell-prime