[ghc-steering-committee] Discussion on #155 Type Variable in Labmdas

Iavor Diatchki iavor.diatchki at gmail.com
Wed Apr 3 16:45:48 UTC 2019


perhaps it is time to come up with some sort of decision here.  Based on
the replies to this thread we seem to have the following opinions:
  1. Eric and Richard seem to be quite keen on the feature
  2. Simon is on the fence, but likes it because it introduces System F
vocabulary to Haskell
  3. I am skeptical of the proposal as is, as I think it adds additional
complexity to the language (more non-orthogonal features) without
significant payoff.

Does anyone else have anything else to add?


On Tue, Mar 26, 2019 at 6:48 PM Eric Seidel <eric at seidel.io> wrote:

> On Tue, Mar 26, 2019, at 13:17, Iavor Diatchki wrote:
> > My concern is that the notation certainly suggests that you are binding
> > types with the @ syntax, but in really it is still the type signature
> > that guides the binding of the variables and the @ parameters just
> > duplicate the information from the type signature.
> But you are binding types with the @ syntax. The proposal gives a number
> of examples where the @-bound type variable is bound by a different name
> (or not at all) in the type signature. Many are contrived, to demonstrate
> where the binders are allowed, but the higher-rank and proxy-eliding
> examples look compelling to me.
> We also already allow repeated value binders in Haskell. When I write a
> function in equational style, I have to rebind each argument in each
> alternate equation. Sometimes this is noisy and I'll prefer a single
> equation with an explicit `case`. But for functions where the body is
> sizable, I find the repeated binders to be quite helpful because the scopes
> are smaller. I can easily see the same benefit applying to type binders.
> Ultimately, I think this comes down to a matter of style, and I favor
> letting Haskell programmers pick the style that works best for them.
> Eric
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190403/3d6abc87/attachment.html>

More information about the ghc-steering-committee mailing list