Ralf Hinze wrote:

> One could also argue that the culprit is Haskell's interpretation of
> type variables of which Report (p. 34) says: `[...] the type variables
> in a Haskell expression are all assumed to be universally quantified
> [..]'. Here is an even more irritating list of possibilities ...

> and so forth ... A solution could be to consider the type variables
> universally quantified at the _outermost_ possible level (currently
> it's the innermost). So `f e1 ... en = e' means `forall a1 .. am.f e1
> ... en = e' where the `ai's are the type variables occuring free in the
> definition. If we had explicit syntax for universal quantification
> (which I consider absolutely necessary) the former interpretation could
> be recovered using explicit quantifiers: ... (f :: forall a.a -> a)
> ...
>

  This sounds great, but it could break old code, of course.  This would have a
different type under Ralf's proposal than Haskell 1.4:
    (id :: a -> a, id :: a -> a)
However, I think something like it is the only sane way to go.  Whatever we do, type
variables should scope consistently.  With proposal "A" as is (such that it wouldn't
break old code, and just like in hugs 1.3c), a type variable would scope differently if
it was in a pattern verses being in an expression.  Ralf's proposal fixes that nicely,
and I don't think the cost in old code here would be very high.

--Jeff


Reply via email to