Unsurprisingly, I'm in support. The lack of this ability has forced `singletons` to go through hoops to bind type variables in certain situations.

On Jul 24, 2018, at 12:25 PM, Simon Peyton Jones via ghc-steering-committee wrote:

I originally thought that it’d be confusing for ‘a’ to mean ‘Bool’; but that was before GADTs! Now that argument is much less strong, and I’m in favour of this proposal.

Simon

From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 24 July 2018 17:23 To: ghc-steering-committee@haskell.org Subject: [ghc-steering-committee] Discussion on "Allow ScopedTypeVariables to refer to types" (#128)

Hello,

let's get the discussion going on proposal #128.

Summary: this proposal generalizes the behavior of type variables in patterns, specifically the variables that do not refer to an explicitly quantified type parameter. The idea is that such type variables simply introduce a name for their matching type, without placing any restriction on the type. For example, consider the following definition.

f (x : [a]) (y : a) = and x

This would be accepted and it would have type `[Bool] -> Bool -> Bool`. This proposal is about the meaning of the type signature on `x` which states that it must be a list of something, and `a` will be a name for the type of its elements. In this case, it happens that `a` is actually just an alias for `Bool`.

I am strongly in favor of this proposal. As I mentioned on the github discussion, I thought that the feature already worked as in this proposal, and was quite surprised to find out that currently, GHC has restrictions on what `a` could be, and it also complains about "multiple definitions for `a`" in the above example).

Thoughts?

-Iavor

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, I hope you don’t mind me doing this despite me being conflicted, but I observe consensus, and mark this as accepted. Cheers, Joachim Am Dienstag, den 24.07.2018, 21:28 +0200 schrieb Manuel M T Chakravarty:

Count me in, too.

Manuel

...

Am 24.07.2018 um 21:01 schrieb Richard Eisenberg :

Unsurprisingly, I'm in support. The lack of this ability has forced `singletons` to go through hoops to bind type variables in certain situations.

...

On Jul 24, 2018, at 12:25 PM, Simon Peyton Jones via ghc-steering-committee wrote:

I originally thought that it’d be confusing for ‘a’ to mean ‘Bool’; but that was before GADTs! Now that argument is much less strong, and I’m in favour of this proposal.

Simon

From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 24 July 2018 17:23 To: ghc-steering-committee@haskell.org Subject: [ghc-steering-committee] Discussion on "Allow ScopedTypeVariables to refer to types" (#128)

Hello,

let's get the discussion going on proposal #128.

Summary: this proposal generalizes the behavior of type variables in patterns, specifically the variables that do not refer to an explicitly quantified type parameter. The idea is that such type variables simply introduce a name for their matching type, without placing any restriction on the type. For example, consider the following definition.

f (x : [a]) (y : a) = and x

This would be accepted and it would have type `[Bool] -> Bool -> Bool`. This proposal is about the meaning of the type signature on `x` which states that it must be a list of something, and `a` will be a name for the type of its elements. In this case, it happens that `a` is actually just an alias for `Bool`.

I am strongly in favor of this proposal. As I mentioned on the github discussion, I thought that the feature already worked as in this proposal, and was quite surprised to find out that currently, GHC has restrictions on what `a` could be, and it also complains about "multiple definitions for `a`" in the above example).

Thoughts?

-Iavor

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/