Allow ScopedTypeVariables to refer to types #128

nomeata · 2018-04-25T01:46:01Z

The proposal has been accepted; the following discussion is mostly of historic interest.

simonpj · 2018-04-25T07:49:54Z

I basically support this proposal, but starting with an intricate GADT example conceals the point. Please can we offer a series of examples, starting simple. For example (all assuming -XScopedTypeVariables):

f :: Maybe a -> Int
f (Just (x :: b)) = <body>

This is clearly fine. b scopes over <body>. The variable a is not in scope at all (no explicit forall).

f :: forall a. Maybe a -> Int
f (Just (x :: b)) = <body>

Both a and b are in scope in <body>, as aliases.

Now the kicker:

f :: Maybe Int -> Int
f (Just (x :: a)) = <body>

If this was allowed a would have to be an alias for Int. Currently that is not allowed: a lexically scoped type variable can only be bound to a type variable. The whole point of the proposal is to lift that restriction.

One reason for making the change is that it's not really clear what being "bound to a type variable" means in the presence of type equalities. For example:

f1 :: (a ~ Int) => Maybe a -> Int
f1 (Just (x :: b)) = <body>

f2 :: (a ~ Int) => Maybe Int -> Int
f2 (Just (x :: a)) = <body>

Which of these should be accepted under the current rules? (SPJ says: I don't even know; I'd have to try it.) An advantage of the proposal is that such questions become irrelevant.

....You can add some more examples. Be sure to talk about repeated variables too!

RyanGlScott · 2018-04-25T13:14:44Z

I also support this proposal.

Another motivation that might be worth mentioning is the ability to bind large types to shorter variable names, such as in:

f :: ReallyReallyReallyReallyLongTypeName -> T
f (x :: a) = ...
-- Instead of f (x :: ReallyReallyReallyReallyLongTypeName)

goldfirere · 2018-04-25T14:13:59Z

What about this:

foo (Just (x :: a)) = not x

Note: no type signature. This is rejected today, because a is not Bool. Under your proposal, it sounds like you would want to accept this. However, the proposal states "GHC insists that the type variable is bound to a rigid, or fully-known, type". In this case, a is not rigid or fully-known at the time it's bound. To be honest, I don't know exactly what "fully-known" means here.

nomeata · 2018-04-25T14:24:42Z

Indeed, my branch accepts that code:

Prelude> :set -XScopedTypeVariables 
Prelude> foo (Just (x :: a)) = not x
Prelude> :t foo
foo :: Maybe Bool -> Bool

However, the proposal states "GHC insists that the type variable is bound to a rigid, or fully-known, type". In this case, a is not rigid or fully-known at the time it's bound. To be honest, I don't know exactly what "fully-known" means here.

The proposal states that only because it is the smallest delta to the status quo. I am too typechecker ignorant to get this right on my own, so I will need your help. (Where “you” refers to the numerous hoards of type-checker hacker out there, not necessarily just Richard. There are legions of those, are there?)

Shall we simply drop that sentence?

goldfirere · 2018-04-25T14:29:48Z

I vote to drop that sentence, or for someone to explain what it means.

and also mention that the current behavior about repeated type variables is unchanged.

simonpj · 2018-04-25T14:56:30Z

"GHC insists that the type variable is bound to a rigid, or fully-known, type".

Yes I think that sentence is probably nonsense

simonpj · 2018-04-25T14:59:26Z

Could you take advantage of the opportunity, and write as tight a spec for the new system as you can? Things specified by deltas from an ill-specified baseline are never satsifying. Just specify pattern type signatures ab-initio. In the light of this discussion doing so may not be hard.

yav · 2018-06-15T16:48:08Z

I also think this is a good idea. Oddly, I am pretty sure that type variables in patterns used to work as in the proposal some time ago, but I guess at some point they got switched to being universal??

We've had this feature for a long time in Cryptol, and I think it works pretty well.

simonpj · 2018-06-15T20:42:41Z

My request for a spec is answered by this paper: https://www.microsoft.com/en-us/research/publication/type-variables-patterns/. Have a look!

adamgundry · 2018-06-15T21:34:11Z

Lovely. Is there a plan to implement appendix B? I for one would be happy to give up ScopedTypeVariables for the ability to bind type variables in function definitions.

simonpj · 2018-06-15T23:06:48Z

One step at a time. Let's do type applications in patterns first.

goldfirere · 2018-07-14T19:04:21Z

Is this ready to submit to the committee now?

nomeata · 2018-07-14T19:14:05Z

Is there merit in bundling this with #126 and have just one proposal for the paper? But probably not, they are nicely orthogonal… Are you happy with the text?

goldfirere · 2018-07-14T19:26:35Z

In the "specification" part, there is a reference to "the above sentence" which is unclear to me. The best referent seems to have two sentences.

Ericson2314 · 2018-07-16T05:37:03Z

The paper mentions type lambdas as an alternative. But isn't there no conflict? Isn't this forward compatible with:

singleton @b (x :: b) = x -- good

singleton :: a -> [a]
singleton @b (x :: b) = x -- good

singleton :: Show a => a -> [a]
singleton @b (x :: b) = x -- good

singleton :: forall b. b ~ Int => Int -> [Int]
singleton @b (x :: b) = x -- good

singleton :: Int -> [Int]
singleton @b (x :: b) = x -- bad, because there's explicitly no ∀ type

singleton :: a -> [a]
singleton @b (x :: c) = x 
-- ^ bad, because cannot mix implicit (for `c`) and explicit (for `b`) Λ

nomeata · 2018-07-16T14:01:56Z

Interesting example. At the moment, I think the way forward will be that type lambdas (#155) will not and never refer to types, and only ever to forall’ed type variables. But maybe that discussion should happen in #155 :-)

goldfirere · 2018-07-16T16:46:05Z

I've responded to #128 (comment) in #155.

Ericson2314 · 2018-07-17T02:27:30Z

Haha, what timing!

…nce of #128

Ericson2314 · 2019-07-23T16:43:54Z

All the examples are pattern signatures within function binds. What about pattern binds? It is not clear to me.

x :: a = 1 :: Int -- OK ?

f :: a -> a -- fresh or captured a?
f = id

The options I think make sense to me are

accepted, captured a below.
disallowed, only patterns within function binds, case patterns, and do notation patterns are allowed. Fresh a below.

What worries me would be taking a turn from #228 and trying to allow a but limit its scope.

x :: a = 1 :: Int
x' :: forall a. Num a => a = \ @c => 1 :: c
Just (y :: b) = Just (1 :: Int)
Just (y :: forall b. Num b => b) = Just $ \ @c => 1 :: c

In deference to future work on impredicative types, I only want the two a bindings to work the same if the two b bindings work the same.

int-index · 2019-07-23T17:00:06Z

What about pattern binds?

Both before & after this proposal, pattern binds don't support scoped type variables.

x :: a = 1 :: Int -- OK ?

Not OK as pattern binds don't support -XScopedTypeVariables at all:

ghci> x :: a = 1 :: Int
<interactive>:3:1: error:
    • You cannot bind scoped type variable ‘a’
        in a pattern binding signature
    • In the pattern: x :: a
      In a pattern binding: x :: a = 1 :: Int

However, #228 reclassifies this as a nullary function bind, so it should be OK in the future.

Ericson2314 · 2019-07-23T17:08:14Z

@int-index sorry lost internet so tardily edited the post above.

Both before & after this proposal, pattern binds don't support scoped type variables.

I believe you but the error messages make this rather confusing

Prelude> (1 :: Int) = 1

<interactive>:8:2: error:
    Illegal type signature: ‘Int’
      Type signatures are only allowed in patterns with ScopedTypeVariables

If we still had PatternSignatures the situation might make more sense!

Ericson2314 · 2019-07-23T17:15:01Z

@int-index I'll take the second part back to a #228 modification. Thanks for clarifying exactly what this does.

nomeata added 2 commits Apr 25, 2018

Allow ScopedTypeVariables to refer to types

c4c833c

Link back to discussion

1d9a387

RyanGlScott mentioned this pull request Apr 25, 2018

Make Sing a type family goldfirere/singletons#318

Closed

Add examples, change spec to just remove the sentence

4cfda53

and also mention that the current behavior about repeated type variables is unchanged.

nomeata mentioned this pull request Apr 26, 2018

Type applications in patterns #126

Merged

No rst links in metadata

a7a41dd

rst syntax fixes

9ddf770

Clarify the proposed change

99b2618

nomeata assigned yav Jul 14, 2018

nomeata added the Pending committee review label Jul 14, 2018

Link to paper

90bda91

goldfirere mentioned this pull request Jul 16, 2018

Binding type variables in lambda-expressions #155

Merged

nomeata merged commit 90bda91 into master Aug 4, 2018

nomeata added Accepted and removed Pending committee review labels Aug 4, 2018

nomeata added a commit that referenced this pull request Aug 17, 2018

Link to trac ticket and remove paragraph that is obsoleted by accepta…

bac8c4c

…nce of #128

bravit added the Proposal label Nov 11, 2018

nomeata added the Implemented label Dec 3, 2018

Ericson2314 mentioned this pull request Nov 14, 2019

-XNoImplicitForAll, -XNoPatternSignatureBinds #285

Merged

ghc-proposals / ghc-proposals

Allow ScopedTypeVariables to refer to types #128

Allow ScopedTypeVariables to refer to types #128

nomeata commented Apr 25, 2018 •

edited

simonpj commented Apr 25, 2018 •

edited

RyanGlScott commented Apr 25, 2018

goldfirere commented Apr 25, 2018

nomeata commented Apr 25, 2018

goldfirere commented Apr 25, 2018

simonpj commented Apr 25, 2018

simonpj commented Apr 25, 2018

yav commented Jun 15, 2018

simonpj commented Jun 15, 2018

adamgundry commented Jun 15, 2018

simonpj commented Jun 15, 2018

goldfirere commented Jul 14, 2018

nomeata commented Jul 14, 2018

goldfirere commented Jul 14, 2018

Ericson2314 commented Jul 16, 2018 •

edited

nomeata commented Jul 16, 2018

goldfirere commented Jul 16, 2018

Ericson2314 commented Jul 17, 2018

Ericson2314 commented Jul 23, 2019 •

edited

int-index commented Jul 23, 2019 •

edited

Ericson2314 commented Jul 23, 2019 •

edited

Ericson2314 commented Jul 23, 2019 •

edited

ghc-proposals / ghc-proposals

Allow ScopedTypeVariables to refer to types #128

Allow ScopedTypeVariables to refer to types #128

Conversation

nomeata commented Apr 25, 2018 • edited

simonpj commented Apr 25, 2018 • edited

RyanGlScott commented Apr 25, 2018

goldfirere commented Apr 25, 2018

nomeata commented Apr 25, 2018

goldfirere commented Apr 25, 2018

simonpj commented Apr 25, 2018

simonpj commented Apr 25, 2018

yav commented Jun 15, 2018

simonpj commented Jun 15, 2018

adamgundry commented Jun 15, 2018

simonpj commented Jun 15, 2018

goldfirere commented Jul 14, 2018

nomeata commented Jul 14, 2018

goldfirere commented Jul 14, 2018

Ericson2314 commented Jul 16, 2018 • edited

nomeata commented Jul 16, 2018

goldfirere commented Jul 16, 2018

Ericson2314 commented Jul 17, 2018

Ericson2314 commented Jul 23, 2019 • edited

int-index commented Jul 23, 2019 • edited

Ericson2314 commented Jul 23, 2019 • edited

Ericson2314 commented Jul 23, 2019 • edited

nomeata commented Apr 25, 2018 •

edited

simonpj commented Apr 25, 2018 •

edited

Ericson2314 commented Jul 16, 2018 •

edited

Ericson2314 commented Jul 23, 2019 •

edited

int-index commented Jul 23, 2019 •

edited

Ericson2314 commented Jul 23, 2019 •

edited

Ericson2314 commented Jul 23, 2019 •

edited