From mail at joachim-breitner.de  Sat Mar  2 16:16:33 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 02 Mar 2019 17:16:33 +0100
Subject: [ghc-steering-committee] #210: -Wredundant-minimal-methods,
	recommendation: accept
In-Reply-To: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
Message-ID: <f78f9f59bda00c7d08fa3a7c35b8f02223e01d31.camel@joachim-breitner.de>

Dear Committee,

Levent Erkök has proposed to introduce a warning when a type class
specifies a methods as definitely requires (via a MINIMAL pragma), but
still gives a default implementation:
https://github.com/LeventErkok/ghc-proposals/blob/master/proposals/0000-minimal-should-warn-extras.rst

This seems both useful and and harmless to me, so I propose we accept
the proposal.

If we want to do some bike shedding: I think 
   -Wredundant-minimal-methods
has a better flow than the proposed
   -Wminimal-redundant-methods
After all, we want to be warned about redundancy of minimal methods,
not minimality of redundant methods.

Cheers,
Simon


From eric at seidel.io  Sat Mar  2 21:41:56 2019
From: eric at seidel.io (Eric Seidel)
Date: Sat, 02 Mar 2019 16:41:56 -0500
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic lift.
	Recommendation: accept
Message-ID: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>

Hi everyone,

This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift` class levity-polymorphic, which allows us to write proper `Lift` instances for unlifted types. It would also allow GHC to remove the special logic that currently supports lifting records with unlifted fields.

The main downside is the potential for breakage since `lift @Foo` would now fix the RuntimeRep parameter rather than the `a`. This is unfortunate, but I doubt it will show up much. It also unfortunately requires making both `lift` and `liftTyped` methods, when we had just decided to extract `lift` from the class. 

I recommend accepting the proposal.

Thanks!
Eric

[1]: https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst

From iavor.diatchki at gmail.com  Sun Mar  3 00:24:31 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sat, 2 Mar 2019 16:24:31 -0800
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
Message-ID: <CAGK9nuobULBOGXJhfYXdnVX1cGT80L6R0BTW5fcgLA54CQxpjQ@mail.gmail.com>

I am on board

On Sat, Mar 2, 2019, 13:42 Eric Seidel <eric at seidel.io> wrote:

> Hi everyone,
>
> This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift`
> class levity-polymorphic, which allows us to write proper `Lift` instances
> for unlifted types. It would also allow GHC to remove the special logic
> that currently supports lifting records with unlifted fields.
>
> The main downside is the potential for breakage since `lift @Foo` would
> now fix the RuntimeRep parameter rather than the `a`. This is unfortunate,
> but I doubt it will show up much. It also unfortunately requires making
> both `lift` and `liftTyped` methods, when we had just decided to extract
> `lift` from the class.
>
> I recommend accepting the proposal.
>
> Thanks!
> Eric
>
> [1]:
> https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst
> _______________________________________________
> 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/20190302/d77d9d95/attachment.html>

From iavor.diatchki at gmail.com  Sun Mar  3 00:27:20 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sat, 2 Mar 2019 16:27:20 -0800
Subject: [ghc-steering-committee] #210: -Wredundant-minimal-methods,
 recommendation: accept
In-Reply-To: <f78f9f59bda00c7d08fa3a7c35b8f02223e01d31.camel@joachim-breitner.de>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <f78f9f59bda00c7d08fa3a7c35b8f02223e01d31.camel@joachim-breitner.de>
Message-ID: <CAGK9nuo=r0P0e_pydzNXEuO0w+PikTdMmFaRqYyLt_nTV=PQag@mail.gmail.com>

I am on board. And I like "redundant minimal" better

On Sat, Mar 2, 2019, 08:16 Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> Levent Erkök has proposed to introduce a warning when a type class
> specifies a methods as definitely requires (via a MINIMAL pragma), but
> still gives a default implementation:
>
> https://github.com/LeventErkok/ghc-proposals/blob/master/proposals/0000-minimal-should-warn-extras.rst
>
> This seems both useful and and harmless to me, so I propose we accept
> the proposal.
>
> If we want to do some bike shedding: I think
>    -Wredundant-minimal-methods
> has a better flow than the proposed
>    -Wminimal-redundant-methods
> After all, we want to be warned about redundancy of minimal methods,
> not minimality of redundant methods.
>
> Cheers,
> Simon
>
> _______________________________________________
> 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/20190302/60d3dcc8/attachment.html>

From chak at justtesting.org  Sun Mar  3 12:47:39 2019
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Sun, 3 Mar 2019 13:47:39 +0100
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
Message-ID: <A47E31A1-750C-4DC9-B90B-A4DF79B00998@justtesting.org>

Sounds good to me.

Manuel

> Am 02.03.2019 um 22:41 schrieb Eric Seidel <eric at seidel.io>:
> 
> Hi everyone,
> 
> This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift` class levity-polymorphic, which allows us to write proper `Lift` instances for unlifted types. It would also allow GHC to remove the special logic that currently supports lifting records with unlifted fields.
> 
> The main downside is the potential for breakage since `lift @Foo` would now fix the RuntimeRep parameter rather than the `a`. This is unfortunate, but I doubt it will show up much. It also unfortunately requires making both `lift` and `liftTyped` methods, when we had just decided to extract `lift` from the class. 
> 
> I recommend accepting the proposal.
> 
> Thanks!
> Eric
> 
> [1]: https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From eric at seidel.io  Mon Mar  4 01:44:21 2019
From: eric at seidel.io (Eric Seidel)
Date: Sun, 03 Mar 2019 20:44:21 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Discussion_on_=23155_Type_Vari?=
 =?utf-8?q?able_in=09Labmdas?=
In-Reply-To: <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
Message-ID: <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>

One argument in favor of the proposal that I don't believe I've seen mentioned is that, now that we can explicitly apply types with the @ syntax, it feels very intuitive to also bind them with the same syntax. So even if this proposal does not add much technically over ScopedTypeVariables, I think it's still a good idea.

I do have a couple of questions/comments though:

1. Should we allow binding type variables that are not explicitly quantified with a forall? I'm concerned about the potential for breaking code should GHC's rules for ordering quantifiers change. Does GHC already guarantee a particular ordering? Would we want to?

2. I wonder if supporting type binders in inference mode is as hard as the proposal fears. The alternatives section mentions the possibility of extracting a partial type signature from the LHS, but I had a simpler thought. Why not say that `\ @a -> body` infers the type `forall a. ty` where `body :: ty`, and let unification handle the rest? It seems like that would handle all of the variants of `null` in section 7, though not the example in section 3 with the equality constraint. But to be honest, I'd be ok with rejecting that program. It would be much clearer with a single type binder.

I don't think the lack of a solution for type binders in inference mode should block this proposal, but it would be much nicer if we had one! I don't want Haskell programmers to have to learn the intricacies of bidirectional type checking to use what is otherwise a very intuitive feature.

Eric


On Tue, Feb 19, 2019, at 14:01, Iavor Diatchki wrote:
> After a bit more thought, I am not sure what do we get with this 
> notation over ScopedTypeVariables. In particular, here are some things 
> that came up as I was trying to write a couple of examples:
> 
>  1. The order in which variables are introduced is not 
> clear---presumably it is some sort of left to write ordering based on 
> the type signature. For example:
>  f1 :: (a,b) -> a -- first type param is `a`?
>  f2 :: Ord b => a -> b -> a -- first type param is `b`?
>  type T a b = (b,a)
>  f3 :: T a b -> a -- first type param is?
>  This approach seems quite fragile.
> 
>  2. The proposal says that a problem with the `forall` in 
> ScopedTypeVariables is that the signature can be arbitrarily far away 
> from the implementation. I agree that this is a problem, but it seems 
> to remain a problem with this proposal, as you have to look at the 
> signature to see in what order you should write the parameters.
> 
>  3. There are some things that you can write with the `forall` 
> notation, that you cannot write using this notation. For example:
> 
>  f3 :: forall a. Bool
>  f3 = null ([] :: [a])
> 
>  Clearly this example is a bit contrived, but still it illustrates a problem.
> 
> As is, I am not sure what we are getting over ScopedTypeVariables. Am I 
> missing something here?
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Feb 19, 2019 at 10:28 AM Iavor Diatchki 
> <iavor.diatchki at gmail.com> wrote:
> > Hello,
> > 
> > let's get the discussion going about proposal #155 (https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst).
> > 
> > Summary:
> > the idea is pretty simple: allow functions to name their type arguments explicitly, so that they can be used in type signatures within the function's definition. The notation for a type argument is `@a`, and such type arguments can be used only when functions have an explicit type signature (technically, when GHC is doing "checking" rather then "inference").
> > 
> > This proposal provides an alternative to "ScopedTypeVariables" to refer to type parameters, which I think is a step in the right direction, as using the `forall` to introduce type variables always felt a bit hacky to me (now, there's a technical argument :)
> > 
> > I am a bit concerned with the notation though: in other places where we use `@a`, (e.g., #126 type application in patterns, and TypeApplications) the `a` is a type, while in this use it must be a variable. I wonder if this punning might be confusing. I don't really have an alternative suggestion though.
> > 
> > What does everyone else thing?
> > 
> > -Iavor 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From simonpj at microsoft.com  Mon Mar  4 11:41:53 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 4 Mar 2019 11:41:53 +0000
Subject: [ghc-steering-committee] #210: -Wredundant-minimal-methods,
	recommendation: accept
In-Reply-To: <f78f9f59bda00c7d08fa3a7c35b8f02223e01d31.camel@joachim-breitner.de>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <f78f9f59bda00c7d08fa3a7c35b8f02223e01d31.camel@joachim-breitner.de>
Message-ID: <DB7PR83MB0298A6E86B49C3742542FCE0AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>

I'm happy to support this.  And yes "-Wredundant-minimal-methods"

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Joachim Breitner
| Sent: 02 March 2019 16:17
| To: ghc-steering-committee at haskell.org
| Subject: [ghc-steering-committee] #210: -Wredundant-minimal-methods,
| recommendation: accept
| 
| Dear Committee,
| 
| Levent Erkök has proposed to introduce a warning when a type class
| specifies a methods as definitely requires (via a MINIMAL pragma), but
| still gives a default implementation:
| https://github.com/LeventErkok/ghc-proposals/blob/master/proposals/0000-
| minimal-should-warn-extras.rst
| 
| This seems both useful and and harmless to me, so I propose we accept
| the proposal.
| 
| If we want to do some bike shedding: I think
|    -Wredundant-minimal-methods
| has a better flow than the proposed
|    -Wminimal-redundant-methods
| After all, we want to be warned about redundancy of minimal methods,
| not minimality of redundant methods.
| 
| Cheers,
| Simon
| 
| _______________________________________________
| ghc-steering-committee mailing list
| ghc-steering-committee at haskell.org
| https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From mail at joachim-breitner.de  Mon Mar  4 12:09:22 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 04 Mar 2019 13:09:22 +0100
Subject: [ghc-steering-committee] Please review #190: Module qualified
	syntax, Shepherd: Simon M
Message-ID: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Module qualified syntax
has been proposed by Shayne Fletcher
https://github.com/ghc-proposals/ghc-proposals/pull/190
https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst

Simon Marlow has already volunteered to shepherd.

Please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process
I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190304/0179786b/attachment.sig>

From simonpj at microsoft.com  Mon Mar  4 12:32:13 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 4 Mar 2019 12:32:13 +0000
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
	lift.	Recommendation: accept
In-Reply-To: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
Message-ID: <DB7PR83MB02985FBCFEDB739632D9B628AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>

I'm supportive too.  But, as I say on the proposal thread, before this lands we should decide about https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0026-explicit-specificity.rst.



I came across another pretty convincing use-case for explicit specificity, in new draft paper "Higher-order Type-level Programming in Haskell".  Will publish a link to it shortly.  But in brief we have a function.

hMap ::  forall {m :: Matchability}

                (c :: * -> Constraint)

                (f :: * ->m *) as.

         All as c => (forall a. c a => a -> f a) -> HList as -> HList (Map f as)


Where the ‘m’ parameter is entirely forced by the ‘f’ parameter.  So we’d end up writing

Hmap @_ @Db @DbUser
a lot.  That “@_” is a bit silly



Simon



-----Original Message-----
From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Eric Seidel
Sent: 02 March 2019 21:42
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic lift. Recommendation: accept



Hi everyone,



This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift` class levity-polymorphic, which allows us to write proper `Lift` instances for unlifted types. It would also allow GHC to remove the special logic that currently supports lifting records with unlifted fields.



The main downside is the potential for breakage since `lift @Foo` would now fix the RuntimeRep parameter rather than the `a`. This is unfortunate, but I doubt it will show up much. It also unfortunately requires making both `lift` and `liftTyped` methods, when we had just decided to extract `lift` from the class.



I recommend accepting the proposal.



Thanks!

Eric



[1]: https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst

_______________________________________________

ghc-steering-committee mailing list

ghc-steering-committee at haskell.org<mailto: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/20190304/1f6a5dc5/attachment-0001.html>

From simonpj at microsoft.com  Mon Mar  4 12:56:59 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 4 Mar 2019 12:56:59 +0000
Subject: [ghc-steering-committee] Discussion on #155 Type Variable
	in	Labmdas
In-Reply-To: <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
Message-ID: <DB7PR83MB0298443B293D0A9094EF8FA2AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>

1. Should we allow binding type variables that are not explicitly quantified with a forall? I'm concerned about the potential for breaking code should GHC's rules for ordering quantifiers change. Does GHC already guarantee a particular ordering?



See my comments<https://github.com/ghc-proposals/ghc-proposals/pull/155#issuecomment-469241834> on GitHub.





2. I wonder if supporting type binders in inference mode is as hard as the proposal fears.



I think it’s hard.

              f @a x = x

we could infer any of.

              f :: forall a b. b -> b

              f :: forall a. a -> a

              f :: forall b a. b -> b



Roughly, it’s as hard as figuring out impredicative polymorphism I think.  Let’s not go there 😊.



Simon



-----Original Message-----
From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Eric Seidel
Sent: 04 March 2019 01:44
To: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas



One argument in favor of the proposal that I don't believe I've seen mentioned is that, now that we can explicitly apply types with the @ syntax, it feels very intuitive to also bind them with the same syntax. So even if this proposal does not add much technically over ScopedTypeVariables, I think it's still a good idea.



I do have a couple of questions/comments though:



1. Should we allow binding type variables that are not explicitly quantified with a forall? I'm concerned about the potential for breaking code should GHC's rules for ordering quantifiers change. Does GHC already guarantee a particular ordering? Would we want to?



2. I wonder if supporting type binders in inference mode is as hard as the proposal fears. The alternatives section mentions the possibility of extracting a partial type signature from the LHS, but I had a simpler thought. Why not say that `\ @a -> body` infers the type `forall a. ty` where `body :: ty`, and let unification handle the rest? It seems like that would handle all of the variants of `null` in section 7, though not the example in section 3 with the equality constraint. But to be honest, I'd be ok with rejecting that program. It would be much clearer with a single type binder.



I don't think the lack of a solution for type binders in inference mode should block this proposal, but it would be much nicer if we had one! I don't want Haskell programmers to have to learn the intricacies of bidirectional type checking to use what is otherwise a very intuitive feature.



Eric





On Tue, Feb 19, 2019, at 14:01, Iavor Diatchki wrote:

> After a bit more thought, I am not sure what do we get with this

> notation over ScopedTypeVariables. In particular, here are some things

> that came up as I was trying to write a couple of examples:

>

>  1. The order in which variables are introduced is not

> clear---presumably it is some sort of left to write ordering based on

> the type signature. For example:

>  f1 :: (a,b) -> a -- first type param is `a`?

>  f2 :: Ord b => a -> b -> a -- first type param is `b`?

>  type T a b = (b,a)

>  f3 :: T a b -> a -- first type param is?

>  This approach seems quite fragile.

>

>  2. The proposal says that a problem with the `forall` in

> ScopedTypeVariables is that the signature can be arbitrarily far away

> from the implementation. I agree that this is a problem, but it seems

> to remain a problem with this proposal, as you have to look at the

> signature to see in what order you should write the parameters.

>

>  3. There are some things that you can write with the `forall`

> notation, that you cannot write using this notation. For example:

>

>  f3 :: forall a. Bool

>  f3 = null ([] :: [a])

>

>  Clearly this example is a bit contrived, but still it illustrates a problem.

>

> As is, I am not sure what we are getting over ScopedTypeVariables. Am

> I missing something here?

>

> -Iavor

>

>

>

>

>

>

>

>

>

>

> On Tue, Feb 19, 2019 at 10:28 AM Iavor Diatchki

> <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

> > Hello,

> >

> > let's get the discussion going about proposal #155 (https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst).

> >

> > Summary:

> > the idea is pretty simple: allow functions to name their type arguments explicitly, so that they can be used in type signatures within the function's definition. The notation for a type argument is `@a`, and such type arguments can be used only when functions have an explicit type signature (technically, when GHC is doing "checking" rather then "inference").

> >

> > This proposal provides an alternative to "ScopedTypeVariables" to

> > refer to type parameters, which I think is a step in the right

> > direction, as using the `forall` to introduce type variables always

> > felt a bit hacky to me (now, there's a technical argument :)

> >

> > I am a bit concerned with the notation though: in other places where we use `@a`, (e.g., #126 type application in patterns, and TypeApplications) the `a` is a type, while in this use it must be a variable. I wonder if this punning might be confusing. I don't really have an alternative suggestion though.

> >

> > What does everyone else thing?

> >

> > -Iavor

> _______________________________________________

> ghc-steering-committee mailing list

> ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>

> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ

> ee

>

_______________________________________________

ghc-steering-committee mailing list

ghc-steering-committee at haskell.org<mailto: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/20190304/36e0c4dd/attachment-0001.html>

From eric at seidel.io  Mon Mar  4 14:56:11 2019
From: eric at seidel.io (Eric Seidel)
Date: Mon, 04 Mar 2019 09:56:11 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Discussion_on_=23155_Type_Vari?=
 =?utf-8?q?able_in=09Labmdas?=
In-Reply-To: <DB7PR83MB0298443B293D0A9094EF8FA2AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <DB7PR83MB0298443B293D0A9094EF8FA2AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <9bb98351-8bc6-4dd4-ac99-4988e53f30ac@www.fastmail.com>

On Mon, Mar 4, 2019, at 07:57, Simon Peyton Jones wrote:
>  
> 1. Should we allow binding type variables that are not explicitly 
> quantified with a forall? I'm concerned about the potential for 
> breaking code should GHC's rules for ordering quantifiers change. Does 
> GHC already guarantee a particular ordering?
> 
> 
> See  my comments 
> <https://github.com/ghc-proposals/ghc-proposals/pull/155#issuecomment-469241834> on GitHub.

Ah, thanks for the clarification. In retrospect, I guess it makes sense that GHC guarantees an ordering. TypeApplications would have been quite disruptive if we could only specify types that were explicitly quantified..

> 2. I wonder if supporting type binders in inference mode is as hard as 
> the proposal fears.
> 
> 
> I think it’s hard. 
> 
>  f @a x = x
> 
> we could infer any of.
> 
>  f :: forall a b. b -> b
> 
>  f :: forall a. a -> a
> 
>  f :: forall b a. b -> b

I don't know how we'd infer the 2nd option, even though that's surely what was intended. There's simply no link between the `a` and `x` in the code. So I'd expect GHC to infer either the 1st or 3rd type, and emit a warning about the unused type abstraction similar to the existing warnings about unused variables or unused foralls. Does the order of tyvars matter here? Doesn't seem so, as `b` should be marked inferred, and thus ineligible for VTA.

> Roughly, it’s as hard as figuring out impredicative polymorphism I 
> think. Let’s not go there 😊.

Is it really like impredicative polymorphism? Based on my (very limited) understanding of impredicativity, the difficulty is in figuring out where to place quantifiers. But with explicit type abstraction the user has told us precisely where the quantifier goes! So this seems like a rather different, and simpler, problem than impredicativity.

From iavor.diatchki at gmail.com  Mon Mar  4 19:04:08 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 4 Mar 2019 11:04:08 -0800
Subject: [ghc-steering-committee] Discussion on #155 Type Variable in
	Labmdas
In-Reply-To: <9bb98351-8bc6-4dd4-ac99-4988e53f30ac@www.fastmail.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <DB7PR83MB0298443B293D0A9094EF8FA2AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <9bb98351-8bc6-4dd4-ac99-4988e53f30ac@www.fastmail.com>
Message-ID: <CAGK9nuomgVf7qgg-vzkpETiDMZuK6sbq2QunqAKa703kw+c2-A@mail.gmail.com>

Hello,

> 2. I wonder if supporting type binders in inference mode is as hard as
> > the proposal fears.
> >
> >
> > I think it’s hard.
> >
> >  f @a x = x
> >
> > we could infer any of.
> >
> >  f :: forall a b. b -> b
> >
> >  f :: forall a. a -> a
> >
> >  f :: forall b a. b -> b
>
> I don't know how we'd infer the 2nd option, even though that's surely what
> was intended. There's simply no link between the `a` and `x` in the code.
> So I'd expect GHC to infer either the 1st or 3rd type, and emit a warning
> about the unused type abstraction similar to the existing warnings about
> unused variables or unused foralls. Does the order of tyvars matter here?
> Doesn't seem so, as `b` should be marked inferred, and thus ineligible for
> VTA.
>

Like Eric, I would expect that the type of `f` should be something like (1)
or (3), except that the inferred polymorphic variables should not be
visible (i.e., you shouldn't be able to explicitly apply them), in which
case (1) and (3) are essentially the same:

f :: forall a {b}. b -> b

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190304/311e15fa/attachment.html>

From rae at cs.brynmawr.edu  Tue Mar  5 03:05:30 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 4 Mar 2019 22:05:30 -0500
Subject: [ghc-steering-committee] Discussion on #155 Type Variable
	in	Labmdas
In-Reply-To: <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
Message-ID: <78A08A87-F650-4F37-B5CC-BA011C509D3D@cs.brynmawr.edu>



> On Mar 3, 2019, at 8:44 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> Why not say that `\ @a -> body` infers the type `forall a. ty` where `body :: ty`, and let unification handle the rest?

That's intriguingly simple. I haven't thought through the consequences of this fully, but it does seem plausible. I'm not ready to commit to that, but after a few minutes' focused thought, I can't see any problems with it. In any case, the proposal as written is forward-compatible with such a change, as doing what you say will allow only more programs: ones accepted by the proposal will remain accepted and with the same meanings.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190304/789bb5b7/attachment.html>

From rae at cs.brynmawr.edu  Tue Mar  5 03:16:18 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 4 Mar 2019 22:16:18 -0500
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
Message-ID: <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>

I recall a discussion in another proposal about the Lift class and removing the lift function. This was for a good reason (I think it stopped silent, terrible breakage). Does anyone remember where that conversation took place? A quick search didn't find an accepted proposal about the Lift class.

Thanks,
Richard

> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> Hi everyone,
> 
> This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift` class levity-polymorphic, which allows us to write proper `Lift` instances for unlifted types. It would also allow GHC to remove the special logic that currently supports lifting records with unlifted fields.
> 
> The main downside is the potential for breakage since `lift @Foo` would now fix the RuntimeRep parameter rather than the `a`. This is unfortunate, but I doubt it will show up much. It also unfortunately requires making both `lift` and `liftTyped` methods, when we had just decided to extract `lift` from the class. 
> 
> I recommend accepting the proposal.
> 
> Thanks!
> Eric
> 
> [1]: https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From eric at seidel.io  Tue Mar  5 03:19:51 2019
From: eric at seidel.io (Eric Seidel)
Date: Mon, 04 Mar 2019 22:19:51 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=23209=3A_Levity_poly?=
 =?utf-8?q?morphic_lift=2E_Recommendation=3A_accept?=
In-Reply-To: <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
Message-ID: <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>

I believe you're thinking of https://github.com/ghc-proposals/ghc-proposals/pull/175. The PR has been marked accepted, but it seems it didn't get merged.

On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
> I recall a discussion in another proposal about the Lift class and 
> removing the lift function. This was for a good reason (I think it 
> stopped silent, terrible breakage). Does anyone remember where that 
> conversation took place? A quick search didn't find an accepted 
> proposal about the Lift class.
> 
> Thanks,
> Richard
> 
> > On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
> > 
> > Hi everyone,
> > 
> > This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift` class levity-polymorphic, which allows us to write proper `Lift` instances for unlifted types. It would also allow GHC to remove the special logic that currently supports lifting records with unlifted fields.
> > 
> > The main downside is the potential for breakage since `lift @Foo` would now fix the RuntimeRep parameter rather than the `a`. This is unfortunate, but I doubt it will show up much. It also unfortunately requires making both `lift` and `liftTyped` methods, when we had just decided to extract `lift` from the class. 
> > 
> > I recommend accepting the proposal.
> > 
> > Thanks!
> > Eric
> > 
> > [1]: https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
>

From rae at cs.brynmawr.edu  Tue Mar  5 03:30:03 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 4 Mar 2019 22:30:03 -0500
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
Message-ID: <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>

Thanks, Eric.

So, if we restore lift (and have it be defined in terms of liftTyped) to the Lift class, then we potentially have a problem. This is allowed today (and it works well):

> data Foo
>   deriving Data
> instance Lift Foo

But after this proposal, it will still be accepted **but will loop**. That is, the instance silently becomes a bomb waiting to maim poor clients with an obscure compile-time hang. Because of the MINIMAL pragma, there will be a warning. So perhaps we decide that the warning is enough of a deterrent and to allow this strange back-compat story.

On the other hand, if we remove lift from the class, then the above code fails with a "liftTyped is not defined" error. That's quite easy to pinpoint.

I'm not wholly against this proposal at all -- indeed, it's a nice application of levity polymorphism -- but I think there is a real drawback here worth debating.

Richard

> On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> I believe you're thinking of https://github.com/ghc-proposals/ghc-proposals/pull/175. The PR has been marked accepted, but it seems it didn't get merged.
> 
> On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
>> I recall a discussion in another proposal about the Lift class and 
>> removing the lift function. This was for a good reason (I think it 
>> stopped silent, terrible breakage). Does anyone remember where that 
>> conversation took place? A quick search didn't find an accepted 
>> proposal about the Lift class.
>> 
>> Thanks,
>> Richard
>> 
>>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
>>> 
>>> Hi everyone,
>>> 
>>> This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift` class levity-polymorphic, which allows us to write proper `Lift` instances for unlifted types. It would also allow GHC to remove the special logic that currently supports lifting records with unlifted fields.
>>> 
>>> The main downside is the potential for breakage since `lift @Foo` would now fix the RuntimeRep parameter rather than the `a`. This is unfortunate, but I doubt it will show up much. It also unfortunately requires making both `lift` and `liftTyped` methods, when we had just decided to extract `lift` from the class. 
>>> 
>>> I recommend accepting the proposal.
>>> 
>>> Thanks!
>>> Eric
>>> 
>>> [1]: https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> 


From eric at seidel.io  Tue Mar  5 04:17:41 2019
From: eric at seidel.io (Eric Seidel)
Date: Mon, 04 Mar 2019 23:17:41 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=23209=3A_Levity_poly?=
 =?utf-8?q?morphic_lift=2E_Recommendation=3A_accept?=
In-Reply-To: <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
Message-ID: <a28853c0-a897-437d-bc86-b1697ee65684@www.fastmail.com>

That's true, thank you for reminding me of our previous discussion about this issue.

I recall suggesting earlier a one-off error for empty Lift instances. It's kludgy, but easy to implement and deploy since TH is bundled with GHC. And it makes the problem go away entirely. This solution seems more compelling than it did before, since we now have a good reason for wanting both methods in the class.

Eric

On Mon, Mar 4, 2019, at 22:30, Richard Eisenberg wrote:
> Thanks, Eric.
> 
> So, if we restore lift (and have it be defined in terms of liftTyped) 
> to the Lift class, then we potentially have a problem. This is allowed 
> today (and it works well):
> 
> > data Foo
> >   deriving Data
> > instance Lift Foo
> 
> But after this proposal, it will still be accepted **but will loop**. 
> That is, the instance silently becomes a bomb waiting to maim poor 
> clients with an obscure compile-time hang. Because of the MINIMAL 
> pragma, there will be a warning. So perhaps we decide that the warning 
> is enough of a deterrent and to allow this strange back-compat story.
> 
> On the other hand, if we remove lift from the class, then the above 
> code fails with a "liftTyped is not defined" error. That's quite easy 
> to pinpoint.
> 
> I'm not wholly against this proposal at all -- indeed, it's a nice 
> application of levity polymorphism -- but I think there is a real 
> drawback here worth debating.
> 
> Richard
> 
> > On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io> wrote:
> > 
> > I believe you're thinking of https://github.com/ghc-proposals/ghc-proposals/pull/175. The PR has been marked accepted, but it seems it didn't get merged.
> > 
> > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
> >> I recall a discussion in another proposal about the Lift class and 
> >> removing the lift function. This was for a good reason (I think it 
> >> stopped silent, terrible breakage). Does anyone remember where that 
> >> conversation took place? A quick search didn't find an accepted 
> >> proposal about the Lift class.
> >> 
> >> Thanks,
> >> Richard
> >> 
> >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
> >>> 
> >>> Hi everyone,
> >>> 
> >>> This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift` class levity-polymorphic, which allows us to write proper `Lift` instances for unlifted types. It would also allow GHC to remove the special logic that currently supports lifting records with unlifted fields.
> >>> 
> >>> The main downside is the potential for breakage since `lift @Foo` would now fix the RuntimeRep parameter rather than the `a`. This is unfortunate, but I doubt it will show up much. It also unfortunately requires making both `lift` and `liftTyped` methods, when we had just decided to extract `lift` from the class. 
> >>> 
> >>> I recommend accepting the proposal.
> >>> 
> >>> Thanks!
> >>> Eric
> >>> 
> >>> [1]: https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/proposals/0000-levity-polymorphic-lift.rst
> >>> _______________________________________________
> >>> ghc-steering-committee mailing list
> >>> ghc-steering-committee at haskell.org
> >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >> 
> >> 
> 
>

From simonpj at microsoft.com  Tue Mar  5 08:13:24 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 5 Mar 2019 08:13:24 +0000
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
Message-ID: <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>

| > data Foo
| >   deriving Data
| > instance Lift Foo
| 
| But after this proposal, it will still be accepted **but will loop**. That
| is, the instance silently becomes a bomb waiting to maim poor clients with
| an obscure compile-time hang.

Can you remind us why making Lift levit-polymorphic causes this change in looping behaviour?

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Richard Eisenberg
| Sent: 05 March 2019 03:30
| To: Eric Seidel <eric at seidel.io>
| Cc: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
| lift. Recommendation: accept
| 
| Thanks, Eric.
| 
| So, if we restore lift (and have it be defined in terms of liftTyped) to
| the Lift class, then we potentially have a problem. This is allowed today
| (and it works well):
| 
| > data Foo
| >   deriving Data
| > instance Lift Foo
| 
| But after this proposal, it will still be accepted **but will loop**. That
| is, the instance silently becomes a bomb waiting to maim poor clients with
| an obscure compile-time hang. Because of the MINIMAL pragma, there will be
| a warning. So perhaps we decide that the warning is enough of a deterrent
| and to allow this strange back-compat story.
| 
| On the other hand, if we remove lift from the class, then the above code
| fails with a "liftTyped is not defined" error. That's quite easy to
| pinpoint.
| 
| I'm not wholly against this proposal at all -- indeed, it's a nice
| application of levity polymorphism -- but I think there is a real drawback
| here worth debating.
| 
| Richard
| 
| > On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io> wrote:
| >
| > I believe you're thinking of
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
| m%2Fghc-proposals%2Fghc-
| proposals%2Fpull%2F175&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89
| 805fa4e1a3f6008d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368
| 73534124463833&amp;sdata=WUd8z511ysFVYxvhdpYCtw0useZOtOq37VANULn%2BHd8%3D&a
| mp;reserved=0. The PR has been marked accepted, but it seems it didn't get
| merged.
| >
| > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
| >> I recall a discussion in another proposal about the Lift class and
| >> removing the lift function. This was for a good reason (I think it
| >> stopped silent, terrible breakage). Does anyone remember where that
| >> conversation took place? A quick search didn't find an accepted
| >> proposal about the Lift class.
| >>
| >> Thanks,
| >> Richard
| >>
| >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
| >>>
| >>> Hi everyone,
| >>>
| >>> This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift`
| class levity-polymorphic, which allows us to write proper `Lift` instances
| for unlifted types. It would also allow GHC to remove the special logic
| that currently supports lifting records with unlifted fields.
| >>>
| >>> The main downside is the potential for breakage since `lift @Foo` would
| now fix the RuntimeRep parameter rather than the `a`. This is unfortunate,
| but I doubt it will show up much. It also unfortunately requires making
| both `lift` and `liftTyped` methods, when we had just decided to extract
| `lift` from the class.
| >>>
| >>> I recommend accepting the proposal.
| >>>
| >>> Thanks!
| >>> Eric
| >>>
| >>> [1]:
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
| m%2Fharpocrates%2Fghc-proposals%2Fblob%2Flevity-polymorphic-
| lift%2Fproposals%2F0000-levity-polymorphic-
| lift.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f600
| 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833
| &amp;sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&amp;reserved=0
| >>> _______________________________________________
| >>> ghc-steering-committee mailing list
| >>> ghc-steering-committee at haskell.org
| >>>
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
| committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
| 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
| 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
| >>
| >>
| 
| _______________________________________________
| ghc-steering-committee mailing list
| ghc-steering-committee at haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
| committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
| 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
| 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0

From eric at seidel.io  Tue Mar  5 11:59:21 2019
From: eric at seidel.io (Eric Seidel)
Date: Tue, 5 Mar 2019 06:59:21 -0500
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
	lift. Recommendation: accept
In-Reply-To: <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>

It’s not that lift has become levity-polymorphic, rather both lift and liftTyped are back in Lift with mutually recursive default implementations. 

Sent from my iPhone

> On Mar 5, 2019, at 03:13, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> | > data Foo
> | >   deriving Data
> | > instance Lift Foo
> | 
> | But after this proposal, it will still be accepted **but will loop**. That
> | is, the instance silently becomes a bomb waiting to maim poor clients with
> | an obscure compile-time hang.
> 
> Can you remind us why making Lift levit-polymorphic causes this change in looping behaviour?
> 
> Simon
> 
> | -----Original Message-----
> | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> | On Behalf Of Richard Eisenberg
> | Sent: 05 March 2019 03:30
> | To: Eric Seidel <eric at seidel.io>
> | Cc: ghc-steering-committee at haskell.org
> | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
> | lift. Recommendation: accept
> | 
> | Thanks, Eric.
> | 
> | So, if we restore lift (and have it be defined in terms of liftTyped) to
> | the Lift class, then we potentially have a problem. This is allowed today
> | (and it works well):
> | 
> | > data Foo
> | >   deriving Data
> | > instance Lift Foo
> | 
> | But after this proposal, it will still be accepted **but will loop**. That
> | is, the instance silently becomes a bomb waiting to maim poor clients with
> | an obscure compile-time hang. Because of the MINIMAL pragma, there will be
> | a warning. So perhaps we decide that the warning is enough of a deterrent
> | and to allow this strange back-compat story.
> | 
> | On the other hand, if we remove lift from the class, then the above code
> | fails with a "liftTyped is not defined" error. That's quite easy to
> | pinpoint.
> | 
> | I'm not wholly against this proposal at all -- indeed, it's a nice
> | application of levity polymorphism -- but I think there is a real drawback
> | here worth debating.
> | 
> | Richard
> | 
> | > On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io> wrote:
> | >
> | > I believe you're thinking of
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> | m%2Fghc-proposals%2Fghc-
> | proposals%2Fpull%2F175&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89
> | 805fa4e1a3f6008d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368
> | 73534124463833&amp;sdata=WUd8z511ysFVYxvhdpYCtw0useZOtOq37VANULn%2BHd8%3D&a
> | mp;reserved=0. The PR has been marked accepted, but it seems it didn't get
> | merged.
> | >
> | > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
> | >> I recall a discussion in another proposal about the Lift class and
> | >> removing the lift function. This was for a good reason (I think it
> | >> stopped silent, terrible breakage). Does anyone remember where that
> | >> conversation took place? A quick search didn't find an accepted
> | >> proposal about the Lift class.
> | >>
> | >> Thanks,
> | >> Richard
> | >>
> | >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
> | >>>
> | >>> Hi everyone,
> | >>>
> | >>> This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift`
> | class levity-polymorphic, which allows us to write proper `Lift` instances
> | for unlifted types. It would also allow GHC to remove the special logic
> | that currently supports lifting records with unlifted fields.
> | >>>
> | >>> The main downside is the potential for breakage since `lift @Foo` would
> | now fix the RuntimeRep parameter rather than the `a`. This is unfortunate,
> | but I doubt it will show up much. It also unfortunately requires making
> | both `lift` and `liftTyped` methods, when we had just decided to extract
> | `lift` from the class.
> | >>>
> | >>> I recommend accepting the proposal.
> | >>>
> | >>> Thanks!
> | >>> Eric
> | >>>
> | >>> [1]:
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> | m%2Fharpocrates%2Fghc-proposals%2Fblob%2Flevity-polymorphic-
> | lift%2Fproposals%2F0000-levity-polymorphic-
> | lift.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f600
> | 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833
> | &amp;sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&amp;reserved=0
> | >>> _______________________________________________
> | >>> ghc-steering-committee mailing list
> | >>> ghc-steering-committee at haskell.org
> | >>>
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
> | 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
> | 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
> | >>
> | >>
> | 
> | _______________________________________________
> | ghc-steering-committee mailing list
> | ghc-steering-committee at haskell.org
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
> | 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
> | 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0


From rae at cs.brynmawr.edu  Tue Mar  5 13:40:34 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 5 Mar 2019 08:40:34 -0500
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
Message-ID: <979CD87B-5BFB-4ED7-81EA-3713BB4F14DB@cs.brynmawr.edu>

... and keeping lift in the type class is necessary now because moving it outside the class would violate levity-polymorphic binder restrictions.

Richard

> On Mar 5, 2019, at 6:59 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> It’s not that lift has become levity-polymorphic, rather both lift and liftTyped are back in Lift with mutually recursive default implementations. 
> 
> Sent from my iPhone
> 
>> On Mar 5, 2019, at 03:13, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> 
>> | > data Foo
>> | >   deriving Data
>> | > instance Lift Foo
>> | 
>> | But after this proposal, it will still be accepted **but will loop**. That
>> | is, the instance silently becomes a bomb waiting to maim poor clients with
>> | an obscure compile-time hang.
>> 
>> Can you remind us why making Lift levit-polymorphic causes this change in looping behaviour?
>> 
>> Simon
>> 
>> | -----Original Message-----
>> | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
>> | On Behalf Of Richard Eisenberg
>> | Sent: 05 March 2019 03:30
>> | To: Eric Seidel <eric at seidel.io>
>> | Cc: ghc-steering-committee at haskell.org
>> | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
>> | lift. Recommendation: accept
>> | 
>> | Thanks, Eric.
>> | 
>> | So, if we restore lift (and have it be defined in terms of liftTyped) to
>> | the Lift class, then we potentially have a problem. This is allowed today
>> | (and it works well):
>> | 
>> | > data Foo
>> | >   deriving Data
>> | > instance Lift Foo
>> | 
>> | But after this proposal, it will still be accepted **but will loop**. That
>> | is, the instance silently becomes a bomb waiting to maim poor clients with
>> | an obscure compile-time hang. Because of the MINIMAL pragma, there will be
>> | a warning. So perhaps we decide that the warning is enough of a deterrent
>> | and to allow this strange back-compat story.
>> | 
>> | On the other hand, if we remove lift from the class, then the above code
>> | fails with a "liftTyped is not defined" error. That's quite easy to
>> | pinpoint.
>> | 
>> | I'm not wholly against this proposal at all -- indeed, it's a nice
>> | application of levity polymorphism -- but I think there is a real drawback
>> | here worth debating.
>> | 
>> | Richard
>> | 
>> | > On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io> wrote:
>> | >
>> | > I believe you're thinking of
>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>> | m%2Fghc-proposals%2Fghc-
>> | proposals%2Fpull%2F175&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89
>> | 805fa4e1a3f6008d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368
>> | 73534124463833&amp;sdata=WUd8z511ysFVYxvhdpYCtw0useZOtOq37VANULn%2BHd8%3D&a
>> | mp;reserved=0. The PR has been marked accepted, but it seems it didn't get
>> | merged.
>> | >
>> | > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
>> | >> I recall a discussion in another proposal about the Lift class and
>> | >> removing the lift function. This was for a good reason (I think it
>> | >> stopped silent, terrible breakage). Does anyone remember where that
>> | >> conversation took place? A quick search didn't find an accepted
>> | >> proposal about the Lift class.
>> | >>
>> | >> Thanks,
>> | >> Richard
>> | >>
>> | >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
>> | >>>
>> | >>> Hi everyone,
>> | >>>
>> | >>> This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift`
>> | class levity-polymorphic, which allows us to write proper `Lift` instances
>> | for unlifted types. It would also allow GHC to remove the special logic
>> | that currently supports lifting records with unlifted fields.
>> | >>>
>> | >>> The main downside is the potential for breakage since `lift @Foo` would
>> | now fix the RuntimeRep parameter rather than the `a`. This is unfortunate,
>> | but I doubt it will show up much. It also unfortunately requires making
>> | both `lift` and `liftTyped` methods, when we had just decided to extract
>> | `lift` from the class.
>> | >>>
>> | >>> I recommend accepting the proposal.
>> | >>>
>> | >>> Thanks!
>> | >>> Eric
>> | >>>
>> | >>> [1]:
>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>> | m%2Fharpocrates%2Fghc-proposals%2Fblob%2Flevity-polymorphic-
>> | lift%2Fproposals%2F0000-levity-polymorphic-
>> | lift.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f600
>> | 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833
>> | &amp;sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&amp;reserved=0
>> | >>> _______________________________________________
>> | >>> ghc-steering-committee mailing list
>> | >>> ghc-steering-committee at haskell.org
>> | >>>
>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
>> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> | committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
>> | 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
>> | 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
>> | >>
>> | >>
>> | 
>> | _______________________________________________
>> | ghc-steering-committee mailing list
>> | ghc-steering-committee at haskell.org
>> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
>> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> | committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
>> | 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
>> | 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
> 


From simonpj at microsoft.com  Tue Mar  5 16:34:21 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 5 Mar 2019 16:34:21 +0000
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
Message-ID: <DB7PR83MB029819400A9669497730E074AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>

| It’s not that lift has become levity-polymorphic, rather both lift and
| liftTyped are back in Lift with mutually recursive default implementations.

OK, so just like (==) and (/=) in class Eq.  What's the time-bomb?  Does Eq suffer from it?

Simon

| -----Original Message-----
| From: Eric Seidel <eric at seidel.io>
| Sent: 05 March 2019 11:59
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-
| committee at haskell.org
| Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
| lift. Recommendation: accept
| 
| It’s not that lift has become levity-polymorphic, rather both lift and
| liftTyped are back in Lift with mutually recursive default implementations.
| 
| Sent from my iPhone
| 
| > On Mar 5, 2019, at 03:13, Simon Peyton Jones <simonpj at microsoft.com>
| wrote:
| >
| > | > data Foo
| > | >   deriving Data
| > | > instance Lift Foo
| > |
| > | But after this proposal, it will still be accepted **but will loop**.
| That
| > | is, the instance silently becomes a bomb waiting to maim poor clients
| with
| > | an obscure compile-time hang.
| >
| > Can you remind us why making Lift levit-polymorphic causes this change in
| looping behaviour?
| >
| > Simon
| >
| > | -----Original Message-----
| > | From: ghc-steering-committee <ghc-steering-committee-
| bounces at haskell.org>
| > | On Behalf Of Richard Eisenberg
| > | Sent: 05 March 2019 03:30
| > | To: Eric Seidel <eric at seidel.io>
| > | Cc: ghc-steering-committee at haskell.org
| > | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
| > | lift. Recommendation: accept
| > |
| > | Thanks, Eric.
| > |
| > | So, if we restore lift (and have it be defined in terms of liftTyped)
| to
| > | the Lift class, then we potentially have a problem. This is allowed
| today
| > | (and it works well):
| > |
| > | > data Foo
| > | >   deriving Data
| > | > instance Lift Foo
| > |
| > | But after this proposal, it will still be accepted **but will loop**.
| That
| > | is, the instance silently becomes a bomb waiting to maim poor clients
| with
| > | an obscure compile-time hang. Because of the MINIMAL pragma, there will
| be
| > | a warning. So perhaps we decide that the warning is enough of a
| deterrent
| > | and to allow this strange back-compat story.
| > |
| > | On the other hand, if we remove lift from the class, then the above
| code
| > | fails with a "liftTyped is not defined" error. That's quite easy to
| > | pinpoint.
| > |
| > | I'm not wholly against this proposal at all -- indeed, it's a nice
| > | application of levity polymorphism -- but I think there is a real
| drawback
| > | here worth debating.
| > |
| > | Richard
| > |
| > | > On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io> wrote:
| > | >
| > | > I believe you're thinking of
| > |
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
| > | m%2Fghc-proposals%2Fghc-
| > |
| proposals%2Fpull%2F175&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89
| > |
| 805fa4e1a3f6008d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368
| > |
| 73534124463833&amp;sdata=WUd8z511ysFVYxvhdpYCtw0useZOtOq37VANULn%2BHd8%3D&a
| > | mp;reserved=0. The PR has been marked accepted, but it seems it didn't
| get
| > | merged.
| > | >
| > | > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
| > | >> I recall a discussion in another proposal about the Lift class and
| > | >> removing the lift function. This was for a good reason (I think it
| > | >> stopped silent, terrible breakage). Does anyone remember where that
| > | >> conversation took place? A quick search didn't find an accepted
| > | >> proposal about the Lift class.
| > | >>
| > | >> Thanks,
| > | >> Richard
| > | >>
| > | >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
| > | >>>
| > | >>> Hi everyone,
| > | >>>
| > | >>> This proposal[1] makes the `lift` and `liftTyped` methods of the
| `Lift`
| > | class levity-polymorphic, which allows us to write proper `Lift`
| instances
| > | for unlifted types. It would also allow GHC to remove the special logic
| > | that currently supports lifting records with unlifted fields.
| > | >>>
| > | >>> The main downside is the potential for breakage since `lift @Foo`
| would
| > | now fix the RuntimeRep parameter rather than the `a`. This is
| unfortunate,
| > | but I doubt it will show up much. It also unfortunately requires making
| > | both `lift` and `liftTyped` methods, when we had just decided to
| extract
| > | `lift` from the class.
| > | >>>
| > | >>> I recommend accepting the proposal.
| > | >>>
| > | >>> Thanks!
| > | >>> Eric
| > | >>>
| > | >>> [1]:
| > |
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
| > | m%2Fharpocrates%2Fghc-proposals%2Fblob%2Flevity-polymorphic-
| > | lift%2Fproposals%2F0000-levity-polymorphic-
| > |
| lift.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f600
| > |
| 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833
| > |
| &amp;sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&amp;reserved=0
| > | >>> _______________________________________________
| > | >>> ghc-steering-committee mailing list
| > | >>> ghc-steering-committee at haskell.org
| > | >>>
| > |
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
| > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
| > |
| committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
| > |
| 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
| > |
| 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
| > | >>
| > | >>
| > |
| > | _______________________________________________
| > | ghc-steering-committee mailing list
| > | ghc-steering-committee at haskell.org
| > |
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
| > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
| > |
| committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
| > |
| 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
| > |
| 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0


From simonpj at microsoft.com  Tue Mar  5 16:34:26 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 5 Mar 2019 16:34:26 +0000
Subject: [ghc-steering-committee] Discussion on #155 Type
	Variable	in	Labmdas
In-Reply-To: <78A08A87-F650-4F37-B5CC-BA011C509D3D@cs.brynmawr.edu>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <78A08A87-F650-4F37-B5CC-BA011C509D3D@cs.brynmawr.edu>
Message-ID: <DB7PR83MB0298918C10588EB2476BC831AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>

I haven't thought through the consequences of this fully, but it does seem plausible.

It says we must generalise over some ‘a’, but which ‘a’?  What type does (\@a (\x. x)) have?   I suppose you could say (forall b. (forall a. b -> b)), but presumably it could equally well have the type (forall a. a->a).

I think I can see an algorithm.  But someone would need to write down a type system.

(I think I was probably was wrong to mutter about impredicativity.)

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 05 March 2019 03:06
To: Eric Seidel <eric at seidel.io>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas




On Mar 3, 2019, at 8:44 PM, Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>> wrote:

Why not say that `\ @a -> body` infers the type `forall a. ty` where `body :: ty`, and let unification handle the rest?

That's intriguingly simple. I haven't thought through the consequences of this fully, but it does seem plausible. I'm not ready to commit to that, but after a few minutes' focused thought, I can't see any problems with it. In any case, the proposal as written is forward-compatible with such a change, as doing what you say will allow only more programs: ones accepted by the proposal will remain accepted and with the same meanings.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190305/1718616c/attachment-0001.html>

From eric at seidel.io  Tue Mar  5 16:42:25 2019
From: eric at seidel.io (Eric Seidel)
Date: Tue, 05 Mar 2019 11:42:25 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=23209=3A_Levity_poly?=
 =?utf-8?q?morphic_lift=2E_Recommendation=3A_accept?=
In-Reply-To: <DB7PR83MB029819400A9669497730E074AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
 <DB7PR83MB029819400A9669497730E074AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <7d0c15f7-06ec-4a0a-bbb8-faa1907f661d@www.fastmail.com>

The time-bomb is that there may exist empty Lift instances that are *currently safe* because there's a single lift method with a default implementation. Once you add the liftTyped method, and make the default implementations mutually recursive, these empty instances suddenly become unsafe.

Eq would have the same problem if we had first defined it solely in terms of (==), with a default implementation, and then later decided to add (/=) and make the defaults mutually recursive.

It's not a problem with the mutually recursive definitions per se, rather with the migration path.

On Tue, Mar 5, 2019, at 11:34, Simon Peyton Jones wrote:
> | It’s not that lift has become levity-polymorphic, rather both lift and
> | liftTyped are back in Lift with mutually recursive default implementations.
> 
> OK, so just like (==) and (/=) in class Eq.  What's the time-bomb?  
> Does Eq suffer from it?
> 
> Simon
> 
> | -----Original Message-----
> | From: Eric Seidel <eric at seidel.io>
> | Sent: 05 March 2019 11:59
> | To: Simon Peyton Jones <simonpj at microsoft.com>
> | Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-
> | committee at haskell.org
> | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
> | lift. Recommendation: accept
> | 
> | It’s not that lift has become levity-polymorphic, rather both lift and
> | liftTyped are back in Lift with mutually recursive default implementations.
> | 
> | Sent from my iPhone
> | 
> | > On Mar 5, 2019, at 03:13, Simon Peyton Jones <simonpj at microsoft.com>
> | wrote:
> | >
> | > | > data Foo
> | > | >   deriving Data
> | > | > instance Lift Foo
> | > |
> | > | But after this proposal, it will still be accepted **but will loop**.
> | That
> | > | is, the instance silently becomes a bomb waiting to maim poor clients
> | with
> | > | an obscure compile-time hang.
> | >
> | > Can you remind us why making Lift levit-polymorphic causes this change in
> | looping behaviour?
> | >
> | > Simon
> | >
> | > | -----Original Message-----
> | > | From: ghc-steering-committee <ghc-steering-committee-
> | bounces at haskell.org>
> | > | On Behalf Of Richard Eisenberg
> | > | Sent: 05 March 2019 03:30
> | > | To: Eric Seidel <eric at seidel.io>
> | > | Cc: ghc-steering-committee at haskell.org
> | > | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
> | > | lift. Recommendation: accept
> | > |
> | > | Thanks, Eric.
> | > |
> | > | So, if we restore lift (and have it be defined in terms of liftTyped)
> | to
> | > | the Lift class, then we potentially have a problem. This is allowed
> | today
> | > | (and it works well):
> | > |
> | > | > data Foo
> | > | >   deriving Data
> | > | > instance Lift Foo
> | > |
> | > | But after this proposal, it will still be accepted **but will loop**.
> | That
> | > | is, the instance silently becomes a bomb waiting to maim poor clients
> | with
> | > | an obscure compile-time hang. Because of the MINIMAL pragma, there will
> | be
> | > | a warning. So perhaps we decide that the warning is enough of a
> | deterrent
> | > | and to allow this strange back-compat story.
> | > |
> | > | On the other hand, if we remove lift from the class, then the above
> | code
> | > | fails with a "liftTyped is not defined" error. That's quite easy to
> | > | pinpoint.
> | > |
> | > | I'm not wholly against this proposal at all -- indeed, it's a nice
> | > | application of levity polymorphism -- but I think there is a real
> | drawback
> | > | here worth debating.
> | > |
> | > | Richard
> | > |
> | > | > On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io> wrote:
> | > | >
> | > | > I believe you're thinking of
> | > |
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> | > | m%2Fghc-proposals%2Fghc-
> | > |
> | proposals%2Fpull%2F175&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89
> | > |
> | 805fa4e1a3f6008d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368
> | > |
> | 73534124463833&amp;sdata=WUd8z511ysFVYxvhdpYCtw0useZOtOq37VANULn%2BHd8%3D&a
> | > | mp;reserved=0. The PR has been marked accepted, but it seems it didn't
> | get
> | > | merged.
> | > | >
> | > | > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
> | > | >> I recall a discussion in another proposal about the Lift class and
> | > | >> removing the lift function. This was for a good reason (I think it
> | > | >> stopped silent, terrible breakage). Does anyone remember where that
> | > | >> conversation took place? A quick search didn't find an accepted
> | > | >> proposal about the Lift class.
> | > | >>
> | > | >> Thanks,
> | > | >> Richard
> | > | >>
> | > | >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
> | > | >>>
> | > | >>> Hi everyone,
> | > | >>>
> | > | >>> This proposal[1] makes the `lift` and `liftTyped` methods of the
> | `Lift`
> | > | class levity-polymorphic, which allows us to write proper `Lift`
> | instances
> | > | for unlifted types. It would also allow GHC to remove the special logic
> | > | that currently supports lifting records with unlifted fields.
> | > | >>>
> | > | >>> The main downside is the potential for breakage since `lift @Foo`
> | would
> | > | now fix the RuntimeRep parameter rather than the `a`. This is
> | unfortunate,
> | > | but I doubt it will show up much. It also unfortunately requires making
> | > | both `lift` and `liftTyped` methods, when we had just decided to
> | extract
> | > | `lift` from the class.
> | > | >>>
> | > | >>> I recommend accepting the proposal.
> | > | >>>
> | > | >>> Thanks!
> | > | >>> Eric
> | > | >>>
> | > | >>> [1]:
> | > |
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> | > | m%2Fharpocrates%2Fghc-proposals%2Fblob%2Flevity-polymorphic-
> | > | lift%2Fproposals%2F0000-levity-polymorphic-
> | > |
> | lift.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f600
> | > |
> | 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833
> | > |
> | &amp;sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&amp;reserved=0
> | > | >>> _______________________________________________
> | > | >>> ghc-steering-committee mailing list
> | > | >>> ghc-steering-committee at haskell.org
> | > | >>>
> | > |
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
> | > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | > |
> | committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
> | > |
> | 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
> | > |
> | 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
> | > | >>
> | > | >>
> | > |
> | > | _______________________________________________
> | > | ghc-steering-committee mailing list
> | > | ghc-steering-committee at haskell.org
> | > |
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
> | > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | > |
> | committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
> | > |
> | 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
> | > |
> | 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
> 
>

From simonpj at microsoft.com  Tue Mar  5 16:45:55 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 5 Mar 2019 16:45:55 +0000
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <7d0c15f7-06ec-4a0a-bbb8-faa1907f661d@www.fastmail.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
 <DB7PR83MB029819400A9669497730E074AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7d0c15f7-06ec-4a0a-bbb8-faa1907f661d@www.fastmail.com>
Message-ID: <DB7PR83MB0298EE7DFE19DEB0961B343BAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>

| It's not a problem with the mutually recursive definitions per se, rather
| with the migration path.

Ah.  Now I understand, thanks.

S

| -----Original Message-----
| From: Eric Seidel <eric at seidel.io>
| Sent: 05 March 2019 16:42
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-
| committee at haskell.org
| Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
| lift. Recommendation: accept
| 
| The time-bomb is that there may exist empty Lift instances that are
| *currently safe* because there's a single lift method with a default
| implementation. Once you add the liftTyped method, and make the default
| implementations mutually recursive, these empty instances suddenly become
| unsafe.
| 
| Eq would have the same problem if we had first defined it solely in terms
| of (==), with a default implementation, and then later decided to add (/=)
| and make the defaults mutually recursive.
| 
| It's not a problem with the mutually recursive definitions per se, rather
| with the migration path.
| 
| On Tue, Mar 5, 2019, at 11:34, Simon Peyton Jones wrote:
| > | It’s not that lift has become levity-polymorphic, rather both lift and
| > | liftTyped are back in Lift with mutually recursive default
| implementations.
| >
| > OK, so just like (==) and (/=) in class Eq.  What's the time-bomb?
| > Does Eq suffer from it?
| >
| > Simon
| >
| > | -----Original Message-----
| > | From: Eric Seidel <eric at seidel.io>
| > | Sent: 05 March 2019 11:59
| > | To: Simon Peyton Jones <simonpj at microsoft.com>
| > | Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-
| > | committee at haskell.org
| > | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
| > | lift. Recommendation: accept
| > |
| > | It’s not that lift has become levity-polymorphic, rather both lift and
| > | liftTyped are back in Lift with mutually recursive default
| implementations.
| > |
| > | Sent from my iPhone
| > |
| > | > On Mar 5, 2019, at 03:13, Simon Peyton Jones <simonpj at microsoft.com>
| > | wrote:
| > | >
| > | > | > data Foo
| > | > | >   deriving Data
| > | > | > instance Lift Foo
| > | > |
| > | > | But after this proposal, it will still be accepted **but will
| loop**.
| > | That
| > | > | is, the instance silently becomes a bomb waiting to maim poor
| clients
| > | with
| > | > | an obscure compile-time hang.
| > | >
| > | > Can you remind us why making Lift levit-polymorphic causes this
| change in
| > | looping behaviour?
| > | >
| > | > Simon
| > | >
| > | > | -----Original Message-----
| > | > | From: ghc-steering-committee <ghc-steering-committee-
| > | bounces at haskell.org>
| > | > | On Behalf Of Richard Eisenberg
| > | > | Sent: 05 March 2019 03:30
| > | > | To: Eric Seidel <eric at seidel.io>
| > | > | Cc: ghc-steering-committee at haskell.org
| > | > | Subject: Re: [ghc-steering-committee] Proposal #209: Levity
| polymorphic
| > | > | lift. Recommendation: accept
| > | > |
| > | > | Thanks, Eric.
| > | > |
| > | > | So, if we restore lift (and have it be defined in terms of
| liftTyped)
| > | to
| > | > | the Lift class, then we potentially have a problem. This is allowed
| > | today
| > | > | (and it works well):
| > | > |
| > | > | > data Foo
| > | > | >   deriving Data
| > | > | > instance Lift Foo
| > | > |
| > | > | But after this proposal, it will still be accepted **but will
| loop**.
| > | That
| > | > | is, the instance silently becomes a bomb waiting to maim poor
| clients
| > | with
| > | > | an obscure compile-time hang. Because of the MINIMAL pragma, there
| will
| > | be
| > | > | a warning. So perhaps we decide that the warning is enough of a
| > | deterrent
| > | > | and to allow this strange back-compat story.
| > | > |
| > | > | On the other hand, if we remove lift from the class, then the above
| > | code
| > | > | fails with a "liftTyped is not defined" error. That's quite easy to
| > | > | pinpoint.
| > | > |
| > | > | I'm not wholly against this proposal at all -- indeed, it's a nice
| > | > | application of levity polymorphism -- but I think there is a real
| > | drawback
| > | > | here worth debating.
| > | > |
| > | > | Richard
| > | > |
| > | > | > On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io> wrote:
| > | > | >
| > | > | > I believe you're thinking of
| > | > |
| > |
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
| > | > | m%2Fghc-proposals%2Fghc-
| > | > |
| > |
| proposals%2Fpull%2F175&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89
| > | > |
| > |
| 805fa4e1a3f6008d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368
| > | > |
| > |
| 73534124463833&amp;sdata=WUd8z511ysFVYxvhdpYCtw0useZOtOq37VANULn%2BHd8%3D&a
| > | > | mp;reserved=0. The PR has been marked accepted, but it seems it
| didn't
| > | get
| > | > | merged.
| > | > | >
| > | > | > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
| > | > | >> I recall a discussion in another proposal about the Lift class
| and
| > | > | >> removing the lift function. This was for a good reason (I think
| it
| > | > | >> stopped silent, terrible breakage). Does anyone remember where
| that
| > | > | >> conversation took place? A quick search didn't find an accepted
| > | > | >> proposal about the Lift class.
| > | > | >>
| > | > | >> Thanks,
| > | > | >> Richard
| > | > | >>
| > | > | >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io> wrote:
| > | > | >>>
| > | > | >>> Hi everyone,
| > | > | >>>
| > | > | >>> This proposal[1] makes the `lift` and `liftTyped` methods of
| the
| > | `Lift`
| > | > | class levity-polymorphic, which allows us to write proper `Lift`
| > | instances
| > | > | for unlifted types. It would also allow GHC to remove the special
| logic
| > | > | that currently supports lifting records with unlifted fields.
| > | > | >>>
| > | > | >>> The main downside is the potential for breakage since `lift
| @Foo`
| > | would
| > | > | now fix the RuntimeRep parameter rather than the `a`. This is
| > | unfortunate,
| > | > | but I doubt it will show up much. It also unfortunately requires
| making
| > | > | both `lift` and `liftTyped` methods, when we had just decided to
| > | extract
| > | > | `lift` from the class.
| > | > | >>>
| > | > | >>> I recommend accepting the proposal.
| > | > | >>>
| > | > | >>> Thanks!
| > | > | >>> Eric
| > | > | >>>
| > | > | >>> [1]:
| > | > |
| > |
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
| > | > | m%2Fharpocrates%2Fghc-proposals%2Fblob%2Flevity-polymorphic-
| > | > | lift%2Fproposals%2F0000-levity-polymorphic-
| > | > |
| > |
| lift.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f600
| > | > |
| > |
| 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833
| > | > |
| > |
| &amp;sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&amp;reserved=0
| > | > | >>> _______________________________________________
| > | > | >>> ghc-steering-committee mailing list
| > | > | >>> ghc-steering-committee at haskell.org
| > | > | >>>
| > | > |
| > |
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
| > | > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
| > | > |
| > |
| committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
| > | > |
| > |
| 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
| > | > |
| > |
| 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
| > | > | >>
| > | > | >>
| > | > |
| > | > | _______________________________________________
| > | > | ghc-steering-committee mailing list
| > | > | ghc-steering-committee at haskell.org
| > | > |
| > |
| https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
| > | > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
| > | > |
| > |
| committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C179fc89805fa4e1a3f60
| > | > |
| > |
| 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
| > | > |
| > |
| 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
| >
| >

From iavor.diatchki at gmail.com  Tue Mar  5 17:37:19 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 5 Mar 2019 09:37:19 -0800
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <DB7PR83MB0298EE7DFE19DEB0961B343BAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
 <DB7PR83MB029819400A9669497730E074AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7d0c15f7-06ec-4a0a-bbb8-faa1907f661d@www.fastmail.com>
 <DB7PR83MB0298EE7DFE19DEB0961B343BAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nupp7A5nJ=q3arxCCUSTQgMM+W33XcpSGgtSzso93VDO=Q@mail.gmail.com>

What if we simply do not have a default on the `liftTyped` method?

The default is kind of dodgy anyway, as it uses the unsafe cast operator,
and so an incorrect implementation of `lift` will result in an ill typed
result.

On Tue, Mar 5, 2019, 08:46 Simon Peyton Jones via ghc-steering-committee <
ghc-steering-committee at haskell.org> wrote:

> | It's not a problem with the mutually recursive definitions per se, rather
> | with the migration path.
>
> Ah.  Now I understand, thanks.
>
> S
>
> | -----Original Message-----
> | From: Eric Seidel <eric at seidel.io>
> | Sent: 05 March 2019 16:42
> | To: Simon Peyton Jones <simonpj at microsoft.com>
> | Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-
> | committee at haskell.org
> | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
> | lift. Recommendation: accept
> |
> | The time-bomb is that there may exist empty Lift instances that are
> | *currently safe* because there's a single lift method with a default
> | implementation. Once you add the liftTyped method, and make the default
> | implementations mutually recursive, these empty instances suddenly become
> | unsafe.
> |
> | Eq would have the same problem if we had first defined it solely in terms
> | of (==), with a default implementation, and then later decided to add
> (/=)
> | and make the defaults mutually recursive.
> |
> | It's not a problem with the mutually recursive definitions per se, rather
> | with the migration path.
> |
> | On Tue, Mar 5, 2019, at 11:34, Simon Peyton Jones wrote:
> | > | It’s not that lift has become levity-polymorphic, rather both lift
> and
> | > | liftTyped are back in Lift with mutually recursive default
> | implementations.
> | >
> | > OK, so just like (==) and (/=) in class Eq.  What's the time-bomb?
> | > Does Eq suffer from it?
> | >
> | > Simon
> | >
> | > | -----Original Message-----
> | > | From: Eric Seidel <eric at seidel.io>
> | > | Sent: 05 March 2019 11:59
> | > | To: Simon Peyton Jones <simonpj at microsoft.com>
> | > | Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-
> | > | committee at haskell.org
> | > | Subject: Re: [ghc-steering-committee] Proposal #209: Levity
> polymorphic
> | > | lift. Recommendation: accept
> | > |
> | > | It’s not that lift has become levity-polymorphic, rather both lift
> and
> | > | liftTyped are back in Lift with mutually recursive default
> | implementations.
> | > |
> | > | Sent from my iPhone
> | > |
> | > | > On Mar 5, 2019, at 03:13, Simon Peyton Jones <
> simonpj at microsoft.com>
> | > | wrote:
> | > | >
> | > | > | > data Foo
> | > | > | >   deriving Data
> | > | > | > instance Lift Foo
> | > | > |
> | > | > | But after this proposal, it will still be accepted **but will
> | loop**.
> | > | That
> | > | > | is, the instance silently becomes a bomb waiting to maim poor
> | clients
> | > | with
> | > | > | an obscure compile-time hang.
> | > | >
> | > | > Can you remind us why making Lift levit-polymorphic causes this
> | change in
> | > | looping behaviour?
> | > | >
> | > | > Simon
> | > | >
> | > | > | -----Original Message-----
> | > | > | From: ghc-steering-committee <ghc-steering-committee-
> | > | bounces at haskell.org>
> | > | > | On Behalf Of Richard Eisenberg
> | > | > | Sent: 05 March 2019 03:30
> | > | > | To: Eric Seidel <eric at seidel.io>
> | > | > | Cc: ghc-steering-committee at haskell.org
> | > | > | Subject: Re: [ghc-steering-committee] Proposal #209: Levity
> | polymorphic
> | > | > | lift. Recommendation: accept
> | > | > |
> | > | > | Thanks, Eric.
> | > | > |
> | > | > | So, if we restore lift (and have it be defined in terms of
> | liftTyped)
> | > | to
> | > | > | the Lift class, then we potentially have a problem. This is
> allowed
> | > | today
> | > | > | (and it works well):
> | > | > |
> | > | > | > data Foo
> | > | > | >   deriving Data
> | > | > | > instance Lift Foo
> | > | > |
> | > | > | But after this proposal, it will still be accepted **but will
> | loop**.
> | > | That
> | > | > | is, the instance silently becomes a bomb waiting to maim poor
> | clients
> | > | with
> | > | > | an obscure compile-time hang. Because of the MINIMAL pragma,
> there
> | will
> | > | be
> | > | > | a warning. So perhaps we decide that the warning is enough of a
> | > | deterrent
> | > | > | and to allow this strange back-compat story.
> | > | > |
> | > | > | On the other hand, if we remove lift from the class, then the
> above
> | > | code
> | > | > | fails with a "liftTyped is not defined" error. That's quite easy
> to
> | > | > | pinpoint.
> | > | > |
> | > | > | I'm not wholly against this proposal at all -- indeed, it's a
> nice
> | > | > | application of levity polymorphism -- but I think there is a real
> | > | drawback
> | > | > | here worth debating.
> | > | > |
> | > | > | Richard
> | > | > |
> | > | > | > On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io>
> wrote:
> | > | > | >
> | > | > | > I believe you're thinking of
> | > | > |
> | > |
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> | > | > | m%2Fghc-proposals%2Fghc-
> | > | > |
> | > |
> | proposals%2Fpull%2F175&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C179fc89
> | > | > |
> | > |
> |
> 805fa4e1a3f6008d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368
> | > | > |
> | > |
> |
> 73534124463833&amp;sdata=WUd8z511ysFVYxvhdpYCtw0useZOtOq37VANULn%2BHd8%3D&a
> | > | > | mp;reserved=0. The PR has been marked accepted, but it seems it
> | didn't
> | > | get
> | > | > | merged.
> | > | > | >
> | > | > | > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
> | > | > | >> I recall a discussion in another proposal about the Lift class
> | and
> | > | > | >> removing the lift function. This was for a good reason (I
> think
> | it
> | > | > | >> stopped silent, terrible breakage). Does anyone remember where
> | that
> | > | > | >> conversation took place? A quick search didn't find an
> accepted
> | > | > | >> proposal about the Lift class.
> | > | > | >>
> | > | > | >> Thanks,
> | > | > | >> Richard
> | > | > | >>
> | > | > | >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io>
> wrote:
> | > | > | >>>
> | > | > | >>> Hi everyone,
> | > | > | >>>
> | > | > | >>> This proposal[1] makes the `lift` and `liftTyped` methods of
> | the
> | > | `Lift`
> | > | > | class levity-polymorphic, which allows us to write proper `Lift`
> | > | instances
> | > | > | for unlifted types. It would also allow GHC to remove the special
> | logic
> | > | > | that currently supports lifting records with unlifted fields.
> | > | > | >>>
> | > | > | >>> The main downside is the potential for breakage since `lift
> | @Foo`
> | > | would
> | > | > | now fix the RuntimeRep parameter rather than the `a`. This is
> | > | unfortunate,
> | > | > | but I doubt it will show up much. It also unfortunately requires
> | making
> | > | > | both `lift` and `liftTyped` methods, when we had just decided to
> | > | extract
> | > | > | `lift` from the class.
> | > | > | >>>
> | > | > | >>> I recommend accepting the proposal.
> | > | > | >>>
> | > | > | >>> Thanks!
> | > | > | >>> Eric
> | > | > | >>>
> | > | > | >>> [1]:
> | > | > |
> | > |
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> | > | > | m%2Fharpocrates%2Fghc-proposals%2Fblob%2Flevity-polymorphic-
> | > | > | lift%2Fproposals%2F0000-levity-polymorphic-
> | > | > |
> | > |
> | lift.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C179fc89805fa4e1a3f600
> | > | > |
> | > |
> |
> 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833
> | > | > |
> | > |
> |
> &amp;sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&amp;reserved=0
> | > | > | >>> _______________________________________________
> | > | > | >>> ghc-steering-committee mailing list
> | > | > | >>> ghc-steering-committee at haskell.org
> | > | > | >>>
> | > | > |
> | > |
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
> | > | > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | > | > |
> | > |
> | committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C179fc89805fa4e1a3f60
> | > | > |
> | > |
> |
> 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
> | > | > |
> | > |
> |
> 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
> | > | > | >>
> | > | > | >>
> | > | > |
> | > | > | _______________________________________________
> | > | > | ghc-steering-committee mailing list
> | > | > | ghc-steering-committee at haskell.org
> | > | > |
> | > |
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask
> | > | > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | > | > |
> | > |
> | committee&amp;data=02%7C01%7Csimonpj%40microsoft.com
> %7C179fc89805fa4e1a3f60
> | > | > |
> | > |
> |
> 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
> | > | > |
> | > |
> |
> 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
> | >
> | >
> _______________________________________________
> 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/20190305/b62ffc0d/attachment-0001.html>

From rae at cs.brynmawr.edu  Tue Mar  5 21:14:39 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 5 Mar 2019 16:14:39 -0500
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <CAGK9nupp7A5nJ=q3arxCCUSTQgMM+W33XcpSGgtSzso93VDO=Q@mail.gmail.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
 <DB7PR83MB029819400A9669497730E074AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7d0c15f7-06ec-4a0a-bbb8-faa1907f661d@www.fastmail.com>
 <DB7PR83MB0298EE7DFE19DEB0961B343BAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAGK9nupp7A5nJ=q3arxCCUSTQgMM+W33XcpSGgtSzso93VDO=Q@mail.gmail.com>
Message-ID: <C0491A7D-5451-4E19-B270-A97659AE0074@cs.brynmawr.edu>



> On Mar 5, 2019, at 12:37 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> What if we simply do not have a default on the `liftTyped` method? 

That might work. This means that old hand-written instances for Lift will be broken -- but we've agreed that's OK. New (generated) instances will use liftTyped.

Is it possible to write liftTyped in a generic way, like the way the old lift had a generic default? That might solve all the problems at once.

Richard

> 
> The default is kind of dodgy anyway, as it uses the unsafe cast operator, and so an incorrect implementation of `lift` will result in an ill typed result.
> 
> On Tue, Mar 5, 2019, 08:46 Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
> | It's not a problem with the mutually recursive definitions per se, rather
> | with the migration path.
> 
> Ah.  Now I understand, thanks.
> 
> S
> 
> | -----Original Message-----
> | From: Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>
> | Sent: 05 March 2019 16:42
> | To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> | Cc: Richard Eisenberg <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>>; ghc-steering-
> | committee at haskell.org <mailto:committee at haskell.org>
> | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
> | lift. Recommendation: accept
> | 
> | The time-bomb is that there may exist empty Lift instances that are
> | *currently safe* because there's a single lift method with a default
> | implementation. Once you add the liftTyped method, and make the default
> | implementations mutually recursive, these empty instances suddenly become
> | unsafe.
> | 
> | Eq would have the same problem if we had first defined it solely in terms
> | of (==), with a default implementation, and then later decided to add (/=)
> | and make the defaults mutually recursive.
> | 
> | It's not a problem with the mutually recursive definitions per se, rather
> | with the migration path.
> | 
> | On Tue, Mar 5, 2019, at 11:34, Simon Peyton Jones wrote:
> | > | It’s not that lift has become levity-polymorphic, rather both lift and
> | > | liftTyped are back in Lift with mutually recursive default
> | implementations.
> | >
> | > OK, so just like (==) and (/=) in class Eq.  What's the time-bomb?
> | > Does Eq suffer from it?
> | >
> | > Simon
> | >
> | > | -----Original Message-----
> | > | From: Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>
> | > | Sent: 05 March 2019 11:59
> | > | To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> | > | Cc: Richard Eisenberg <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>>; ghc-steering-
> | > | committee at haskell.org <mailto:committee at haskell.org>
> | > | Subject: Re: [ghc-steering-committee] Proposal #209: Levity polymorphic
> | > | lift. Recommendation: accept
> | > |
> | > | It’s not that lift has become levity-polymorphic, rather both lift and
> | > | liftTyped are back in Lift with mutually recursive default
> | implementations.
> | > |
> | > | Sent from my iPhone
> | > |
> | > | > On Mar 5, 2019, at 03:13, Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> | > | wrote:
> | > | >
> | > | > | > data Foo
> | > | > | >   deriving Data
> | > | > | > instance Lift Foo
> | > | > |
> | > | > | But after this proposal, it will still be accepted **but will
> | loop**.
> | > | That
> | > | > | is, the instance silently becomes a bomb waiting to maim poor
> | clients
> | > | with
> | > | > | an obscure compile-time hang.
> | > | >
> | > | > Can you remind us why making Lift levit-polymorphic causes this
> | change in
> | > | looping behaviour?
> | > | >
> | > | > Simon
> | > | >
> | > | > | -----Original Message-----
> | > | > | From: ghc-steering-committee <ghc-steering-committee-
> | > | bounces at haskell.org <mailto:bounces at haskell.org>>
> | > | > | On Behalf Of Richard Eisenberg
> | > | > | Sent: 05 March 2019 03:30
> | > | > | To: Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>
> | > | > | Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> | > | > | Subject: Re: [ghc-steering-committee] Proposal #209: Levity
> | polymorphic
> | > | > | lift. Recommendation: accept
> | > | > |
> | > | > | Thanks, Eric.
> | > | > |
> | > | > | So, if we restore lift (and have it be defined in terms of
> | liftTyped)
> | > | to
> | > | > | the Lift class, then we potentially have a problem. This is allowed
> | > | today
> | > | > | (and it works well):
> | > | > |
> | > | > | > data Foo
> | > | > | >   deriving Data
> | > | > | > instance Lift Foo
> | > | > |
> | > | > | But after this proposal, it will still be accepted **but will
> | loop**.
> | > | That
> | > | > | is, the instance silently becomes a bomb waiting to maim poor
> | clients
> | > | with
> | > | > | an obscure compile-time hang. Because of the MINIMAL pragma, there
> | will
> | > | be
> | > | > | a warning. So perhaps we decide that the warning is enough of a
> | > | deterrent
> | > | > | and to allow this strange back-compat story.
> | > | > |
> | > | > | On the other hand, if we remove lift from the class, then the above
> | > | code
> | > | > | fails with a "liftTyped is not defined" error. That's quite easy to
> | > | > | pinpoint.
> | > | > |
> | > | > | I'm not wholly against this proposal at all -- indeed, it's a nice
> | > | > | application of levity polymorphism -- but I think there is a real
> | > | drawback
> | > | > | here worth debating.
> | > | > |
> | > | > | Richard
> | > | > |
> | > | > | > On Mar 4, 2019, at 10:19 PM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> | > | > | >
> | > | > | > I believe you're thinking of
> | > | > |
> | > |
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co>
> | > | > | m%2Fghc-proposals%2Fghc-
> | > | > |
> | > |
> | proposals%2Fpull%2F175&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C179fc89
> | > | > |
> | > |
> | 805fa4e1a3f6008d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6368
> | > | > |
> | > |
> | 73534124463833&amp;sdata=WUd8z511ysFVYxvhdpYCtw0useZOtOq37VANULn%2BHd8%3D&a
> | > | > | mp;reserved=0. The PR has been marked accepted, but it seems it
> | didn't
> | > | get
> | > | > | merged.
> | > | > | >
> | > | > | > On Mon, Mar 4, 2019, at 22:16, Richard Eisenberg wrote:
> | > | > | >> I recall a discussion in another proposal about the Lift class
> | and
> | > | > | >> removing the lift function. This was for a good reason (I think
> | it
> | > | > | >> stopped silent, terrible breakage). Does anyone remember where
> | that
> | > | > | >> conversation took place? A quick search didn't find an accepted
> | > | > | >> proposal about the Lift class.
> | > | > | >>
> | > | > | >> Thanks,
> | > | > | >> Richard
> | > | > | >>
> | > | > | >>> On Mar 2, 2019, at 4:41 PM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> | > | > | >>>
> | > | > | >>> Hi everyone,
> | > | > | >>>
> | > | > | >>> This proposal[1] makes the `lift` and `liftTyped` methods of
> | the
> | > | `Lift`
> | > | > | class levity-polymorphic, which allows us to write proper `Lift`
> | > | instances
> | > | > | for unlifted types. It would also allow GHC to remove the special
> | logic
> | > | > | that currently supports lifting records with unlifted fields.
> | > | > | >>>
> | > | > | >>> The main downside is the potential for breakage since `lift
> | @Foo`
> | > | would
> | > | > | now fix the RuntimeRep parameter rather than the `a`. This is
> | > | unfortunate,
> | > | > | but I doubt it will show up much. It also unfortunately requires
> | making
> | > | > | both `lift` and `liftTyped` methods, when we had just decided to
> | > | extract
> | > | > | `lift` from the class.
> | > | > | >>>
> | > | > | >>> I recommend accepting the proposal.
> | > | > | >>>
> | > | > | >>> Thanks!
> | > | > | >>> Eric
> | > | > | >>>
> | > | > | >>> [1]:
> | > | > |
> | > |
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co>
> | > | > | m%2Fharpocrates%2Fghc-proposals%2Fblob%2Flevity-polymorphic-
> | > | > | lift%2Fproposals%2F0000-levity-polymorphic-
> | > | > |
> | > |
> | lift.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C179fc89805fa4e1a3f600
> | > | > |
> | > |
> | 8d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636873534124463833
> | > | > |
> | > |
> | &amp;sdata=K9%2BIbsRdxplDnvRirFgrgzspyPjf3F1iZrRK5vE7q7c%3D&amp;reserved=0
> | > | > | >>> _______________________________________________
> | > | > | >>> ghc-steering-committee mailing list
> | > | > | >>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> | > | > | >>>
> | > | > |
> | > |
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask>
> | > | > | ell.org <http://ell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | > | > |
> | > |
> | committee&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C179fc89805fa4e1a3f60
> | > | > |
> | > |
> | 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
> | > | > |
> | > |
> | 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
> | > | > | >>
> | > | > | >>
> | > | > |
> | > | > | _______________________________________________
> | > | > | ghc-steering-committee mailing list
> | > | > | ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> | > | > |
> | > |
> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask>
> | > | > | ell.org <http://ell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> | > | > |
> | > |
> | committee&amp;data=02%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7C179fc89805fa4e1a3f60
> | > | > |
> | > |
> | 08d6a11adfa7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687353412446383
> | > | > |
> | > |
> | 3&amp;sdata=37JiqdFQvu35db6WyYz6Q60jEgNQULRvhByqDUN%2FPjI%3D&amp;reserved=0
> | >
> | >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> 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/20190305/bde6b114/attachment-0001.html>

From rae at cs.brynmawr.edu  Tue Mar  5 21:19:40 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 5 Mar 2019 16:19:40 -0500
Subject: [ghc-steering-committee] Discussion on #155 Type Variable	in
 Labmdas
In-Reply-To: <DB7PR83MB0298918C10588EB2476BC831AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <78A08A87-F650-4F37-B5CC-BA011C509D3D@cs.brynmawr.edu>
 <DB7PR83MB0298918C10588EB2476BC831AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <7E2BF2D8-372F-4A7F-8129-C6FFA21E4FBD@cs.brynmawr.edu>



> On Mar 5, 2019, at 11:34 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> I haven't thought through the consequences of this fully, but it does seem plausible.
>  
> It says we must generalise over some ‘a’, but which ‘a’?  What type does (\@a (\x. x)) have?

My understanding of Eric's idea is that GHC would give (\x.x) the type (alpha -> alpha), as usual. Then (\ @a (\x.x)) gets the type forall a. alpha -> alpha. Later, we might solve for alpha or generalize over it, perhaps leading a type like forall b a. b -> b.

> But someone would need to write down a type system.

I agree here. I think we'd need more Medium Thought (not quite Hard Thought) before committing to this plan, but it still seems plausible.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190305/79494277/attachment.html>

From eric at seidel.io  Tue Mar  5 21:55:13 2019
From: eric at seidel.io (Eric Seidel)
Date: Tue, 05 Mar 2019 16:55:13 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Discussion_on_=23155_Type_Vari?=
 =?utf-8?q?able=09in_Labmdas?=
In-Reply-To: <7E2BF2D8-372F-4A7F-8129-C6FFA21E4FBD@cs.brynmawr.edu>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <78A08A87-F650-4F37-B5CC-BA011C509D3D@cs.brynmawr.edu>
 <DB7PR83MB0298918C10588EB2476BC831AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7E2BF2D8-372F-4A7F-8129-C6FFA21E4FBD@cs.brynmawr.edu>
Message-ID: <c514cdaa-c524-4603-9454-40dc991d2974@www.fastmail.com>

On Tue, Mar 5, 2019, at 16:19, Richard Eisenberg wrote:
> 
> 
> > On Mar 5, 2019, at 11:34 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > 
> > I haven't thought through the consequences of this fully, but it does seem plausible.
> > It says we must generalise over some ‘a’, but *which* ‘a’? What type does (\@a (\x. x)) have? 
> 
> My understanding of Eric's idea is that GHC would give (\x.x) the type 
> (alpha -> alpha), as usual. Then (\ @a (\x.x)) gets the type forall a. 
> alpha -> alpha. Later, we might solve for alpha or generalize over it, 
> perhaps leading a type like forall b a. b -> b.

Yep, that's precisely what I would expect.

It doesn't need to happen for this proposal, but it would make a very nice addition assuming the theory works out.

From mail at joachim-breitner.de  Thu Mar  7 09:38:58 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 07 Mar 2019 10:38:58 +0100
Subject: [ghc-steering-committee] Please review #207: type variables in
	quotations, Shepherd: Richard
Message-ID: <aa7901129feebbbf7dfb8df5e68507cf6849bd91.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

type variables in quotations
has been proposed by Richard Eisenberg
https://github.com/ghc-proposals/ghc-proposals/pull/207
https://github.com/mpickering/ghc-proposals/blob/csp-types/proposals/0000-csp-types.rst

I propose Richard as the Shepherd.

Please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process
I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190307/b174c725/attachment.sig>

From mail at joachim-breitner.de  Thu Mar  7 09:40:37 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 07 Mar 2019 10:40:37 +0100
Subject: [ghc-steering-committee] Please review #204: nested brackets,
	Shepherd: Iavor
Message-ID: <99ce97ece8cccbaca101d834a9411ef3bef776c4.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Remove nested bracket restriction in Template Haskell  
has been proposed by Matthew Pickering
https://github.com/ghc-proposals/ghc-proposals/pull/204
https://github.com/ghc-proposals/ghc-proposals/blob/a5fca22bd396647c5b5efb98f75a4d215d65f4da/proposals/0000-nested-brackets.rst

I propose Iavor as the shepherd.

Please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process
I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190307/b7089eba/attachment.sig>

From mail at joachim-breitner.de  Thu Mar  7 09:42:06 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 07 Mar 2019 10:42:06 +0100
Subject: [ghc-steering-committee] Please review #195: newtype Q (TExp a),
	Shepherd: Vitaly
Message-ID: <b0b83437db7688461923ffb7bf10f9ca1c37a16b.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Make Q (TExp a) into a newtype
has been proposed by Matthew Pickering
https://github.com/ghc-proposals/ghc-proposals/pull/195
https://github.com/ghc-proposals/ghc-proposals/blob/22e97d7693edb0b3676c948a123e57ea93c462e3/proposals/0000-code-texp.rst

I propose Vitaly as the shepherd.

Please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process
I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190307/5bc98676/attachment.sig>

From rae at cs.brynmawr.edu  Thu Mar  7 15:21:27 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 7 Mar 2019 10:21:27 -0500
Subject: [ghc-steering-committee] #207: Type variables in TH quotes
	(recommendation: reject)
Message-ID: <597EFB29-EFF6-4150-AEF3-920096A5BB47@cs.brynmawr.edu>

Hi committee,

Matthew Pickering has proposed #207: Fix the treatment of type variables in quotations. (In contrast to the email from our Most Honored and Appreciated Secretary: Matt wrote the proposal, not me.)

PR: https://github.com/ghc-proposals/ghc-proposals/pull/207 <https://github.com/ghc-proposals/ghc-proposals/pull/207>
Proposal: https://github.com/mpickering/ghc-proposals/blob/csp-types/proposals/0000-csp-types.rst <https://github.com/mpickering/ghc-proposals/blob/csp-types/proposals/0000-csp-types.rst>

The proposal considers code like this:

foo :: forall a. Proxy a -> Q Exp
foo _ = [| let x :: a -> a; ... |]

Note that the type variable `a` is in scope in the quotation. Currently, this quotation is accepted, but then any use of it in a splice leads to an error, because the `a` has a Unique of a variable that has fallen out of scope. This is just plain wrong.

Matt proposes to fix this by introducing a new class LiftT, with one method: liftTyCl :: forall {k} (a :: k). LiftT a => Q Type. This is a type-level equivalent of the existing Lift class, whose `lift` method produces a Q Exp. Instances of LiftT would be automatically provided by GHC at all types, including polytypes. Matt has already implemented the proposal.

I recommend against accepting this proposal in its current form, for the following reasons:
 - While the proposal addresses a specific, real bug in TH, this is far from the simplest solution. Instead, we could just state that no variables brought into scope outside a TH quote remain in scope within the TH quote. The body of `foo` above would be rejected for this reason.
 - There is no motivation for the new feature in the proposal, other than fixing the bug.
 - The example in the proposal is one that, even with this proposal implemented, would not work: it uses *typed* TH, which does not allow type-level splices. So, even if Matt has a genuine need for this feature leading to the example in the proposal, implementing the proposal doesn't actually solve his problem.
 - The proposal mentions the possibility of using Typeable instead of LiftT, but discards this idea because we cannot solve, e.g., Typeable (forall a. a -> a); in contrast, we can solve LiftT instances of that form. However, generating a need for a LiftT instance of that form requires -XImpredicativeTypes, which is a bug, not a feature.
 - Although Matt has kindly already implemented this feature, we all know that the initial implementation of a feature is only the tip of the iceberg in its cost. Adding this feature, as proposed, introduces yet another class that we have to have custom treatment for, along with various other points of complexity.

Perhaps with proper motivation -- and with an implementation based on Typeable -- I would be more in support. I do think this may be useful. But given the fact that the TH bug has existed since the dawn of time and no one has complained until now -- and even now, there is no practical, on the ground motivation -- I'm uninclined to move forward here.

As usual, I will take silence as agreement with this recommendation to reject, but I'd love to hear opposing viewpoints.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190307/fda70eca/attachment.html>

From eric at seidel.io  Fri Mar  8 03:27:07 2019
From: eric at seidel.io (Eric Seidel)
Date: Thu, 07 Mar 2019 22:27:07 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=23209=3A_Levity_poly?=
 =?utf-8?q?morphic_lift=2E_Recommendation=3A_accept?=
In-Reply-To: <C0491A7D-5451-4E19-B270-A97659AE0074@cs.brynmawr.edu>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
 <DB7PR83MB029819400A9669497730E074AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7d0c15f7-06ec-4a0a-bbb8-faa1907f661d@www.fastmail.com>
 <DB7PR83MB0298EE7DFE19DEB0961B343BAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAGK9nupp7A5nJ=q3arxCCUSTQgMM+W33XcpSGgtSzso93VDO=Q@mail.gmail.com>
 <C0491A7D-5451-4E19-B270-A97659AE0074@cs.brynmawr.edu>
Message-ID: <bff01274-4e9b-4c34-bd39-680cb9053916@www.fastmail.com>

On Tue, Mar 5, 2019, at 16:15, Richard Eisenberg wrote:
> 
> Is it possible to write liftTyped in a generic way, like the way the 
> old lift had a generic default? That might solve all the problems at 
> once.

The old lift's default is

  default lift :: Data t => t -> Q Exp
  lift = liftData

I imagine we could get away with

  default liftTyped :: (r ~ 'LiftedRep, Data t) => t -> Q (TExp t)
  liftTyped = unsafeTExpCoerce . liftData

which would be no less unsafe than what is currently proposed as the default implementation. In which case, we could give both lift and liftTyped generic defaults, which would provide a seamless migration for code with and empty Lift instance.

Ah, but unfortunately this fails to typecheck with the following error.

    • Expected a type, but ‘t’ has kind ‘TYPE r’
    • In the first argument of ‘Data’, namely ‘t’
      In the type signature:
        liftTyped :: forall r (t :: TYPE r).
                     (r ~  'LiftedRep, Data t) => t -> Q (TExp t)

I'm a bit perplexed by this error actually. GHC rightly wants `t` to be a proper type, ie `TYPE LiftedRep`. Instead we have that `t` is a `TYPE r` where `r ~ LiftedRep`. Is there a technical reason GHC can't deduce that `t :: Type` here?


From bravit111 at gmail.com  Fri Mar  8 05:24:58 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Fri, 8 Mar 2019 08:24:58 +0300
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
Message-ID: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>

Hi everyone,

I was asked to shepherd the proposal #167 (Deprecated Entities,
https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst).
It is proposed to extend (nonpositional) DEPRECATED pragma with the two
specifiers to disambiguate deprecating named type-level and value-level
things. In its current formulation, the proposal suggests to use the
specifiers "type" for type-level things and "pattern" for value-level
things as follows:

data Bar = Bar
{-# DEPRECATED type Bar "Don't use type Bar" #-}
data Baz = Baz
{-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}

Using this pragma without specifiers should mean deprecating both (as is
works now).

After discussing this proposal within the committee (see
https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html),
I recommend acceptance with one change, namely using "data" instead of
"pattern" for deprecating value-level things.

Reasons for choosing "data":
* it's a reserved keyword (as opposed to "value", which is another option)
* we are deprecating data constructors here
* it just feels right (sorry!)

Reasons against "data":
* it can be confusing whether we mean data type or data constructor
* we use "value" and "pattern" in other places meaning basically the same
thing

If the committee decides to go this way, then the wider community may think
about other proposals, such as
* adding positional DEPRECATED pragmas (including class instances
deprecation)
* fixing inconsistencies with the fixity declarations (
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst)
and updating ExplicitNamespaces in import/export lists
* deprecating usage of nonpositional DEPRECATED pragma without the
specifiers

Silence is understood as agreement.

Regards,
Vitaly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/888afa09/attachment.html>

From bravit111 at gmail.com  Fri Mar  8 06:40:47 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Fri, 8 Mar 2019 09:40:47 +0300
Subject: [ghc-steering-committee] #195: Make Q (TExp a) into a newtype,
	rec: accept
Message-ID: <CALpVSmPNrEPDKJm3xbtAMyhgUbyfKLUvTHqPgWAjcfgzOT-N0g@mail.gmail.com>

Hi everyone,

Matthew Pickering proposed to make Q (TExp a) into a newtype called Code.
Proposal #195:
https://github.com/ghc-proposals/ghc-proposals/blob/22e97d7693edb0b3676c948a123e57ea93c462e3/proposals/0000-code-texp.rst
Pull request discussion:
https://github.com/ghc-proposals/ghc-proposals/pull/195

It looks like the motivation behind this proposal boils down to the
convenience of writing instances which seems a good thing. The minor
problem I see is the proposed name "Code" as it looks a little bit too
abstract for Typed Template Haskell expressions. Nevertheless, I recommend
to accept the proposal as it is. Silence is understood as agreement.

Regards,
Vitaly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/6a03753b/attachment.html>

From marlowsd at gmail.com  Fri Mar  8 07:57:12 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 8 Mar 2019 07:57:12 +0000
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
Message-ID: <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>

Yes, I think this is the right way to go.

Cheers
Simon

On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:

> Hi everyone,
>
> I was asked to shepherd the proposal #167 (Deprecated Entities,
> https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst).
> It is proposed to extend (nonpositional) DEPRECATED pragma with the two
> specifiers to disambiguate deprecating named type-level and value-level
> things. In its current formulation, the proposal suggests to use the
> specifiers "type" for type-level things and "pattern" for value-level
> things as follows:
>
> data Bar = Bar
> {-# DEPRECATED type Bar "Don't use type Bar" #-}
> data Baz = Baz
> {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
>
> Using this pragma without specifiers should mean deprecating both (as is
> works now).
>
> After discussing this proposal within the committee (see
> https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html),
> I recommend acceptance with one change, namely using "data" instead of
> "pattern" for deprecating value-level things.
>
> Reasons for choosing "data":
> * it's a reserved keyword (as opposed to "value", which is another option)
> * we are deprecating data constructors here
> * it just feels right (sorry!)
>
> Reasons against "data":
> * it can be confusing whether we mean data type or data constructor
> * we use "value" and "pattern" in other places meaning basically the same
> thing
>
> If the committee decides to go this way, then the wider community may
> think about other proposals, such as
> * adding positional DEPRECATED pragmas (including class instances
> deprecation)
> * fixing inconsistencies with the fixity declarations (
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst)
> and updating ExplicitNamespaces in import/export lists
> * deprecating usage of nonpositional DEPRECATED pragma without the
> specifiers
>
> Silence is understood as agreement.
>
> Regards,
> Vitaly
>
>
> _______________________________________________
> 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/20190308/5c0bd69d/attachment-0001.html>

From marlowsd at gmail.com  Fri Mar  8 08:31:51 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 8 Mar 2019 08:31:51 +0000
Subject: [ghc-steering-committee] #190: Module qualified syntax,
	recommendation: accept
In-Reply-To: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
Message-ID: <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>

Proposal #190 is about accepting the syntax

  import A.B.C qualified

instead of (or in addition to) the existing syntax

  import qualified A.B.C

I think it's widely accepted that the original syntax was a mistake. I
don't need to rehash the rationale for the change here, iit's described
pretty well in the proposal and elaborated in the discussion.

The question for us is really: is it worth changing? There are costs:
- A new extension flag, which itself has costs (extra documentation, a new
thing that people need to understand)
- new code using the extension doesn't compile with older compilers
- all the existing code in the world uses the old convention
- etc.

Reasonable people can differ here. The discussion on the proposal has
representatives from both sides of the camp.

Personally, the current syntax annoys me almost every day. It's already a
small cost on everyone, and I think we need to move forwards even if there
are costs in migrating. So, I'm going to recommend that we accept this
proposal.

We might want to reconsider the name of the extension:
QualifiedImportsPostpositive
seems like a mouthful. Perhaps ImportQualifiedPost is enough?

Cheers
Simon

On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Module qualified syntax
> has been proposed by Shayne Fletcher
> https://github.com/ghc-proposals/ghc-proposals/pull/190
>
> https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst
>
> Simon Marlow has already volunteered to shepherd.
>
> Please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> I suggest you make a recommendation, in a new e-mail thread with the
> proposal number in the subject, about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
>
> Thanks,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20190308/d6845aca/attachment.html>

From simonpj at microsoft.com  Fri Mar  8 08:42:55 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 8 Mar 2019 08:42:55 +0000
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
Message-ID: <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>

I’ve made a post on the proposal thread asking why we don’t just follow the already-adopted proposal for WARNING and infix pragmas.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 08 March 2019 07:57
To: Vitaly Bragilevsky <bravit111 at gmail.com>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept

Yes, I think this is the right way to go.

Cheers
Simon

On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com<mailto:bravit111 at gmail.com>> wrote:
Hi everyone,

I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnineonine%2Fghc-proposals%2Fblob%2Fdepr-entities%2Fproposals%2F0000-deprecated-entities.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630814000&sdata=sJ3QiAx6Z55hJvsYajJEKfx6M8IVZ2DEY4LRRiaBTI8%3D&reserved=0>). It is proposed to extend (nonpositional) DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. In its current formulation, the proposal suggests to use the specifiers "type" for type-level things and "pattern" for value-level things as follows:

data Bar = Bar
{-# DEPRECATED type Bar "Don't use type Bar" #-}
data Baz = Baz
{-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}

Using this pragma without specifiers should mean deprecating both (as is works now).

After discussing this proposal within the committee (see https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-February%2F000894.html&data=02%7C01%7Csimonpj%40microsoft.com%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630824013&sdata=DEu9cf6sX2xf%2BxegCrh1TikJT%2B3yWB3BgA1k9CmCLs4%3D&reserved=0>), I recommend acceptance with one change, namely using "data" instead of "pattern" for deprecating value-level things.

Reasons for choosing "data":
* it's a reserved keyword (as opposed to "value", which is another option)
* we are deprecating data constructors here
* it just feels right (sorry!)

Reasons against "data":
* it can be confusing whether we mean data type or data constructor
* we use "value" and "pattern" in other places meaning basically the same thing

If the committee decides to go this way, then the wider community may think about other proposals, such as
* adding positional DEPRECATED pragmas (including class instances deprecation)
* fixing inconsistencies with the fixity declarations (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0008-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630834021&sdata=IrpWyWLVksadQK5bo%2B7d%2B10LWuztYUcFwkAUsZxA5cg%3D&reserved=0>) and updating ExplicitNamespaces in import/export lists
* deprecating usage of nonpositional DEPRECATED pragma without the specifiers

Silence is understood as agreement.

Regards,
Vitaly

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630834021&sdata=BfV5VDwcmFI210G0Aq5uZFmsC8Pc5fQdkB%2F8Hi5mtmI%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/8f5edc93/attachment-0001.html>

From chak at justtesting.org  Fri Mar  8 08:44:36 2019
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Fri, 8 Mar 2019 09:44:36 +0100
Subject: [ghc-steering-committee] #190: Module qualified syntax,
 recommendation: accept
In-Reply-To: <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
Message-ID: <E64424EF-2503-4DEA-8FA7-A1FA3DCF4FC6@justtesting.org>

First of all, I totally agree that the proposed syntax is better.

However, TBH, I don’t think it is a particularly good idea to change syntactic warts by way of a language extension. If we were discussing actually changing the language definition, that would be a different matter. But we are not. We just add an alternative and potentially cause confusion.

Hence, I think, this is a bad idea.

Cheers,
Manuel


> Am 08.03.2019 um 09:31 schrieb Simon Marlow <marlowsd at gmail.com>:
> 
> Proposal #190 is about accepting the syntax
> 
>   import A.B.C qualified
> 
> instead of (or in addition to) the existing syntax
> 
>   import qualified A.B.C
> 
> I think it's widely accepted that the original syntax was a mistake. I don't need to rehash the rationale for the change here, iit's described pretty well in the proposal and elaborated in the discussion.
> 
> The question for us is really: is it worth changing? There are costs:
> - A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand)
> - new code using the extension doesn't compile with older compilers
> - all the existing code in the world uses the old convention
> - etc.
> 
> Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.
> 
> Personally, the current syntax annoys me almost every day. It's already a small cost on everyone, and I think we need to move forwards even if there are costs in migrating. So, I'm going to recommend that we accept this proposal.
> 
> We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?
> 
> Cheers
> Simon
> 
> On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Module qualified syntax
> has been proposed by Shayne Fletcher
> https://github.com/ghc-proposals/ghc-proposals/pull/190 <https://github.com/ghc-proposals/ghc-proposals/pull/190>
> https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst <https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst>
> 
> Simon Marlow has already volunteered to shepherd.
> 
> Please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> I suggest you make a recommendation, in a new e-mail thread with the
> proposal number in the subject, about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
> 
> Thanks,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> 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/20190308/4a820643/attachment.html>

From simonpj at microsoft.com  Fri Mar  8 08:51:37 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 8 Mar 2019 08:51:37 +0000
Subject: [ghc-steering-committee] #195: Make Q (TExp a) into a newtype,
	rec: accept
In-Reply-To: <CALpVSmPNrEPDKJm3xbtAMyhgUbyfKLUvTHqPgWAjcfgzOT-N0g@mail.gmail.com>
References: <CALpVSmPNrEPDKJm3xbtAMyhgUbyfKLUvTHqPgWAjcfgzOT-N0g@mail.gmail.com>
Message-ID: <AM0PR83MB028936B9C4DF562AF458C8E9AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>

Yes, I agree.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Vitaly Bragilevsky
Sent: 08 March 2019 06:41
To: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: [ghc-steering-committee] #195: Make Q (TExp a) into a newtype, rec: accept

Hi everyone,

Matthew Pickering proposed to make Q (TExp a) into a newtype called Code.
Proposal #195: https://github.com/ghc-proposals/ghc-proposals/blob/22e97d7693edb0b3676c948a123e57ea93c462e3/proposals/0000-code-texp.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2F22e97d7693edb0b3676c948a123e57ea93c462e3%2Fproposals%2F0000-code-texp.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C283dee8b70474ae9761308d6a3910fb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876240764020521&sdata=Cq32fdykV9oonakOOFbAnV7LulmupHXHq0p2c9raKFs%3D&reserved=0>
Pull request discussion: https://github.com/ghc-proposals/ghc-proposals/pull/195<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F195&data=02%7C01%7Csimonpj%40microsoft.com%7C283dee8b70474ae9761308d6a3910fb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876240764030529&sdata=6CqagCiMbgVgSgmWeLTcDbauGsB111fn7DOyuMiXemI%3D&reserved=0>

It looks like the motivation behind this proposal boils down to the convenience of writing instances which seems a good thing. The minor problem I see is the proposed name "Code" as it looks a little bit too abstract for Typed Template Haskell expressions. Nevertheless, I recommend to accept the proposal as it is. Silence is understood as agreement.

Regards,
Vitaly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/d3fd5f0d/attachment.html>

From simonpj at microsoft.com  Fri Mar  8 08:55:59 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 8 Mar 2019 08:55:59 +0000
Subject: [ghc-steering-committee] #190: Module qualified syntax,
	recommendation: accept
In-Reply-To: <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
Message-ID: <AM0PR83MB028917B1EED79F22B6D8B0E4AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>

I agree.  It’s a tiny, superficial thing, but it’s clearly egregiously annoying to some pretty experience users, who use Haskell at scale.  So yes, we should do this.

My only question is: do we really need a  flag.  Suppose we simply accepted the postfix “qualified” with no flag support.  Then a program will be accepted that earlier compilers would have rejected – and, absent a flag, we normally try to continue to reject programs that weren’t legal before.  But in this case no one is going to fall into this by mistake.  I suggest we consider simply allowing it as an exception to our general rule, and move on.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 08 March 2019 08:32
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] #190: Module qualified syntax, recommendation: accept

Proposal #190 is about accepting the syntax

  import A.B.C qualified

instead of (or in addition to) the existing syntax

  import qualified A.B.C

I think it's widely accepted that the original syntax was a mistake. I don't need to rehash the rationale for the change here, iit's described pretty well in the proposal and elaborated in the discussion.

The question for us is really: is it worth changing? There are costs:
- A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand)
- new code using the extension doesn't compile with older compilers
- all the existing code in the world uses the old convention
- etc.

Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.

Personally, the current syntax annoys me almost every day. It's already a small cost on everyone, and I think we need to move forwards even if there are costs in migrating. So, I'm going to recommend that we accept this proposal.

We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?

Cheers
Simon

On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

Module qualified syntax
has been proposed by Shayne Fletcher
https://github.com/ghc-proposals/ghc-proposals/pull/190<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F190&data=02%7C01%7Csimonpj%40microsoft.com%7Caf28d349cc4b4dcc2c9708d6a3a09262%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876307377122036&sdata=j2ADKb66m6dLG4JNJD4t37U5jF3Kooh4nWLYx0BPU9I%3D&reserved=0>
https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Fmodule-qualified-syntax%2Fproposals%2F0000-module-qualified-syntax.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Caf28d349cc4b4dcc2c9708d6a3a09262%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876307377132029&sdata=bRsO6Tt9pqe3peTWlWm5fkIvLX35fCOCwJpY6WyTQ1o%3D&reserved=0>

Simon Marlow has already volunteered to shepherd.

Please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Caf28d349cc4b4dcc2c9708d6a3a09262%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876307377132029&sdata=Fl4isHNP4fJq%2FRvdhofK8HJeTEJ6jCsEIgtTH0uZdFs%3D&reserved=0>
I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Caf28d349cc4b4dcc2c9708d6a3a09262%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876307377142023&sdata=haZTJI6ivDUviYGAUO7vISNU%2F9wNhfK%2FuZxII01dE5k%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Caf28d349cc4b4dcc2c9708d6a3a09262%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876307377142023&sdata=4rv%2F4hdx6XOhgDYezaDp2Ev45zlqO6gkZP%2Bz%2FQ3vaM4%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/2f87dc37/attachment-0001.html>

From mail at joachim-breitner.de  Fri Mar  8 09:29:40 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 08 Mar 2019 10:29:40 +0100
Subject: [ghc-steering-committee] #190: Module qualified syntax,
 recommendation: accept
In-Reply-To: <AM0PR83MB028917B1EED79F22B6D8B0E4AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <AM0PR83MB028917B1EED79F22B6D8B0E4AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <7a7b9ec3a38c1c0a9cff2172aebd118654027335.camel@joachim-breitner.de>

Hello,

Am Freitag, den 08.03.2019, 08:55 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> I agree.  It’s a tiny, superficial thing, but it’s clearly
> egregiously annoying to some pretty experience users, who use Haskell
> at scale.  So yes, we should do this.

It never bothered me, and I would have leaned towards “not worth the
bother”, but I am swayed by strong support from Neil and Simon², so I
am fine with accepting this.

> My only question is: do we really need a  flag.  Suppose we simply
> accepted the postfix “qualified” with no flag support.  Then a
> program will be accepted that earlier compilers would have rejected –
> and, absent a flag, we normally try to continue to reject programs
> that weren’t legal before.  But in this case no one is going to fall
> into this by mistake.  I suggest we consider simply allowing it as an
> exception to our general rule, and move on.

Let’s not do this. We have very few hard guidelines to help us in our
work; “changes to the language needs a flag” is one of them. If we
start to be lax here, we will have to justify every future flag where
the extension would just be an invalid program otherwise, including
things like LambdaCase etc.

It is tempting, but the slope is too slippery.

Most of our users (in particular the “experienced users” mentioned
above) are used to managing a long list of flags, adding another will
not hurt them to manage another one.

And if this management becomes too long, then instead of making
exceptions, we should either hope for Haskell20xx to liberally include
these “convenience extensions”, or otherwise make the management of the
extension list easier (e.g. maybe by picking up  
https://github.com/ghc-proposals/ghc-proposals/pull/92 again).



As for a shorter name, now about QualifiedLast?


Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/5083e7fc/attachment.sig>

From simonpj at microsoft.com  Fri Mar  8 09:56:45 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 8 Mar 2019 09:56:45 +0000
Subject: [ghc-steering-committee] #207: Type variables in TH
	quotes	(recommendation: reject)
In-Reply-To: <597EFB29-EFF6-4150-AEF3-920096A5BB47@cs.brynmawr.edu>
References: <597EFB29-EFF6-4150-AEF3-920096A5BB47@cs.brynmawr.edu>
Message-ID: <AM0PR83MB0289761200029510A4CF37C8AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>

I'm afraid I agree here.  We need a much more compelling motivation before adopting all this extra stuff.  Moreover, absent compelling use-cases it's all too easy to implement something that, when the use-cases arrive, turns out to be not quite right.  Best to inform the design directly from a collection of motivating uses.

There's a simple bug-fix for now: just reject the program.  If we get lots of people yelling that they really want such programs, we can tackle it then.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 07 March 2019 15:21
To: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: [ghc-steering-committee] #207: Type variables in TH quotes (recommendation: reject)

Hi committee,

Matthew Pickering has proposed #207: Fix the treatment of type variables in quotations. (In contrast to the email from our Most Honored and Appreciated Secretary: Matt wrote the proposal, not me.)

PR: https://github.com/ghc-proposals/ghc-proposals/pull/207<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F207&data=02%7C01%7Csimonpj%40microsoft.com%7Cc8827273f9e44622cb0408d6a3109b10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875689049631261&sdata=AXbw0Qv0srD4CbUt2HE8AR%2FxOfO%2Fpk7YFa61x384Bmw%3D&reserved=0>
Proposal: https://github.com/mpickering/ghc-proposals/blob/csp-types/proposals/0000-csp-types.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmpickering%2Fghc-proposals%2Fblob%2Fcsp-types%2Fproposals%2F0000-csp-types.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc8827273f9e44622cb0408d6a3109b10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875689049641265&sdata=e95B6Dsf0jhEy8IU%2BWCNfjQG8yT8S3KE5eqfCfL9GfE%3D&reserved=0>

The proposal considers code like this:

foo :: forall a. Proxy a -> Q Exp
foo _ = [| let x :: a -> a; ... |]

Note that the type variable `a` is in scope in the quotation. Currently, this quotation is accepted, but then any use of it in a splice leads to an error, because the `a` has a Unique of a variable that has fallen out of scope. This is just plain wrong.

Matt proposes to fix this by introducing a new class LiftT, with one method: liftTyCl :: forall {k} (a :: k). LiftT a => Q Type. This is a type-level equivalent of the existing Lift class, whose `lift` method produces a Q Exp. Instances of LiftT would be automatically provided by GHC at all types, including polytypes. Matt has already implemented the proposal.

I recommend against accepting this proposal in its current form, for the following reasons:
 - While the proposal addresses a specific, real bug in TH, this is far from the simplest solution. Instead, we could just state that no variables brought into scope outside a TH quote remain in scope within the TH quote. The body of `foo` above would be rejected for this reason.
 - There is no motivation for the new feature in the proposal, other than fixing the bug.
 - The example in the proposal is one that, even with this proposal implemented, would not work: it uses *typed* TH, which does not allow type-level splices. So, even if Matt has a genuine need for this feature leading to the example in the proposal, implementing the proposal doesn't actually solve his problem.
 - The proposal mentions the possibility of using Typeable instead of LiftT, but discards this idea because we cannot solve, e.g., Typeable (forall a. a -> a); in contrast, we can solve LiftT instances of that form. However, generating a need for a LiftT instance of that form requires -XImpredicativeTypes, which is a bug, not a feature.
 - Although Matt has kindly already implemented this feature, we all know that the initial implementation of a feature is only the tip of the iceberg in its cost. Adding this feature, as proposed, introduces yet another class that we have to have custom treatment for, along with various other points of complexity.

Perhaps with proper motivation -- and with an implementation based on Typeable -- I would be more in support. I do think this may be useful. But given the fact that the TH bug has existed since the dawn of time and no one has complained until now -- and even now, there is no practical, on the ground motivation -- I'm uninclined to move forward here.

As usual, I will take silence as agreement with this recommendation to reject, but I'd love to hear opposing viewpoints.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/db7dc2b7/attachment.html>

From chak at justtesting.org  Fri Mar  8 10:14:24 2019
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Fri, 8 Mar 2019 11:14:24 +0100
Subject: [ghc-steering-committee] #207: Type variables in TH	quotes
 (recommendation: reject)
In-Reply-To: <AM0PR83MB0289761200029510A4CF37C8AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <597EFB29-EFF6-4150-AEF3-920096A5BB47@cs.brynmawr.edu>
 <AM0PR83MB0289761200029510A4CF37C8AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <7F193E16-0CB9-40DA-A5FD-A641ECB0D767@justtesting.org>

> Am 08.03.2019 um 10:56 schrieb Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>:
> 
> There’s a simple bug-fix for now: just reject the program.  If we get lots of people yelling that they really want such programs, we can tackle it then.

Sounds like the right approach to me, too.

Manuel

>  
> Simon
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
> Sent: 07 March 2019 15:21
> To: ghc-steering-committee <ghc-steering-committee at haskell.org>
> Subject: [ghc-steering-committee] #207: Type variables in TH quotes (recommendation: reject)
>  
> Hi committee,
>  
> Matthew Pickering has proposed #207: Fix the treatment of type variables in quotations. (In contrast to the email from our Most Honored and Appreciated Secretary: Matt wrote the proposal, not me.)
>  
> PR: https://github.com/ghc-proposals/ghc-proposals/pull/207 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F207&data=02%7C01%7Csimonpj%40microsoft.com%7Cc8827273f9e44622cb0408d6a3109b10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875689049631261&sdata=AXbw0Qv0srD4CbUt2HE8AR%2FxOfO%2Fpk7YFa61x384Bmw%3D&reserved=0>
> Proposal: https://github.com/mpickering/ghc-proposals/blob/csp-types/proposals/0000-csp-types.rst <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmpickering%2Fghc-proposals%2Fblob%2Fcsp-types%2Fproposals%2F0000-csp-types.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc8827273f9e44622cb0408d6a3109b10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875689049641265&sdata=e95B6Dsf0jhEy8IU%2BWCNfjQG8yT8S3KE5eqfCfL9GfE%3D&reserved=0>
>  
> The proposal considers code like this:
>  
> foo :: forall a. Proxy a -> Q Exp
> foo _ = [| let x :: a -> a; ... |]
>  
> Note that the type variable `a` is in scope in the quotation. Currently, this quotation is accepted, but then any use of it in a splice leads to an error, because the `a` has a Unique of a variable that has fallen out of scope. This is just plain wrong.
>  
> Matt proposes to fix this by introducing a new class LiftT, with one method: liftTyCl :: forall {k} (a :: k). LiftT a => Q Type. This is a type-level equivalent of the existing Lift class, whose `lift` method produces a Q Exp. Instances of LiftT would be automatically provided by GHC at all types, including polytypes. Matt has already implemented the proposal.
>  
> I recommend against accepting this proposal in its current form, for the following reasons:
>  - While the proposal addresses a specific, real bug in TH, this is far from the simplest solution. Instead, we could just state that no variables brought into scope outside a TH quote remain in scope within the TH quote. The body of `foo` above would be rejected for this reason.
>  - There is no motivation for the new feature in the proposal, other than fixing the bug.
>  - The example in the proposal is one that, even with this proposal implemented, would not work: it uses *typed* TH, which does not allow type-level splices. So, even if Matt has a genuine need for this feature leading to the example in the proposal, implementing the proposal doesn't actually solve his problem.
>  - The proposal mentions the possibility of using Typeable instead of LiftT, but discards this idea because we cannot solve, e.g., Typeable (forall a. a -> a); in contrast, we can solve LiftT instances of that form. However, generating a need for a LiftT instance of that form requires -XImpredicativeTypes, which is a bug, not a feature.
>  - Although Matt has kindly already implemented this feature, we all know that the initial implementation of a feature is only the tip of the iceberg in its cost. Adding this feature, as proposed, introduces yet another class that we have to have custom treatment for, along with various other points of complexity.
>  
> Perhaps with proper motivation -- and with an implementation based on Typeable -- I would be more in support. I do think this may be useful. But given the fact that the TH bug has existed since the dawn of time and no one has complained until now -- and even now, there is no practical, on the ground motivation -- I'm uninclined to move forward here.
>  
> As usual, I will take silence as agreement with this recommendation to reject, but I'd love to hear opposing viewpoints.
>  
> Thanks,
> Richard
> _______________________________________________
> 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/20190308/20beb134/attachment-0001.html>

From eric at seidel.io  Fri Mar  8 13:50:33 2019
From: eric at seidel.io (Eric Seidel)
Date: Fri, 08 Mar 2019 08:50:33 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?=23190=3A_Module_qualified_syn?=
 =?utf-8?q?tax=2C_recommendation=3A_accept?=
In-Reply-To: <7a7b9ec3a38c1c0a9cff2172aebd118654027335.camel@joachim-breitner.de>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <AM0PR83MB028917B1EED79F22B6D8B0E4AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <7a7b9ec3a38c1c0a9cff2172aebd118654027335.camel@joachim-breitner.de>
Message-ID: <dd3bd1f3-0b87-44e1-978e-18462f1f7ad5@www.fastmail.com>

On Fri, Mar 8, 2019, at 04:29, Joachim Breitner wrote:
> And if this management becomes too long, then instead of making
> exceptions, we should either hope for Haskell20xx to liberally include
> these “convenience extensions”, or otherwise make the management of the
> extension list easier (e.g. maybe by picking up 
> https://github.com/ghc-proposals/ghc-proposals/pull/92 again).

I was going to argue alongside Simon in favor of just accepting the new syntax, when I remembered that emacs (with intero at least) can automatically insert necessary LANGUAGE pragmas, provided that GHC suggests them in its error message. This makes dealing with language extensions so much easier.

So I think I'd be ok with a new extension, small as it as, so long as we ensure that GHC suggests enabling it in its error messages!

From bravit111 at gmail.com  Fri Mar  8 14:29:41 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Fri, 8 Mar 2019 17:29:41 +0300
Subject: [ghc-steering-committee] #190: Module qualified syntax,
 recommendation: accept
In-Reply-To: <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
Message-ID: <CALpVSmP+s2L0cWZ6WqJnoX-v7xmn8ofit3ekawMPacAjnJdp9w@mail.gmail.com>

Hello,

I am in favor of this proposal. As for the name of the extension, my
suggestion is 'FlexibleImports', then we could allow even more flexibility
in import declarations in the future. Anyway, I am also ok with the current
versions (although the shorter the better).

Regards,
Vitaly

On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow <marlowsd at gmail.com> wrote:

> Proposal #190 is about accepting the syntax
>
>   import A.B.C qualified
>
> instead of (or in addition to) the existing syntax
>
>   import qualified A.B.C
>
> I think it's widely accepted that the original syntax was a mistake. I
> don't need to rehash the rationale for the change here, iit's described
> pretty well in the proposal and elaborated in the discussion.
>
> The question for us is really: is it worth changing? There are costs:
> - A new extension flag, which itself has costs (extra documentation, a new
> thing that people need to understand)
> - new code using the extension doesn't compile with older compilers
> - all the existing code in the world uses the old convention
> - etc.
>
> Reasonable people can differ here. The discussion on the proposal has
> representatives from both sides of the camp.
>
> Personally, the current syntax annoys me almost every day. It's already a
> small cost on everyone, and I think we need to move forwards even if there
> are costs in migrating. So, I'm going to recommend that we accept this
> proposal.
>
> We might want to reconsider the name of the extension: QualifiedImportsPostpositive
> seems like a mouthful. Perhaps ImportQualifiedPost is enough?
>
> Cheers
> Simon
>
> On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Dear Committee,
>>
>> this is your secretary speaking:
>>
>> Module qualified syntax
>> has been proposed by Shayne Fletcher
>> https://github.com/ghc-proposals/ghc-proposals/pull/190
>>
>> https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst
>>
>> Simon Marlow has already volunteered to shepherd.
>>
>> Please reach consensus as described in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>> I suggest you make a recommendation, in a new e-mail thread with the
>> proposal number in the subject, about the decision, maybe point out
>> debatable points, and assume that anyone who stays quiet agrees with
>> you.
>>
>> Thanks,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20190308/b60f1484/attachment.html>

From bravit111 at gmail.com  Fri Mar  8 14:44:05 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Fri, 8 Mar 2019 17:44:05 +0300
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>

Simon PJ argues for "value" over "data" as a specifier:
https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193

I'm fine with this choice either (and I'm satisfied with the argument that
deprecating or setting fixity for value "value" is a rare case to be
considered seriously). If you have another opinion, please, speak up.

Vitaly

On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I’ve made a post on the proposal thread asking why we don’t just follow
> the already-adopted proposal for WARNING and infix pragmas.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 08 March 2019 07:57
> *To:* Vitaly Bragilevsky <bravit111 at gmail.com>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
> accept
>
>
>
> Yes, I think this is the right way to go.
>
>
>
> Cheers
>
> Simon
>
>
>
> On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
>
> Hi everyone,
>
>
>
> I was asked to shepherd the proposal #167 (Deprecated Entities,
> https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnineonine%2Fghc-proposals%2Fblob%2Fdepr-entities%2Fproposals%2F0000-deprecated-entities.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630814000&sdata=sJ3QiAx6Z55hJvsYajJEKfx6M8IVZ2DEY4LRRiaBTI8%3D&reserved=0>).
> It is proposed to extend (nonpositional) DEPRECATED pragma with the two
> specifiers to disambiguate deprecating named type-level and value-level
> things. In its current formulation, the proposal suggests to use the
> specifiers "type" for type-level things and "pattern" for value-level
> things as follows:
>
> data Bar = Bar
>
> {-# DEPRECATED type Bar "Don't use type Bar" #-}
>
> data Baz = Baz
>
> {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
>
> Using this pragma without specifiers should mean deprecating both (as is
> works now).
>
>
>
> After discussing this proposal within the committee (see
> https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-February%2F000894.html&data=02%7C01%7Csimonpj%40microsoft.com%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630824013&sdata=DEu9cf6sX2xf%2BxegCrh1TikJT%2B3yWB3BgA1k9CmCLs4%3D&reserved=0>),
> I recommend acceptance with one change, namely using "data" instead of
> "pattern" for deprecating value-level things.
>
>
>
> Reasons for choosing "data":
>
> * it's a reserved keyword (as opposed to "value", which is another option)
>
> * we are deprecating data constructors here
>
> * it just feels right (sorry!)
>
>
>
> Reasons against "data":
>
> * it can be confusing whether we mean data type or data constructor
>
> * we use "value" and "pattern" in other places meaning basically the same
> thing
>
>
>
> If the committee decides to go this way, then the wider community may
> think about other proposals, such as
>
> * adding positional DEPRECATED pragmas (including class instances
> deprecation)
>
> * fixing inconsistencies with the fixity declarations (
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0008-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630834021&sdata=IrpWyWLVksadQK5bo%2B7d%2B10LWuztYUcFwkAUsZxA5cg%3D&reserved=0>)
> and updating ExplicitNamespaces in import/export lists
>
> * deprecating usage of nonpositional DEPRECATED pragma without the
> specifiers
>
>
>
> Silence is understood as agreement.
>
>
>
> Regards,
>
> Vitaly
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630834021&sdata=BfV5VDwcmFI210G0Aq5uZFmsC8Pc5fQdkB%2F8Hi5mtmI%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/8531e671/attachment-0001.html>

From simonpj at microsoft.com  Fri Mar  8 14:46:28 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 8 Mar 2019 14:46:28 +0000
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
Message-ID: <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>

I also argue that, to be consistent, whatever keyword we agree, we should use it

  *   In the (accepted) infix/WARNING proposal
  *   In import and export lists – presumably for now in addition to ‘pattern’, though we might end up deprecating the latter.
Simon

From: Vitaly Bragilevsky <bravit111 at gmail.com>
Sent: 08 March 2019 14:44
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Simon Marlow <marlowsd at gmail.com>; ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept

Simon PJ argues for "value" over "data" as a specifier: https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F167%23issuecomment-470947193&data=02%7C01%7Csimonpj%40microsoft.com%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599100730&sdata=s8VbHAxHZb3vUqXKJXq%2FVMuIiPYwGzPWNJCyE6mWgTU%3D&reserved=0>

I'm fine with this choice either (and I'm satisfied with the argument that deprecating or setting fixity for value "value" is a rare case to be considered seriously). If you have another opinion, please, speak up.

Vitaly

On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I’ve made a post on the proposal thread asking why we don’t just follow the already-adopted proposal for WARNING and infix pragmas.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Simon Marlow
Sent: 08 March 2019 07:57
To: Vitaly Bragilevsky <bravit111 at gmail.com<mailto:bravit111 at gmail.com>>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept

Yes, I think this is the right way to go.

Cheers
Simon

On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com<mailto:bravit111 at gmail.com>> wrote:
Hi everyone,

I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnineonine%2Fghc-proposals%2Fblob%2Fdepr-entities%2Fproposals%2F0000-deprecated-entities.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599110725&sdata=7Ahx5YEJjUcvj7TAR7Y%2Bli5fFDp5O7uH1y5XPOR07Nc%3D&reserved=0>). It is proposed to extend (nonpositional) DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. In its current formulation, the proposal suggests to use the specifiers "type" for type-level things and "pattern" for value-level things as follows:

data Bar = Bar
{-# DEPRECATED type Bar "Don't use type Bar" #-}
data Baz = Baz
{-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}

Using this pragma without specifiers should mean deprecating both (as is works now).

After discussing this proposal within the committee (see https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-February%2F000894.html&data=02%7C01%7Csimonpj%40microsoft.com%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599110725&sdata=qtZe%2Bwn%2Fz770ILSA7Yx50OxzYyXTSr2wJjgDice2yFU%3D&reserved=0>), I recommend acceptance with one change, namely using "data" instead of "pattern" for deprecating value-level things.

Reasons for choosing "data":
* it's a reserved keyword (as opposed to "value", which is another option)
* we are deprecating data constructors here
* it just feels right (sorry!)

Reasons against "data":
* it can be confusing whether we mean data type or data constructor
* we use "value" and "pattern" in other places meaning basically the same thing

If the committee decides to go this way, then the wider community may think about other proposals, such as
* adding positional DEPRECATED pragmas (including class instances deprecation)
* fixing inconsistencies with the fixity declarations (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0008-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599120719&sdata=ZQa8twzFBzNPyUte52GBna0Igb7qGnyqAZrhUps7emM%3D&reserved=0>) and updating ExplicitNamespaces in import/export lists
* deprecating usage of nonpositional DEPRECATED pragma without the specifiers

Silence is understood as agreement.

Regards,
Vitaly
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599120719&sdata=zPbrM1G9Y4w2tUcdANne5mRqGwMYZ2qkhevPzPrdxkE%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/87cd6550/attachment-0001.html>

From eric at seidel.io  Fri Mar  8 15:11:42 2019
From: eric at seidel.io (Eric Seidel)
Date: Fri, 08 Mar 2019 10:11:42 -0500
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <ff3a0f2f-45d3-49ac-b40a-93022db03261@www.fastmail.com>

Yes, the concern about being consistent across fixity, WARNING, import/export, etc. came up when we were discussing this proposal earlier[1], and I think we all agree that consistency is imperative.

[1]: https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html

On Fri, Mar 8, 2019, at 09:46, Simon Peyton Jones via ghc-steering-committee wrote:
>  
> I also argue that, to be consistent, whatever keyword we agree, we should use it
> 
>  * In the (accepted) infix/WARNING proposal
>  * In import and export lists – presumably for now in addition to 
> ‘pattern’, though we might end up deprecating the latter.
> Simon
> 
> 
> *From:* Vitaly Bragilevsky <bravit111 at gmail.com> 
> *Sent:* 08 March 2019 14:44
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Simon Marlow <marlowsd at gmail.com>; ghc-steering-committee 
> <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] #167: Deprecated Entities, rec: 
> accept
> 
> 
> Simon PJ argues for "value" over "data" as a specifier: 
> https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F167%23issuecomment-470947193&data=02%7C01%7Csimonpj%40microsoft.com%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599100730&sdata=s8VbHAxHZb3vUqXKJXq%2FVMuIiPYwGzPWNJCyE6mWgTU%3D&reserved=0>
> 
> 
> I'm fine with this choice either (and I'm satisfied with the argument 
> that deprecating or setting fixity for value "value" is a rare case to 
> be considered seriously). If you have another opinion, please, speak up.
> 
> 
> Vitaly
> 
> 
> On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones 
> <simonpj at microsoft.com> wrote:
> 
> > I’ve made a post on the proposal thread asking why we don’t just follow the already-adopted proposal for WARNING and infix pragmas.
> 
> 
> > Simon
> 
> 
> > *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon Marlow
> > *Sent:* 08 March 2019 07:57
> > *To:* Vitaly Bragilevsky <bravit111 at gmail.com>
> > *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> > *Subject:* Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
> 
> 
> > Yes, I think this is the right way to go.
> 
> 
> > Cheers
> 
> > Simon
> 
> 
> > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> 
> >> Hi everyone, 
> 
> 
> >> I was asked to shepherd the proposal #167 (Deprecated Entities,  https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnineonine%2Fghc-proposals%2Fblob%2Fdepr-entities%2Fproposals%2F0000-deprecated-entities.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599110725&sdata=7Ahx5YEJjUcvj7TAR7Y%2Bli5fFDp5O7uH1y5XPOR07Nc%3D&reserved=0>). It is proposed to extend (nonpositional) DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. In its current formulation, the proposal suggests to use the specifiers "type" for type-level things and "pattern" for value-level things as follows:
> >> 
> >>  data Bar = Bar
> 
> >> {-# DEPRECATED type Bar "Don't use type Bar" #-} 
> 
> >> data Baz = Baz
> 
> >> {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
> >> 
> >>  Using this pragma without specifiers should mean deprecating both (as is works now).
> 
> 
> >> After discussing this proposal within the committee (see  https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-February%2F000894.html&data=02%7C01%7Csimonpj%40microsoft.com%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599110725&sdata=qtZe%2Bwn%2Fz770ILSA7Yx50OxzYyXTSr2wJjgDice2yFU%3D&reserved=0>), I recommend acceptance with one change, namely using "data" instead of "pattern" for deprecating value-level things. 
> 
> 
> >> Reasons for choosing "data":
> 
> >> * it's a reserved keyword (as opposed to "value", which is another option)
> 
> >> * we are deprecating data constructors here
> 
> >> * it just feels right (sorry!)
> 
> 
> >> Reasons against "data":
> 
> >> * it can be confusing whether we mean data type or data constructor
> 
> >> * we use "value" and "pattern" in other places meaning basically the same thing
> 
> 
> >> If the committee decides to go this way, then the wider community may think about other proposals, such as
> 
> >> * adding positional DEPRECATED pragmas (including class instances deprecation)
> 
> >> * fixing inconsistencies with the fixity declarations (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0008-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599120719&sdata=ZQa8twzFBzNPyUte52GBna0Igb7qGnyqAZrhUps7emM%3D&reserved=0>) and updating ExplicitNamespaces in import/export lists
> 
> >> * deprecating usage of nonpositional DEPRECATED pragma without the specifiers
> 
> 
> >> Silence is understood as agreement. 
> 
> 
> >> Regards, 
> 
> >> Vitaly
> 
> >> _______________________________________________
> >>  ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599120719&sdata=zPbrM1G9Y4w2tUcdANne5mRqGwMYZ2qkhevPzPrdxkE%3D&reserved=0>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From iavor.diatchki at gmail.com  Fri Mar  8 16:59:52 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 8 Mar 2019 08:59:52 -0800
Subject: [ghc-steering-committee] #190: Module qualified syntax,
 recommendation: accept
In-Reply-To: <CALpVSmP+s2L0cWZ6WqJnoX-v7xmn8ofit3ekawMPacAjnJdp9w@mail.gmail.com>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <CALpVSmP+s2L0cWZ6WqJnoX-v7xmn8ofit3ekawMPacAjnJdp9w@mail.gmail.com>
Message-ID: <CAGK9nuqaow5pdoebwcQTD8Af2ygpUvmjtW9ACATpZ9c2vEiT3A@mail.gmail.com>

This never bothered me personally, but I have no strong feeling about it
either way.

On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky <bravit111 at gmail.com>
wrote:

> Hello,
>
> I am in favor of this proposal. As for the name of the extension, my
> suggestion is 'FlexibleImports', then we could allow even more flexibility
> in import declarations in the future. Anyway, I am also ok with the current
> versions (although the shorter the better).
>
> Regards,
> Vitaly
>
> On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow <marlowsd at gmail.com> wrote:
>
>> Proposal #190 is about accepting the syntax
>>
>>   import A.B.C qualified
>>
>> instead of (or in addition to) the existing syntax
>>
>>   import qualified A.B.C
>>
>> I think it's widely accepted that the original syntax was a mistake. I
>> don't need to rehash the rationale for the change here, iit's described
>> pretty well in the proposal and elaborated in the discussion.
>>
>> The question for us is really: is it worth changing? There are costs:
>> - A new extension flag, which itself has costs (extra documentation, a
>> new thing that people need to understand)
>> - new code using the extension doesn't compile with older compilers
>> - all the existing code in the world uses the old convention
>> - etc.
>>
>> Reasonable people can differ here. The discussion on the proposal has
>> representatives from both sides of the camp.
>>
>> Personally, the current syntax annoys me almost every day. It's already a
>> small cost on everyone, and I think we need to move forwards even if there
>> are costs in migrating. So, I'm going to recommend that we accept this
>> proposal.
>>
>> We might want to reconsider the name of the extension: QualifiedImportsPostpositive
>> seems like a mouthful. Perhaps ImportQualifiedPost is enough?
>>
>> Cheers
>> Simon
>>
>> On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>>> Dear Committee,
>>>
>>> this is your secretary speaking:
>>>
>>> Module qualified syntax
>>> has been proposed by Shayne Fletcher
>>> https://github.com/ghc-proposals/ghc-proposals/pull/190
>>>
>>> https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst
>>>
>>> Simon Marlow has already volunteered to shepherd.
>>>
>>> Please reach consensus as described in
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>> I suggest you make a recommendation, in a new e-mail thread with the
>>> proposal number in the subject, about the decision, maybe point out
>>> debatable points, and assume that anyone who stays quiet agrees with
>>> you.
>>>
>>> Thanks,
>>> Joachim
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20190308/5a8a558a/attachment.html>

From iavor.diatchki at gmail.com  Fri Mar  8 17:03:17 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 8 Mar 2019 09:03:17 -0800
Subject: [ghc-steering-committee] #195: Make Q (TExp a) into a newtype,
 rec: accept
In-Reply-To: <AM0PR83MB028936B9C4DF562AF458C8E9AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <CALpVSmPNrEPDKJm3xbtAMyhgUbyfKLUvTHqPgWAjcfgzOT-N0g@mail.gmail.com>
 <AM0PR83MB028936B9C4DF562AF458C8E9AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuoboVbMB_9UHzbB7BmsX7eMFb6L8FGV=4+9DGnexA_jMg@mail.gmail.com>

I agree that we should probably accept this.

I wonder if there are cases where one might one to go in the other
direction, i.e., do we also need a function:  `Code a -> Q (TExp a)`?

-Iavor

On Fri, Mar 8, 2019 at 12:51 AM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Yes, I agree.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Vitaly Bragilevsky
> *Sent:* 08 March 2019 06:41
> *To:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* [ghc-steering-committee] #195: Make Q (TExp a) into a newtype,
> rec: accept
>
>
>
> Hi everyone,
>
>
>
> Matthew Pickering proposed to make Q (TExp a) into a newtype called Code.
>
> Proposal #195:
> https://github.com/ghc-proposals/ghc-proposals/blob/22e97d7693edb0b3676c948a123e57ea93c462e3/proposals/0000-code-texp.rst
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2F22e97d7693edb0b3676c948a123e57ea93c462e3%2Fproposals%2F0000-code-texp.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C283dee8b70474ae9761308d6a3910fb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876240764020521&sdata=Cq32fdykV9oonakOOFbAnV7LulmupHXHq0p2c9raKFs%3D&reserved=0>
>
> Pull request discussion:
> https://github.com/ghc-proposals/ghc-proposals/pull/195
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F195&data=02%7C01%7Csimonpj%40microsoft.com%7C283dee8b70474ae9761308d6a3910fb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876240764030529&sdata=6CqagCiMbgVgSgmWeLTcDbauGsB111fn7DOyuMiXemI%3D&reserved=0>
>
>
>
> It looks like the motivation behind this proposal boils down to the
> convenience of writing instances which seems a good thing. The minor
> problem I see is the proposed name "Code" as it looks a little bit too
> abstract for Typed Template Haskell expressions. Nevertheless, I recommend
> to accept the proposal as it is. Silence is understood as agreement.
>
>
>
> Regards,
>
> Vitaly
> _______________________________________________
> 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/20190308/da37bff1/attachment-0001.html>

From rae at cs.brynmawr.edu  Fri Mar  8 17:26:45 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 8 Mar 2019 12:26:45 -0500
Subject: [ghc-steering-committee] #195: Make Q (TExp a) into a newtype,
 rec: accept
In-Reply-To: <CAGK9nuoboVbMB_9UHzbB7BmsX7eMFb6L8FGV=4+9DGnexA_jMg@mail.gmail.com>
References: <CALpVSmPNrEPDKJm3xbtAMyhgUbyfKLUvTHqPgWAjcfgzOT-N0g@mail.gmail.com>
 <AM0PR83MB028936B9C4DF562AF458C8E9AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CAGK9nuoboVbMB_9UHzbB7BmsX7eMFb6L8FGV=4+9DGnexA_jMg@mail.gmail.com>
Message-ID: <634BBAE8-3A1F-430B-BF37-487514CD8B39@cs.brynmawr.edu>

Yes, I agree that we need functions in both directions. I support this proposal.

Richard

> On Mar 8, 2019, at 12:03 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> I agree that we should probably accept this.
> 
> I wonder if there are cases where one might one to go in the other direction, i.e., do we also need a function:  `Code a -> Q (TExp a)`?
> 
> -Iavor
> 
> On Fri, Mar 8, 2019 at 12:51 AM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
> Yes, I agree.
> 
>  
> 
> Simon
> 
>  
> 
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Vitaly Bragilevsky
> Sent: 08 March 2019 06:41
> To: ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> Subject: [ghc-steering-committee] #195: Make Q (TExp a) into a newtype, rec: accept
> 
>  
> 
> Hi everyone, 
> 
>  
> 
> Matthew Pickering proposed to make Q (TExp a) into a newtype called Code. 
> 
> Proposal #195: https://github.com/ghc-proposals/ghc-proposals/blob/22e97d7693edb0b3676c948a123e57ea93c462e3/proposals/0000-code-texp.rst <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2F22e97d7693edb0b3676c948a123e57ea93c462e3%2Fproposals%2F0000-code-texp.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C283dee8b70474ae9761308d6a3910fb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876240764020521&sdata=Cq32fdykV9oonakOOFbAnV7LulmupHXHq0p2c9raKFs%3D&reserved=0>
> Pull request discussion: https://github.com/ghc-proposals/ghc-proposals/pull/195 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F195&data=02%7C01%7Csimonpj%40microsoft.com%7C283dee8b70474ae9761308d6a3910fb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876240764030529&sdata=6CqagCiMbgVgSgmWeLTcDbauGsB111fn7DOyuMiXemI%3D&reserved=0>
>  
> 
> It looks like the motivation behind this proposal boils down to the convenience of writing instances which seems a good thing. The minor problem I see is the proposed name "Code" as it looks a little bit too abstract for Typed Template Haskell expressions. Nevertheless, I recommend to accept the proposal as it is. Silence is understood as agreement.
> 
>  
> 
> Regards, 
> 
> Vitaly
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> 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/20190308/231f3a4a/attachment.html>

From marlowsd at gmail.com  Fri Mar  8 17:36:31 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 8 Mar 2019 17:36:31 +0000
Subject: [ghc-steering-committee] #190: Module qualified syntax,
 recommendation: accept
In-Reply-To: <7a7b9ec3a38c1c0a9cff2172aebd118654027335.camel@joachim-breitner.de>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <AM0PR83MB028917B1EED79F22B6D8B0E4AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <7a7b9ec3a38c1c0a9cff2172aebd118654027335.camel@joachim-breitner.de>
Message-ID: <CANsrgPJ5WcqNxiR_KK3DueWKVKNBKTrdTNQDixkcUQ+UxSegyQ@mail.gmail.com>

On Fri, 8 Mar 2019 at 09:29, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Am Freitag, den 08.03.2019, 08:55 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
> > My only question is: do we really need a  flag.  Suppose we simply
> > accepted the postfix “qualified” with no flag support.  Then a
> > program will be accepted that earlier compilers would have rejected –
> > and, absent a flag, we normally try to continue to reject programs
> > that weren’t legal before.  But in this case no one is going to fall
> > into this by mistake.  I suggest we consider simply allowing it as an
> > exception to our general rule, and move on.
>
> Let’s not do this. We have very few hard guidelines to help us in our
> work; “changes to the language needs a flag” is one of them. If we
> start to be lax here, we will have to justify every future flag where
> the extension would just be an invalid program otherwise, including
> things like LambdaCase etc.
>
> It is tempting, but the slope is too slippery.
>
> Most of our users (in particular the “experienced users” mentioned
> above) are used to managing a long list of flags, adding another will
> not hurt them to manage another one.
>
> And if this management becomes too long, then instead of making
> exceptions, we should either hope for Haskell20xx to liberally include
> these “convenience extensions”, or otherwise make the management of the
> extension list easier (e.g. maybe by picking up
> https://github.com/ghc-proposals/ghc-proposals/pull/92 again).
>

Yes - everything that changes the language in some way should have an
extension flag. We've been strict about this up to now, I think it would be
a shame to start making exceptions. We have the nice property that if a
module would fail to compile because it uses an extension that isn't
supported by the compiler in use, we get a useful diagnostic rather than
just a parse error. Every source file declares which language it is written
in (well, together with the .cabal file), which is a nice property to have,
and useful for other tooling in addition to compilers.

Cheers
Simon


> As for a shorter name, now about QualifiedLast?
>
>
> Cheers,
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20190308/812dcc21/attachment.html>

From rae at cs.brynmawr.edu  Fri Mar  8 17:37:29 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 8 Mar 2019 12:37:29 -0500
Subject: [ghc-steering-committee] #190: Module qualified syntax,
 recommendation: accept
In-Reply-To: <CAGK9nuqaow5pdoebwcQTD8Af2ygpUvmjtW9ACATpZ9c2vEiT3A@mail.gmail.com>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <CALpVSmP+s2L0cWZ6WqJnoX-v7xmn8ofit3ekawMPacAjnJdp9w@mail.gmail.com>
 <CAGK9nuqaow5pdoebwcQTD8Af2ygpUvmjtW9ACATpZ9c2vEiT3A@mail.gmail.com>
Message-ID: <2A4CEC6F-5A55-43D8-9714-F507AE1A8CBC@cs.brynmawr.edu>

Like many on this list, I've never been bothered by the existing syntax. But I am swayed by experienced folks who very much want this.

I like Vitaly's idea of opening the door to future changes. I think there is more improvement to be found in our import/export syntax than just this one change, and so if we have a generic enough language extension, it allows us to consider smallish syntax changes without new language extensions in the future. `FlexibleImports` is as good a name as any, I think.

As to the annoyance about adding language extensions: what if we issue a *warning*, not an error, when the user writes a program without specifying the extension? This warning would be on by default (but could, naturally, be suppressed). I'd be comfortable with expanding this treatment by identifying a set of "benign" extensions. Each benign extension would have an accompanying warning, e.g., -Wmissing-FlexibleInstances. These would all be on by default, suppressed with either, e.g., -XFlexibleInstances or -Wno-missing-FlexibleInstances. (Interestingly, the semantics of -XFlexibleInstances and -Wno-missing-FlexibleInstances is identical. Hmm.)

Definition: A *benign* extension is one that, when enabled, strictly increases the set of programs GHC accepts. It never changes the meaning of any program that was accepted without the extension.

I don't feel strongly on this warning idea, but I wanted to throw it out there.

Richard

> On Mar 8, 2019, at 11:59 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> This never bothered me personally, but I have no strong feeling about it either way. 
> 
> On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky <bravit111 at gmail.com <mailto:bravit111 at gmail.com>> wrote:
> Hello, 
> 
> I am in favor of this proposal. As for the name of the extension, my suggestion is 'FlexibleImports', then we could allow even more flexibility in import declarations in the future. Anyway, I am also ok with the current versions (although the shorter the better).
> 
> Regards, 
> Vitaly
> 
> On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
> Proposal #190 is about accepting the syntax
> 
>   import A.B.C qualified
> 
> instead of (or in addition to) the existing syntax
> 
>   import qualified A.B.C
> 
> I think it's widely accepted that the original syntax was a mistake. I don't need to rehash the rationale for the change here, iit's described pretty well in the proposal and elaborated in the discussion.
> 
> The question for us is really: is it worth changing? There are costs:
> - A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand)
> - new code using the extension doesn't compile with older compilers
> - all the existing code in the world uses the old convention
> - etc.
> 
> Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.
> 
> Personally, the current syntax annoys me almost every day. It's already a small cost on everyone, and I think we need to move forwards even if there are costs in migrating. So, I'm going to recommend that we accept this proposal.
> 
> We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?
> 
> Cheers
> Simon
> 
> On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Module qualified syntax
> has been proposed by Shayne Fletcher
> https://github.com/ghc-proposals/ghc-proposals/pull/190 <https://github.com/ghc-proposals/ghc-proposals/pull/190>
> https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst <https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst>
> 
> Simon Marlow has already volunteered to shepherd.
> 
> Please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> I suggest you make a recommendation, in a new e-mail thread with the
> proposal number in the subject, about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
> 
> Thanks,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> 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/20190308/04a4048b/attachment-0001.html>

From mail at joachim-breitner.de  Fri Mar  8 17:45:25 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 08 Mar 2019 18:45:25 +0100
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
Message-ID: <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>

Hi,

I fully support this (I thought I brought it up before, but maybe not
strongly enough).

Should we just include this change in #167? (If politicians can add
random riders to laws, so can we). Or does it need more thought?

Cheers,
Joachim


Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> I also argue that, to be consistent, whatever keyword we agree, we should use it
> In the (accepted) infix/WARNING proposal
> In import and export lists – presumably for now in addition to ‘pattern’, though we might end up deprecating the latter.
> Simon
>  
> From: Vitaly Bragilevsky <bravit111 at gmail.com> 
> Sent: 08 March 2019 14:44
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: Simon Marlow <marlowsd at gmail.com>; ghc-steering-committee <ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
>  
> Simon PJ argues for "value" over "data" as a specifier: https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193
>  
> I'm fine with this choice either (and I'm satisfied with the argument that deprecating or setting fixity for value "value" is a rare case to be considered seriously). If you have another opinion, please, speak up.
>  
> Vitaly
>  
> On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > I’ve made a post on the proposal thread asking why we don’t just follow the already-adopted proposal for WARNING and infix pragmas.
> >  
> > Simon
> >  
> > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
> > Sent: 08 March 2019 07:57
> > To: Vitaly Bragilevsky <bravit111 at gmail.com>
> > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
> >  
> > Yes, I think this is the right way to go.
> >  
> > Cheers
> > Simon
> >  
> > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> > > Hi everyone, 
> > >  
> > > I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst). It is proposed to extend (nonpositional) DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. In its current formulation, the proposal suggests to use the specifiers "type" for type-level things and "pattern" for value-level things as follows:
> > > 
> > > data Bar = Bar
> > > {-# DEPRECATED type Bar "Don't use type Bar" #-} 
> > > data Baz = Baz
> > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
> > > 
> > > Using this pragma without specifiers should mean deprecating both (as is works now).
> > >  
> > > After discussing this proposal within the committee (see https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html), I recommend acceptance with one change, namely using "data" instead of "pattern" for deprecating value-level things. 
> > >  
> > > Reasons for choosing "data":
> > > * it's a reserved keyword (as opposed to "value", which is another option)
> > > * we are deprecating data constructors here
> > > * it just feels right (sorry!)
> > >  
> > > Reasons against "data":
> > > * it can be confusing whether we mean data type or data constructor
> > > * we use "value" and "pattern" in other places meaning basically the same thing
> > >  
> > > If the committee decides to go this way, then the wider community may think about other proposals, such as
> > > * adding positional DEPRECATED pragmas (including class instances deprecation)
> > > * fixing inconsistencies with the fixity declarations (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst) and updating ExplicitNamespaces in import/export lists
> > > * deprecating usage of nonpositional DEPRECATED pragma without the specifiers
> > >  
> > > Silence is understood as agreement. 
> > >  
> > > Regards, 
> > > Vitaly
> > > 
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/57aeb3d3/attachment.sig>

From mail at joachim-breitner.de  Fri Mar  8 17:52:02 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 08 Mar 2019 18:52:02 +0100
Subject: [ghc-steering-committee] -Wmissing-language (Was: Module qualified
	syntax)
In-Reply-To: <2A4CEC6F-5A55-43D8-9714-F507AE1A8CBC@cs.brynmawr.edu>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <CALpVSmP+s2L0cWZ6WqJnoX-v7xmn8ofit3ekawMPacAjnJdp9w@mail.gmail.com>
 <CAGK9nuqaow5pdoebwcQTD8Af2ygpUvmjtW9ACATpZ9c2vEiT3A@mail.gmail.com>
 <2A4CEC6F-5A55-43D8-9714-F507AE1A8CBC@cs.brynmawr.edu>
Message-ID: <7a4d0020eb1ef5437eadf61aa8e65aedf43b6175.camel@joachim-breitner.de>

Hi,

let’s see. Currently, we issue an *error*

   error: Illegal lambda-case (use -XLambdaCase)

your idea would turn that into a warning

   warning [-Wmissing-LambdaCase] : Illegal lambda-case (use -XLambdaCase)

It is odd that now -Wno-missing-LambdaCase and -XLambdaCase are essentially the same.



But how about we add a single warning category:

   warning [-Wmissing-langauge] : Illegal lambda-case (use -XLambdaCase)

We could even leave the default as 

   -Werror=missing-langauge

matching existing behavior. People who want to play around more liberally can use

   -Wwarn=missing-language

and get notified which extensions they might want (maybe a good default
for ghci?), and those who really don't care can use

   -Wno-missing-language


And then the question is: Do this only only for benign extensions? Only
for those where we can easily issue warnings? For all?


Not sure how useful it is, but it might be.

Cheers,
Joachim


Am Freitag, den 08.03.2019, 12:37 -0500 schrieb Richard Eisenberg:
> Like many on this list, I've never been bothered by the existing syntax. But I am swayed by experienced folks who very much want this.
> 
> I like Vitaly's idea of opening the door to future changes. I think there is more improvement to be found in our import/export syntax than just this one change, and so if we have a generic enough language extension, it allows us to consider smallish syntax changes without new language extensions in the future. `FlexibleImports` is as good a name as any, I think.
> 
> As to the annoyance about adding language extensions: what if we issue a *warning*, not an error, when the user writes a program without specifying the extension? This warning would be on by default (but could, naturally, be suppressed). I'd be comfortable with expanding this treatment by identifying a set of "benign" extensions. Each benign extension would have an accompanying warning, e.g., -Wmissing-FlexibleInstances. These would all be on by default, suppressed with either, e.g., -XFlexibleInstances or -Wno-missing-FlexibleInstances. (Interestingly, the semantics of -XFlexibleInstances and -Wno-missing-FlexibleInstances is identical. Hmm.)
> 
> Definition: A *benign* extension is one that, when enabled, strictly increases the set of programs GHC accepts. It never changes the meaning of any program that was accepted without the extension.
> 
> I don't feel strongly on this warning idea, but I wanted to throw it out there.
> 
> Richard
> 
> > On Mar 8, 2019, at 11:59 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> > 
> > This never bothered me personally, but I have no strong feeling about it either way. 
> > 
> > On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> > > Hello, 
> > > 
> > > I am in favor of this proposal. As for the name of the extension, my suggestion is 'FlexibleImports', then we could allow even more flexibility in import declarations in the future. Anyway, I am also ok with the current versions (although the shorter the better).
> > > 
> > > Regards, 
> > > Vitaly
> > > 
> > > On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow <marlowsd at gmail.com> wrote:
> > > > Proposal #190 is about accepting the syntax
> > > > 
> > > >   import A.B.C qualified
> > > > 
> > > > instead of (or in addition to) the existing syntax
> > > > 
> > > >   import qualified A.B.C
> > > > 
> > > > I think it's widely accepted that the original syntax was a mistake. I don't need to rehash the rationale for the change here, iit's described pretty well in the proposal and elaborated in the discussion.
> > > > 
> > > > The question for us is really: is it worth changing? There are costs:
> > > > - A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand)
> > > > - new code using the extension doesn't compile with older compilers
> > > > - all the existing code in the world uses the old convention
> > > > - etc.
> > > > 
> > > > Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.
> > > > 
> > > > Personally, the current syntax annoys me almost every day. It's already a small cost on everyone, and I think we need to move forwards even if there are costs in migrating. So, I'm going to recommend that we accept this proposal.
> > > > 
> > > > We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?
> > > > 
> > > > Cheers
> > > > Simon
> > > > 
> > > > On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > > > > Dear Committee,
> > > > > 
> > > > > this is your secretary speaking:
> > > > > 
> > > > > Module qualified syntax
> > > > > has been proposed by Shayne Fletcher
> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/190
> > > > > https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst
> > > > > 
> > > > > Simon Marlow has already volunteered to shepherd.
> > > > > 
> > > > > Please reach consensus as described in
> > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > > > I suggest you make a recommendation, in a new e-mail thread with the
> > > > > proposal number in the subject, about the decision, maybe point out
> > > > > debatable points, and assume that anyone who stays quiet agrees with
> > > > > you.
> > > > > 
> > > > > Thanks,
> > > > > Joachim
> > > > > -- 
> > > > > Joachim Breitner
> > > > >   mail at joachim-breitner.de
> > > > >   http://www.joachim-breitner.de/
> > > > > 
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > ghc-steering-committee at haskell.org
> > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > 
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > 
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/1bd8d6c3/attachment.sig>

From bravit111 at gmail.com  Fri Mar  8 18:12:59 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Fri, 8 Mar 2019 21:12:59 +0300
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
Message-ID: <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>

I think we don't have a consensus on the particular word yet: is it data or
value. I'd like to listen to Richard who was strongly in favor of data. We
are in agreement about consistency though.

Vitaly


On Fri, Mar 8, 2019 at 8:45 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> I fully support this (I thought I brought it up before, but maybe not
> strongly enough).
>
> Should we just include this change in #167? (If politicians can add
> random riders to laws, so can we). Or does it need more thought?
>
> Cheers,
> Joachim
>
>
> Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
> > I also argue that, to be consistent, whatever keyword we agree, we
> should use it
> > In the (accepted) infix/WARNING proposal
> > In import and export lists – presumably for now in addition to
> ‘pattern’, though we might end up deprecating the latter.
> > Simon
> >
> > From: Vitaly Bragilevsky <bravit111 at gmail.com>
> > Sent: 08 March 2019 14:44
> > To: Simon Peyton Jones <simonpj at microsoft.com>
> > Cc: Simon Marlow <marlowsd at gmail.com>; ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
> accept
> >
> > Simon PJ argues for "value" over "data" as a specifier:
> https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193
> >
> > I'm fine with this choice either (and I'm satisfied with the argument
> that deprecating or setting fixity for value "value" is a rare case to be
> considered seriously). If you have another opinion, please, speak up.
> >
> > Vitaly
> >
> > On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
> > > I’ve made a post on the proposal thread asking why we don’t just
> follow the already-adopted proposal for WARNING and infix pragmas.
> > >
> > > Simon
> > >
> > > From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
> > > Sent: 08 March 2019 07:57
> > > To: Vitaly Bragilevsky <bravit111 at gmail.com>
> > > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
> accept
> > >
> > > Yes, I think this is the right way to go.
> > >
> > > Cheers
> > > Simon
> > >
> > > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
> > > > Hi everyone,
> > > >
> > > > I was asked to shepherd the proposal #167 (Deprecated Entities,
> https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst).
> It is proposed to extend (nonpositional) DEPRECATED pragma with the two
> specifiers to disambiguate deprecating named type-level and value-level
> things. In its current formulation, the proposal suggests to use the
> specifiers "type" for type-level things and "pattern" for value-level
> things as follows:
> > > >
> > > > data Bar = Bar
> > > > {-# DEPRECATED type Bar "Don't use type Bar" #-}
> > > > data Baz = Baz
> > > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
> > > >
> > > > Using this pragma without specifiers should mean deprecating both
> (as is works now).
> > > >
> > > > After discussing this proposal within the committee (see
> https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html),
> I recommend acceptance with one change, namely using "data" instead of
> "pattern" for deprecating value-level things.
> > > >
> > > > Reasons for choosing "data":
> > > > * it's a reserved keyword (as opposed to "value", which is another
> option)
> > > > * we are deprecating data constructors here
> > > > * it just feels right (sorry!)
> > > >
> > > > Reasons against "data":
> > > > * it can be confusing whether we mean data type or data constructor
> > > > * we use "value" and "pattern" in other places meaning basically the
> same thing
> > > >
> > > > If the committee decides to go this way, then the wider community
> may think about other proposals, such as
> > > > * adding positional DEPRECATED pragmas (including class instances
> deprecation)
> > > > * fixing inconsistencies with the fixity declarations (
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst)
> and updating ExplicitNamespaces in import/export lists
> > > > * deprecating usage of nonpositional DEPRECATED pragma without the
> specifiers
> > > >
> > > > Silence is understood as agreement.
> > > >
> > > > Regards,
> > > > Vitaly
> > > >
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20190308/3d3bd41e/attachment-0001.html>

From marlowsd at gmail.com  Fri Mar  8 19:03:16 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 8 Mar 2019 19:03:16 +0000
Subject: [ghc-steering-committee] -Wmissing-language (Was: Module
 qualified syntax)
In-Reply-To: <7a4d0020eb1ef5437eadf61aa8e65aedf43b6175.camel@joachim-breitner.de>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <CALpVSmP+s2L0cWZ6WqJnoX-v7xmn8ofit3ekawMPacAjnJdp9w@mail.gmail.com>
 <CAGK9nuqaow5pdoebwcQTD8Af2ygpUvmjtW9ACATpZ9c2vEiT3A@mail.gmail.com>
 <2A4CEC6F-5A55-43D8-9714-F507AE1A8CBC@cs.brynmawr.edu>
 <7a4d0020eb1ef5437eadf61aa8e65aedf43b6175.camel@joachim-breitner.de>
Message-ID: <CANsrgPJpbhb9_aniNE=zTBiT=cnX=D9Dqiw873sr3VXA7i7Mgg@mail.gmail.com>

On Fri, 8 Mar 2019 at 17:52, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> let’s see. Currently, we issue an *error*
>
>    error: Illegal lambda-case (use -XLambdaCase)
>
> your idea would turn that into a warning
>
>    warning [-Wmissing-LambdaCase] : Illegal lambda-case (use -XLambdaCase)
>
> It is odd that now -Wno-missing-LambdaCase and -XLambdaCase are
> essentially the same.
>
>
>
> But how about we add a single warning category:
>
>    warning [-Wmissing-langauge] : Illegal lambda-case (use -XLambdaCase)
>
> We could even leave the default as
>
>    -Werror=missing-langauge
>
> matching existing behavior. People who want to play around more liberally
> can use
>
>    -Wwarn=missing-language
>
> and get notified which extensions they might want (maybe a good default
> for ghci?), and those who really don't care can use
>
>    -Wno-missing-language
>

So {-# OPTIONS_GHC -Wno-missing-language #-} at the top of the file would
essentially exempt the file from having to specify LANGUAGE pragmas for
some the extensions that it uses, which is the same as saying that some
extensions don't need LANGUAGE pragmas. I think that would be a shame,
because we lose all the nice properties that we get from being strict about
requiring LANGUAGE pragmas for extensions.  Even -Wwarn=missing-language
would be dangerous in the same sense.

I'm not a fan of this.  I like warnings for unused extension pragmas, but
not for missing pragmas.

Incidentally, having extensions that we add to later, like
FlexiableImports, is also somewhat dodgy because the same extension pragma
means different things depending on which compiler version you're using.
Perhaps being completely strict about this is not feasible in general (we
make small changes to extensions a lot, and it would be silly to make a new
flag each time), but it's an area we should be careful about. If we add to
FlexibleImports, and you're using an older version of the compiler that
doesn't support whatever addition we made to it, we'll get a parse error
instead of a "unsupported extension" diagnostic.

Cheers
Simon



>
>
> And then the question is: Do this only only for benign extensions? Only
> for those where we can easily issue warnings? For all?
>
>
> Not sure how useful it is, but it might be.
>
> Cheers,
> Joachim
>
>
> Am Freitag, den 08.03.2019, 12:37 -0500 schrieb Richard Eisenberg:
> > Like many on this list, I've never been bothered by the existing syntax.
> But I am swayed by experienced folks who very much want this.
> >
> > I like Vitaly's idea of opening the door to future changes. I think
> there is more improvement to be found in our import/export syntax than just
> this one change, and so if we have a generic enough language extension, it
> allows us to consider smallish syntax changes without new language
> extensions in the future. `FlexibleImports` is as good a name as any, I
> think.
> >
> > As to the annoyance about adding language extensions: what if we issue a
> *warning*, not an error, when the user writes a program without specifying
> the extension? This warning would be on by default (but could, naturally,
> be suppressed). I'd be comfortable with expanding this treatment by
> identifying a set of "benign" extensions. Each benign extension would have
> an accompanying warning, e.g., -Wmissing-FlexibleInstances. These would all
> be on by default, suppressed with either, e.g., -XFlexibleInstances or
> -Wno-missing-FlexibleInstances. (Interestingly, the semantics of
> -XFlexibleInstances and -Wno-missing-FlexibleInstances is identical. Hmm.)
> >
> > Definition: A *benign* extension is one that, when enabled, strictly
> increases the set of programs GHC accepts. It never changes the meaning of
> any program that was accepted without the extension.
> >
> > I don't feel strongly on this warning idea, but I wanted to throw it out
> there.
> >
> > Richard
> >
> > > On Mar 8, 2019, at 11:59 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
> > >
> > > This never bothered me personally, but I have no strong feeling about
> it either way.
> > >
> > > On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
> > > > Hello,
> > > >
> > > > I am in favor of this proposal. As for the name of the extension, my
> suggestion is 'FlexibleImports', then we could allow even more flexibility
> in import declarations in the future. Anyway, I am also ok with the current
> versions (although the shorter the better).
> > > >
> > > > Regards,
> > > > Vitaly
> > > >
> > > > On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow <marlowsd at gmail.com>
> wrote:
> > > > > Proposal #190 is about accepting the syntax
> > > > >
> > > > >   import A.B.C qualified
> > > > >
> > > > > instead of (or in addition to) the existing syntax
> > > > >
> > > > >   import qualified A.B.C
> > > > >
> > > > > I think it's widely accepted that the original syntax was a
> mistake. I don't need to rehash the rationale for the change here, iit's
> described pretty well in the proposal and elaborated in the discussion.
> > > > >
> > > > > The question for us is really: is it worth changing? There are
> costs:
> > > > > - A new extension flag, which itself has costs (extra
> documentation, a new thing that people need to understand)
> > > > > - new code using the extension doesn't compile with older compilers
> > > > > - all the existing code in the world uses the old convention
> > > > > - etc.
> > > > >
> > > > > Reasonable people can differ here. The discussion on the proposal
> has representatives from both sides of the camp.
> > > > >
> > > > > Personally, the current syntax annoys me almost every day. It's
> already a small cost on everyone, and I think we need to move forwards even
> if there are costs in migrating. So, I'm going to recommend that we accept
> this proposal.
> > > > >
> > > > > We might want to reconsider the name of the extension:
> QualifiedImportsPostpositive seems like a mouthful. Perhaps
> ImportQualifiedPost is enough?
> > > > >
> > > > > Cheers
> > > > > Simon
> > > > >
> > > > > On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
> > > > > > Dear Committee,
> > > > > >
> > > > > > this is your secretary speaking:
> > > > > >
> > > > > > Module qualified syntax
> > > > > > has been proposed by Shayne Fletcher
> > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/190
> > > > > >
> https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst
> > > > > >
> > > > > > Simon Marlow has already volunteered to shepherd.
> > > > > >
> > > > > > Please reach consensus as described in
> > > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > > > > I suggest you make a recommendation, in a new e-mail thread with
> the
> > > > > > proposal number in the subject, about the decision, maybe point
> out
> > > > > > debatable points, and assume that anyone who stays quiet agrees
> with
> > > > > > you.
> > > > > >
> > > > > > Thanks,
> > > > > > Joachim
> > > > > > --
> > > > > > Joachim Breitner
> > > > > >   mail at joachim-breitner.de
> > > > > >   http://www.joachim-breitner.de/
> > > > > >
> > > > > > _______________________________________________
> > > > > > ghc-steering-committee mailing list
> > > > > > ghc-steering-committee at haskell.org
> > > > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > >
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > ghc-steering-committee at haskell.org
> > > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > >
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20190308/66da8416/attachment.html>

From eric at seidel.io  Fri Mar  8 19:20:50 2019
From: eric at seidel.io (Eric Seidel)
Date: Fri, 08 Mar 2019 14:20:50 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?-Wmissing-language_=28Was=3A_M?=
 =?utf-8?q?odule_qualified=09syntax=29?=
In-Reply-To: <7a4d0020eb1ef5437eadf61aa8e65aedf43b6175.camel@joachim-breitner.de>
References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de>
 <CANsrgPJ3Rv3orfdjfi=QTOj71rbab5kDraOoKk6Hqyyhmk=dmg@mail.gmail.com>
 <CALpVSmP+s2L0cWZ6WqJnoX-v7xmn8ofit3ekawMPacAjnJdp9w@mail.gmail.com>
 <CAGK9nuqaow5pdoebwcQTD8Af2ygpUvmjtW9ACATpZ9c2vEiT3A@mail.gmail.com>
 <2A4CEC6F-5A55-43D8-9714-F507AE1A8CBC@cs.brynmawr.edu>
 <7a4d0020eb1ef5437eadf61aa8e65aedf43b6175.camel@joachim-breitner.de>
Message-ID: <21c69a9a-c78d-4224-b0e7-ebad2ef2556f@www.fastmail.com>

I don't think this is necessary. Managing language extensions is not that hard, and can be trivial with good tooling (which at least some editors already have).

That being said, I suspect that most if not all benign extensions would be good candidates for inclusion in the next language standard.

On Fri, Mar 8, 2019, at 12:52, Joachim Breitner wrote:
> Hi,
> 
> let’s see. Currently, we issue an *error*
> 
>  error: Illegal lambda-case (use -XLambdaCase)
> 
> your idea would turn that into a warning
> 
>  warning [-Wmissing-LambdaCase] : Illegal lambda-case (use -XLambdaCase)
> 
> It is odd that now -Wno-missing-LambdaCase and -XLambdaCase are 
> essentially the same.
> 
> 
> 
> But how about we add a single warning category:
> 
>  warning [-Wmissing-langauge] : Illegal lambda-case (use -XLambdaCase)
> 
> We could even leave the default as 
> 
>  -Werror=missing-langauge
> 
> matching existing behavior. People who want to play around more 
> liberally can use
> 
>  -Wwarn=missing-language
> 
> and get notified which extensions they might want (maybe a good default
> for ghci?), and those who really don't care can use
> 
>  -Wno-missing-language
> 
> 
> And then the question is: Do this only only for benign extensions? Only
> for those where we can easily issue warnings? For all?
> 
> 
> Not sure how useful it is, but it might be.
> 
> Cheers,
> Joachim
> 
> 
> Am Freitag, den 08.03.2019, 12:37 -0500 schrieb Richard Eisenberg:
> > Like many on this list, I've never been bothered by the existing syntax. But I am swayed by experienced folks who very much want this.
> > 
> > I like Vitaly's idea of opening the door to future changes. I think there is more improvement to be found in our import/export syntax than just this one change, and so if we have a generic enough language extension, it allows us to consider smallish syntax changes without new language extensions in the future. `FlexibleImports` is as good a name as any, I think.
> > 
> > As to the annoyance about adding language extensions: what if we issue a *warning*, not an error, when the user writes a program without specifying the extension? This warning would be on by default (but could, naturally, be suppressed). I'd be comfortable with expanding this treatment by identifying a set of "benign" extensions. Each benign extension would have an accompanying warning, e.g., -Wmissing-FlexibleInstances. These would all be on by default, suppressed with either, e.g., -XFlexibleInstances or -Wno-missing-FlexibleInstances. (Interestingly, the semantics of -XFlexibleInstances and -Wno-missing-FlexibleInstances is identical. Hmm.)
> > 
> > Definition: A *benign* extension is one that, when enabled, strictly increases the set of programs GHC accepts. It never changes the meaning of any program that was accepted without the extension.
> > 
> > I don't feel strongly on this warning idea, but I wanted to throw it out there.
> > 
> > Richard
> > 
> > > On Mar 8, 2019, at 11:59 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> > > 
> > > This never bothered me personally, but I have no strong feeling about it either way. 
> > > 
> > > On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> > > > Hello, 
> > > > 
> > > > I am in favor of this proposal. As for the name of the extension, my suggestion is 'FlexibleImports', then we could allow even more flexibility in import declarations in the future. Anyway, I am also ok with the current versions (although the shorter the better).
> > > > 
> > > > Regards, 
> > > > Vitaly
> > > > 
> > > > On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow <marlowsd at gmail.com> wrote:
> > > > > Proposal #190 is about accepting the syntax
> > > > > 
> > > > > import A.B.C qualified
> > > > > 
> > > > > instead of (or in addition to) the existing syntax
> > > > > 
> > > > > import qualified A.B.C
> > > > > 
> > > > > I think it's widely accepted that the original syntax was a mistake. I don't need to rehash the rationale for the change here, iit's described pretty well in the proposal and elaborated in the discussion.
> > > > > 
> > > > > The question for us is really: is it worth changing? There are costs:
> > > > > - A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand)
> > > > > - new code using the extension doesn't compile with older compilers
> > > > > - all the existing code in the world uses the old convention
> > > > > - etc.
> > > > > 
> > > > > Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.
> > > > > 
> > > > > Personally, the current syntax annoys me almost every day. It's already a small cost on everyone, and I think we need to move forwards even if there are costs in migrating. So, I'm going to recommend that we accept this proposal.
> > > > > 
> > > > > We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?
> > > > > 
> > > > > Cheers
> > > > > Simon
> > > > > 
> > > > > On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > > > > > Dear Committee,
> > > > > > 
> > > > > > this is your secretary speaking:
> > > > > > 
> > > > > > Module qualified syntax
> > > > > > has been proposed by Shayne Fletcher
> > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/190
> > > > > > https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst
> > > > > > 
> > > > > > Simon Marlow has already volunteered to shepherd.
> > > > > > 
> > > > > > Please reach consensus as described in
> > > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > > > > I suggest you make a recommendation, in a new e-mail thread with the
> > > > > > proposal number in the subject, about the decision, maybe point out
> > > > > > debatable points, and assume that anyone who stays quiet agrees with
> > > > > > you.
> > > > > > 
> > > > > > Thanks,
> > > > > > Joachim
> > > > > > -- 
> > > > > > Joachim Breitner
> > > > > > mail at joachim-breitner.de
> > > > > > http://www.joachim-breitner.de/
> > > > > > 
> > > > > > _______________________________________________
> > > > > > ghc-steering-committee mailing list
> > > > > > ghc-steering-committee at haskell.org
> > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > > 
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > ghc-steering-committee at haskell.org
> > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > 
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > 
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> Attachments:
> * signature.asc

From rae at cs.brynmawr.edu  Sat Mar  9 21:10:18 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sat, 9 Mar 2019 16:10:18 -0500
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
 <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
Message-ID: <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>

My argument for `data` is as follows (quoted from earlier writing of mine):

---
Though I understand the reasons against it, I'm an unabashed supporter of using the word "data" to supplant "pattern". My principal argument is that data can be used freely in the syntax, given that it's a keyword that has current meaning only as the first lexeme in a top-level declaration. (Specifically, I pine for a future where types and terms mix. We can then use type and data in the middle of expressions/types to denote namespaces.) It also works nicely to mean "data constructor". I agree that it doesn't work as well with functions or the potential confusion around "data Bool = True | False" (though, in that last example, we can pretend hard that the data applies only to the bits after the =). 
---

In other words, I think `data` is more future-compatible than any of the alternatives, even though I agree that `value` flows more smoothly. We can think of `data` as meaning "data-level", not "data constructor" (though that admittedly takes a bit of mental gymnastics).

Richard

> On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> 
> I think we don't have a consensus on the particular word yet: is it data or value. I'd like to listen to Richard who was strongly in favor of data. We are in agreement about consistency though.
> 
> Vitaly
> 
> 
> On Fri, Mar 8, 2019 at 8:45 PM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> I fully support this (I thought I brought it up before, but maybe not
> strongly enough).
> 
> Should we just include this change in #167? (If politicians can add
> random riders to laws, so can we). Or does it need more thought?
> 
> Cheers,
> Joachim
> 
> 
> Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
> > I also argue that, to be consistent, whatever keyword we agree, we should use it
> > In the (accepted) infix/WARNING proposal
> > In import and export lists – presumably for now in addition to ‘pattern’, though we might end up deprecating the latter.
> > Simon
> >  
> > From: Vitaly Bragilevsky <bravit111 at gmail.com <mailto:bravit111 at gmail.com>> 
> > Sent: 08 March 2019 14:44
> > To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> > Cc: Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>>; ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
> >  
> > Simon PJ argues for "value" over "data" as a specifier: https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193 <https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193>
> >  
> > I'm fine with this choice either (and I'm satisfied with the argument that deprecating or setting fixity for value "value" is a rare case to be considered seriously). If you have another opinion, please, speak up.
> >  
> > Vitaly
> >  
> > On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> > > I’ve made a post on the proposal thread asking why we don’t just follow the already-adopted proposal for WARNING and infix pragmas.
> > >  
> > > Simon
> > >  
> > > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Simon Marlow
> > > Sent: 08 March 2019 07:57
> > > To: Vitaly Bragilevsky <bravit111 at gmail.com <mailto:bravit111 at gmail.com>>
> > > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
> > > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
> > >  
> > > Yes, I think this is the right way to go.
> > >  
> > > Cheers
> > > Simon
> > >  
> > > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com <mailto:bravit111 at gmail.com>> wrote:
> > > > Hi everyone, 
> > > >  
> > > > I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst <https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst>). It is proposed to extend (nonpositional) DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. In its current formulation, the proposal suggests to use the specifiers "type" for type-level things and "pattern" for value-level things as follows:
> > > > 
> > > > data Bar = Bar
> > > > {-# DEPRECATED type Bar "Don't use type Bar" #-} 
> > > > data Baz = Baz
> > > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
> > > > 
> > > > Using this pragma without specifiers should mean deprecating both (as is works now).
> > > >  
> > > > After discussing this proposal within the committee (see https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html <https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html>), I recommend acceptance with one change, namely using "data" instead of "pattern" for deprecating value-level things. 
> > > >  
> > > > Reasons for choosing "data":
> > > > * it's a reserved keyword (as opposed to "value", which is another option)
> > > > * we are deprecating data constructors here
> > > > * it just feels right (sorry!)
> > > >  
> > > > Reasons against "data":
> > > > * it can be confusing whether we mean data type or data constructor
> > > > * we use "value" and "pattern" in other places meaning basically the same thing
> > > >  
> > > > If the committee decides to go this way, then the wider community may think about other proposals, such as
> > > > * adding positional DEPRECATED pragmas (including class instances deprecation)
> > > > * fixing inconsistencies with the fixity declarations (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst>) and updating ExplicitNamespaces in import/export lists
> > > > * deprecating usage of nonpositional DEPRECATED pragma without the specifiers
> > > >  
> > > > Silence is understood as agreement. 
> > > >  
> > > > Regards, 
> > > > Vitaly
> > > > 
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> 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/20190309/2c078604/attachment.html>

From bravit111 at gmail.com  Mon Mar 11 13:12:00 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Mon, 11 Mar 2019 16:12:00 +0300
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
 <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
 <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>
Message-ID: <CALpVSmOy2UgH-3cj_OwO+XdmOxcbMa4Hp99oce8w9UvUDvHggA@mail.gmail.com>

Hi Richard,

Do you think that using "value" now is a real stopper for the future you
are talking about? Maybe we should start thinking about making "value" a
reserved keyword because it suits our purposes best as a namespace
specifier. It looks like this data/value debate is the only issue before
reaching the consensus on this proposal. So we have to do something about
it.

Regards,
Vitaly

On Sun, Mar 10, 2019 at 12:10 AM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> My argument for `data` is as follows (quoted from earlier writing of mine):
>
> ---
> Though I understand the reasons against it, I'm an unabashed supporter of
> using the word "data" to supplant "pattern". My principal argument is that
> data can be used freely in the syntax, given that it's a keyword that has
> current meaning only as the first lexeme in a top-level declaration.
> (Specifically, I pine for a future where types and terms mix. We can then
> use type and data in the middle of expressions/types to denote
> namespaces.) It also works nicely to mean "data constructor". I agree that
> it doesn't work as well with functions or the potential confusion around
> "data Bool = True | False" (though, in that last example, we can pretend
> hard that the data applies only to the bits after the =).
> ---
>
> In other words, I think `data` is more future-compatible than any of the
> alternatives, even though I agree that `value` flows more smoothly. We can
> think of `data` as meaning "data-level", not "data constructor" (though
> that admittedly takes a bit of mental gymnastics).
>
> Richard
>
>
> On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
>
> I think we don't have a consensus on the particular word yet: is it data
> or value. I'd like to listen to Richard who was strongly in favor of data.
> We are in agreement about consistency though.
>
> Vitaly
>
>
> On Fri, Mar 8, 2019 at 8:45 PM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> I fully support this (I thought I brought it up before, but maybe not
>> strongly enough).
>>
>> Should we just include this change in #167? (If politicians can add
>> random riders to laws, so can we). Or does it need more thought?
>>
>> Cheers,
>> Joachim
>>
>>
>> Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via
>> ghc-steering-committee:
>> > I also argue that, to be consistent, whatever keyword we agree, we
>> should use it
>> > In the (accepted) infix/WARNING proposal
>> > In import and export lists – presumably for now in addition to
>> ‘pattern’, though we might end up deprecating the latter.
>> > Simon
>> >
>> > From: Vitaly Bragilevsky <bravit111 at gmail.com>
>> > Sent: 08 March 2019 14:44
>> > To: Simon Peyton Jones <simonpj at microsoft.com>
>> > Cc: Simon Marlow <marlowsd at gmail.com>; ghc-steering-committee <
>> ghc-steering-committee at haskell.org>
>> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
>> accept
>> >
>> > Simon PJ argues for "value" over "data" as a specifier:
>> https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193
>> >
>> > I'm fine with this choice either (and I'm satisfied with the argument
>> that deprecating or setting fixity for value "value" is a rare case to be
>> considered seriously). If you have another opinion, please, speak up.
>> >
>> > Vitaly
>> >
>> > On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <
>> simonpj at microsoft.com> wrote:
>> > > I’ve made a post on the proposal thread asking why we don’t just
>> follow the already-adopted proposal for WARNING and infix pragmas.
>> > >
>> > > Simon
>> > >
>> > > From: ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
>> > > Sent: 08 March 2019 07:57
>> > > To: Vitaly Bragilevsky <bravit111 at gmail.com>
>> > > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
>> > > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
>> accept
>> > >
>> > > Yes, I think this is the right way to go.
>> > >
>> > > Cheers
>> > > Simon
>> > >
>> > > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com>
>> wrote:
>> > > > Hi everyone,
>> > > >
>> > > > I was asked to shepherd the proposal #167 (Deprecated Entities,
>> https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst).
>> It is proposed to extend (nonpositional) DEPRECATED pragma with the two
>> specifiers to disambiguate deprecating named type-level and value-level
>> things. In its current formulation, the proposal suggests to use the
>> specifiers "type" for type-level things and "pattern" for value-level
>> things as follows:
>> > > >
>> > > > data Bar = Bar
>> > > > {-# DEPRECATED type Bar "Don't use type Bar" #-}
>> > > > data Baz = Baz
>> > > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
>> > > >
>> > > > Using this pragma without specifiers should mean deprecating both
>> (as is works now).
>> > > >
>> > > > After discussing this proposal within the committee (see
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html),
>> I recommend acceptance with one change, namely using "data" instead of
>> "pattern" for deprecating value-level things.
>> > > >
>> > > > Reasons for choosing "data":
>> > > > * it's a reserved keyword (as opposed to "value", which is another
>> option)
>> > > > * we are deprecating data constructors here
>> > > > * it just feels right (sorry!)
>> > > >
>> > > > Reasons against "data":
>> > > > * it can be confusing whether we mean data type or data constructor
>> > > > * we use "value" and "pattern" in other places meaning basically
>> the same thing
>> > > >
>> > > > If the committee decides to go this way, then the wider community
>> may think about other proposals, such as
>> > > > * adding positional DEPRECATED pragmas (including class instances
>> deprecation)
>> > > > * fixing inconsistencies with the fixity declarations (
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst)
>> and updating ExplicitNamespaces in import/export lists
>> > > > * deprecating usage of nonpositional DEPRECATED pragma without the
>> specifiers
>> > > >
>> > > > Silence is understood as agreement.
>> > > >
>> > > > Regards,
>> > > > Vitaly
>> > > >
>> > > > _______________________________________________
>> > > > ghc-steering-committee mailing list
>> > > > ghc-steering-committee at haskell.org
>> > > >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20190311/1a7bb222/attachment.html>

From rae at cs.brynmawr.edu  Mon Mar 11 13:26:20 2019
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 11 Mar 2019 09:26:20 -0400
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <CALpVSmOy2UgH-3cj_OwO+XdmOxcbMa4Hp99oce8w9UvUDvHggA@mail.gmail.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
 <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
 <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>
 <CALpVSmOy2UgH-3cj_OwO+XdmOxcbMa4Hp99oce8w9UvUDvHggA@mail.gmail.com>
Message-ID: <A2C6D022-99AD-4C72-937E-F4B946374A1C@cs.brynmawr.edu>

"value" would not work as the namespace indicator I envision for the future, as it's a commonly used variable name. (I would advocate against making it a keyword for this reason.) This knob is relatively easy to turn, though, so it's conceivable to use "value" today, and then if/when we start using "data" in the future, allow the use of "data" where we use "value", eventually deprecating and removing "value". It's a bit annoying to users to keep changing it, but only a bit. I've been in this game long enough to know that the future isn't quite predictable, and so I see the sense in choosing the best thing for us now, leaving the door open to fixing it later if necessary. I still advocate for "data", but I won't burst into tears if we choose "value".

I could see waiting a day or two for further commentary and then putting it to a committee vote. In the end, I think this choice matters little.

Richard

> On Mar 11, 2019, at 9:12 AM, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> 
> Hi Richard, 
> 
> Do you think that using "value" now is a real stopper for the future you are talking about? Maybe we should start thinking about making "value" a reserved keyword because it suits our purposes best as a namespace specifier. It looks like this data/value debate is the only issue before reaching the consensus on this proposal. So we have to do something about it.
> 
> Regards, 
> Vitaly
> 
> On Sun, Mar 10, 2019 at 12:10 AM Richard Eisenberg <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> wrote:
> My argument for `data` is as follows (quoted from earlier writing of mine):
> 
> ---
> Though I understand the reasons against it, I'm an unabashed supporter of using the word "data" to supplant "pattern". My principal argument is that data can be used freely in the syntax, given that it's a keyword that has current meaning only as the first lexeme in a top-level declaration. (Specifically, I pine for a future where types and terms mix. We can then use type and data in the middle of expressions/types to denote namespaces.) It also works nicely to mean "data constructor". I agree that it doesn't work as well with functions or the potential confusion around "data Bool = True | False" (though, in that last example, we can pretend hard that the data applies only to the bits after the =). 
> ---
> 
> In other words, I think `data` is more future-compatible than any of the alternatives, even though I agree that `value` flows more smoothly. We can think of `data` as meaning "data-level", not "data constructor" (though that admittedly takes a bit of mental gymnastics).
> 
> Richard
> 
> 
>> On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <bravit111 at gmail.com <mailto:bravit111 at gmail.com>> wrote:
>> 
>> I think we don't have a consensus on the particular word yet: is it data or value. I'd like to listen to Richard who was strongly in favor of data. We are in agreement about consistency though.
>> 
>> Vitaly
>> 
>> 
>> On Fri, Mar 8, 2019 at 8:45 PM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>> Hi,
>> 
>> I fully support this (I thought I brought it up before, but maybe not
>> strongly enough).
>> 
>> Should we just include this change in #167? (If politicians can add
>> random riders to laws, so can we). Or does it need more thought?
>> 
>> Cheers,
>> Joachim
>> 
>> 
>> Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via
>> ghc-steering-committee:
>> > I also argue that, to be consistent, whatever keyword we agree, we should use it
>> > In the (accepted) infix/WARNING proposal
>> > In import and export lists – presumably for now in addition to ‘pattern’, though we might end up deprecating the latter.
>> > Simon
>> >  
>> > From: Vitaly Bragilevsky <bravit111 at gmail.com <mailto:bravit111 at gmail.com>> 
>> > Sent: 08 March 2019 14:44
>> > To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
>> > Cc: Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>>; ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
>> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
>> >  
>> > Simon PJ argues for "value" over "data" as a specifier: https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193 <https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193>
>> >  
>> > I'm fine with this choice either (and I'm satisfied with the argument that deprecating or setting fixity for value "value" is a rare case to be considered seriously). If you have another opinion, please, speak up.
>> >  
>> > Vitaly
>> >  
>> > On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
>> > > I’ve made a post on the proposal thread asking why we don’t just follow the already-adopted proposal for WARNING and infix pragmas.
>> > >  
>> > > Simon
>> > >  
>> > > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Simon Marlow
>> > > Sent: 08 March 2019 07:57
>> > > To: Vitaly Bragilevsky <bravit111 at gmail.com <mailto:bravit111 at gmail.com>>
>> > > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>
>> > > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
>> > >  
>> > > Yes, I think this is the right way to go.
>> > >  
>> > > Cheers
>> > > Simon
>> > >  
>> > > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com <mailto:bravit111 at gmail.com>> wrote:
>> > > > Hi everyone, 
>> > > >  
>> > > > I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst <https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst>). It is proposed to extend (nonpositional) DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. In its current formulation, the proposal suggests to use the specifiers "type" for type-level things and "pattern" for value-level things as follows:
>> > > > 
>> > > > data Bar = Bar
>> > > > {-# DEPRECATED type Bar "Don't use type Bar" #-} 
>> > > > data Baz = Baz
>> > > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
>> > > > 
>> > > > Using this pragma without specifiers should mean deprecating both (as is works now).
>> > > >  
>> > > > After discussing this proposal within the committee (see https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html <https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html>), I recommend acceptance with one change, namely using "data" instead of "pattern" for deprecating value-level things. 
>> > > >  
>> > > > Reasons for choosing "data":
>> > > > * it's a reserved keyword (as opposed to "value", which is another option)
>> > > > * we are deprecating data constructors here
>> > > > * it just feels right (sorry!)
>> > > >  
>> > > > Reasons against "data":
>> > > > * it can be confusing whether we mean data type or data constructor
>> > > > * we use "value" and "pattern" in other places meaning basically the same thing
>> > > >  
>> > > > If the committee decides to go this way, then the wider community may think about other proposals, such as
>> > > > * adding positional DEPRECATED pragmas (including class instances deprecation)
>> > > > * fixing inconsistencies with the fixity declarations (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst>) and updating ExplicitNamespaces in import/export lists
>> > > > * deprecating usage of nonpositional DEPRECATED pragma without the specifiers
>> > > >  
>> > > > Silence is understood as agreement. 
>> > > >  
>> > > > Regards, 
>> > > > Vitaly
>> > > > 
>> > > > _______________________________________________
>> > > > ghc-steering-committee mailing list
>> > > > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> > 
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> -- 
>> Joachim Breitner
>>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/20190311/020f2666/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue Mar 12 17:00:50 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 12 Mar 2019 10:00:50 -0700
Subject: [ghc-steering-committee] Proposal #204: shelve for the moment
Message-ID: <CAGK9nupwHrU_7+BLuowP1K33uuk65Zr5iJV7fOa55HEbvNWpEA@mail.gmail.com>

Hello,

I am the shepherd for #204 "Remove nested bracket restriction in Template
Haskell" [1].

After some more discussion with Matt on the git-hub thread, it seems that
there are some issues related to lifting values across multiple stages, so
it seems better to shelve this for the moment, until those and some related
TH proposals are worked out.

-Iavor


[1] https://github.com/ghc-proposals/ghc-proposals/pull/204
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190312/a33dad39/attachment.html>

From mail at joachim-breitner.de  Wed Mar 13 07:37:14 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 13 Mar 2019 08:37:14 +0100
Subject: [ghc-steering-committee] Proposal #204: shelve for the moment
In-Reply-To: <CAGK9nupwHrU_7+BLuowP1K33uuk65Zr5iJV7fOa55HEbvNWpEA@mail.gmail.com>
References: <CAGK9nupwHrU_7+BLuowP1K33uuk65Zr5iJV7fOa55HEbvNWpEA@mail.gmail.com>
Message-ID: <07d2c8c49b8cea16ea20c482ead701e6685220e8.camel@joachim-breitner.de>

Hi,

sure. I suggest you change the label to “Needs Revision”.

Cheers,
Joachim

Am Dienstag, den 12.03.2019, 10:00 -0700 schrieb Iavor Diatchki:
> Hello,
> 
> I am the shepherd for #204 "Remove nested bracket restriction in Template Haskell" [1].
> 
> After some more discussion with Matt on the git-hub thread, it seems that there are some issues related to lifting values across multiple stages, so it seems better to shelve this for the moment, until those and some related TH proposals are worked out.
> 
> -Iavor
> 
> 
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/204
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190313/d5ae2cc7/attachment.sig>

From marlowsd at gmail.com  Wed Mar 13 13:35:11 2019
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 13 Mar 2019 13:35:11 +0000
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <A2C6D022-99AD-4C72-937E-F4B946374A1C@cs.brynmawr.edu>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
 <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
 <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>
 <CALpVSmOy2UgH-3cj_OwO+XdmOxcbMa4Hp99oce8w9UvUDvHggA@mail.gmail.com>
 <A2C6D022-99AD-4C72-937E-F4B946374A1C@cs.brynmawr.edu>
Message-ID: <CANsrgP+tsNNbttzdyC_7aoojjj_g-PDOFkSMBOafdRAJYiu8aw@mail.gmail.com>

On Mon, 11 Mar 2019 at 13:26, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:

> "value" would not work as the namespace indicator I envision for the
> future, as it's a commonly used variable name. (I would advocate against
> making it a keyword for this reason.) This knob is relatively easy to turn,
> though, so it's conceivable to use "value" today, and then if/when we start
> using "data" in the future, allow the use of "data" where we use "value",
> eventually deprecating and removing "value". It's a bit annoying to users
> to keep changing it, but only a bit. I've been in this game long enough to
> know that the future isn't quite predictable, and so I see the sense in
> choosing the best thing for us now, leaving the door open to fixing it
> later if necessary. I still advocate for "data", but I won't burst into
> tears if we choose "value".
>
> I could see waiting a day or two for further commentary and then putting
> it to a committee vote. In the end, I think this choice matters little.
>


For those who (like me) might have been a bit confused about the current
state of things:

   - There are 5 places that we want namespace specifiers now (possibly
   more later): import, export, fixity, WARNING, DEPRECATED
   - GHC's existing *ExplicitNamespaces* option allows *type* and *pattern*
   keywords to be used in import, export
   - The earlier proposal Require namespacing fixity declarations for type
   names and WARNING/DEPRECATED pragmas
   <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst>
   was accepted, and allows *type* and *value* keywords in fixity, WARNING,
   DEPRECATED
   - This proposal Deprecated Entities
   <https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst>
   suggests adding *type* and *pattern* specifiers to DEPRECATED pragmas.
   (note that DEPRECATED pragmas were covered by the earlier proposal, so this
   conflicts)
   - Vitaly's suggested modification of this proposal is to  adopt *type*
   and *data* instead (for DEPRECATED pragmas), while Simon pointed out
   that we already accepted a proposal for this, using *type* and *value*,
   and that whatever we do we should do it consistently across import, export,
   fixity, WARNING, DEPRECATED (yes!)

I don't think it makes a lot of sense to accept this proposal, since it
conflicts with the earlier one. Should we instead work on a modification of
the earlier proposal to extend it to import/export lists, and also resolve
the debate about *data/pattern/value*?

Richard's concerns about future extensions to add namespacing in
expressions seem valid to me, it would be unfortunate to use *value* now if
that will cause problems later.

Cheers
Simon



> Richard
>
> On Mar 11, 2019, at 9:12 AM, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
>
> Hi Richard,
>
> Do you think that using "value" now is a real stopper for the future you
> are talking about? Maybe we should start thinking about making "value" a
> reserved keyword because it suits our purposes best as a namespace
> specifier. It looks like this data/value debate is the only issue before
> reaching the consensus on this proposal. So we have to do something about
> it.
>
> Regards,
> Vitaly
>
> On Sun, Mar 10, 2019 at 12:10 AM Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
>> My argument for `data` is as follows (quoted from earlier writing of
>> mine):
>>
>> ---
>> Though I understand the reasons against it, I'm an unabashed supporter of
>> using the word "data" to supplant "pattern". My principal argument is that
>> data can be used freely in the syntax, given that it's a keyword that
>> has current meaning only as the first lexeme in a top-level declaration.
>> (Specifically, I pine for a future where types and terms mix. We can then
>> use type and data in the middle of expressions/types to denote
>> namespaces.) It also works nicely to mean "data constructor". I agree that
>> it doesn't work as well with functions or the potential confusion around
>> "data Bool = True | False" (though, in that last example, we can pretend
>> hard that the data applies only to the bits after the =).
>> ---
>>
>> In other words, I think `data` is more future-compatible than any of the
>> alternatives, even though I agree that `value` flows more smoothly. We can
>> think of `data` as meaning "data-level", not "data constructor" (though
>> that admittedly takes a bit of mental gymnastics).
>>
>> Richard
>>
>>
>> On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <bravit111 at gmail.com>
>> wrote:
>>
>> I think we don't have a consensus on the particular word yet: is it data
>> or value. I'd like to listen to Richard who was strongly in favor of data.
>> We are in agreement about consistency though.
>>
>> Vitaly
>>
>>
>> On Fri, Mar 8, 2019 at 8:45 PM Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>>> Hi,
>>>
>>> I fully support this (I thought I brought it up before, but maybe not
>>> strongly enough).
>>>
>>> Should we just include this change in #167? (If politicians can add
>>> random riders to laws, so can we). Or does it need more thought?
>>>
>>> Cheers,
>>> Joachim
>>>
>>>
>>> Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via
>>> ghc-steering-committee:
>>> > I also argue that, to be consistent, whatever keyword we agree, we
>>> should use it
>>> > In the (accepted) infix/WARNING proposal
>>> > In import and export lists – presumably for now in addition to
>>> ‘pattern’, though we might end up deprecating the latter.
>>> > Simon
>>> >
>>> > From: Vitaly Bragilevsky <bravit111 at gmail.com>
>>> > Sent: 08 March 2019 14:44
>>> > To: Simon Peyton Jones <simonpj at microsoft.com>
>>> > Cc: Simon Marlow <marlowsd at gmail.com>; ghc-steering-committee <
>>> ghc-steering-committee at haskell.org>
>>> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
>>> accept
>>> >
>>> > Simon PJ argues for "value" over "data" as a specifier:
>>> https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193
>>> >
>>> > I'm fine with this choice either (and I'm satisfied with the argument
>>> that deprecating or setting fixity for value "value" is a rare case to be
>>> considered seriously). If you have another opinion, please, speak up.
>>> >
>>> > Vitaly
>>> >
>>> > On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <
>>> simonpj at microsoft.com> wrote:
>>> > > I’ve made a post on the proposal thread asking why we don’t just
>>> follow the already-adopted proposal for WARNING and infix pragmas.
>>> > >
>>> > > Simon
>>> > >
>>> > > From: ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
>>> > > Sent: 08 March 2019 07:57
>>> > > To: Vitaly Bragilevsky <bravit111 at gmail.com>
>>> > > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
>>> > > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities,
>>> rec: accept
>>> > >
>>> > > Yes, I think this is the right way to go.
>>> > >
>>> > > Cheers
>>> > > Simon
>>> > >
>>> > > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com>
>>> wrote:
>>> > > > Hi everyone,
>>> > > >
>>> > > > I was asked to shepherd the proposal #167 (Deprecated Entities,
>>> https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst).
>>> It is proposed to extend (nonpositional) DEPRECATED pragma with the two
>>> specifiers to disambiguate deprecating named type-level and value-level
>>> things. In its current formulation, the proposal suggests to use the
>>> specifiers "type" for type-level things and "pattern" for value-level
>>> things as follows:
>>> > > >
>>> > > > data Bar = Bar
>>> > > > {-# DEPRECATED type Bar "Don't use type Bar" #-}
>>> > > > data Baz = Baz
>>> > > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
>>> > > >
>>> > > > Using this pragma without specifiers should mean deprecating both
>>> (as is works now).
>>> > > >
>>> > > > After discussing this proposal within the committee (see
>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html),
>>> I recommend acceptance with one change, namely using "data" instead of
>>> "pattern" for deprecating value-level things.
>>> > > >
>>> > > > Reasons for choosing "data":
>>> > > > * it's a reserved keyword (as opposed to "value", which is another
>>> option)
>>> > > > * we are deprecating data constructors here
>>> > > > * it just feels right (sorry!)
>>> > > >
>>> > > > Reasons against "data":
>>> > > > * it can be confusing whether we mean data type or data constructor
>>> > > > * we use "value" and "pattern" in other places meaning basically
>>> the same thing
>>> > > >
>>> > > > If the committee decides to go this way, then the wider community
>>> may think about other proposals, such as
>>> > > > * adding positional DEPRECATED pragmas (including class instances
>>> deprecation)
>>> > > > * fixing inconsistencies with the fixity declarations (
>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst)
>>> and updating ExplicitNamespaces in import/export lists
>>> > > > * deprecating usage of nonpositional DEPRECATED pragma without the
>>> specifiers
>>> > > >
>>> > > > Silence is understood as agreement.
>>> > > >
>>> > > > Regards,
>>> > > > Vitaly
>>> > > >
>>> > > > _______________________________________________
>>> > > > ghc-steering-committee mailing list
>>> > > > ghc-steering-committee at haskell.org
>>> > > >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> >
>>> > _______________________________________________
>>> > ghc-steering-committee mailing list
>>> > ghc-steering-committee at haskell.org
>>> >
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>>
> _______________________________________________
> 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/20190313/baf7c6f5/attachment-0001.html>

From bravit111 at gmail.com  Wed Mar 13 15:57:38 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Wed, 13 Mar 2019 18:57:38 +0300
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <CANsrgP+tsNNbttzdyC_7aoojjj_g-PDOFkSMBOafdRAJYiu8aw@mail.gmail.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
 <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
 <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>
 <CALpVSmOy2UgH-3cj_OwO+XdmOxcbMa4Hp99oce8w9UvUDvHggA@mail.gmail.com>
 <A2C6D022-99AD-4C72-937E-F4B946374A1C@cs.brynmawr.edu>
 <CANsrgP+tsNNbttzdyC_7aoojjj_g-PDOFkSMBOafdRAJYiu8aw@mail.gmail.com>
Message-ID: <CALpVSmNjiD-2-8Hr9mfKNkcpUB1qidyJwqxpFFs_FL3HqzjbvA@mail.gmail.com>

Thank you for this summary, Simon. I didn't realize that the earlier
proposal Require namespacing fixity declarations for type names and
WARNING/DEPRECATED pragmas
<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst>
affects
DEPRECATED pragmas. They were mentioned in the title but they were not
mentioned in the proposed changes. Now I see in the Motivation section that
«*as well as DEPRECATED pragmas, which accomplish the same thing, so I'll
refer to them henceforth as just WARNING pragmas*».

Joachim, I'm not sure how to proceed here. I don't think that this is the
case for "Needs Revision". I could start another thread with the
recommendation to reject this proposal with the reason that another
(accepted) proposal subsumes this one but it doesn't make too much sense
either.

Vitaly


On Wed, Mar 13, 2019 at 4:35 PM Simon Marlow <marlowsd at gmail.com> wrote:

> On Mon, 11 Mar 2019 at 13:26, Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
>> "value" would not work as the namespace indicator I envision for the
>> future, as it's a commonly used variable name. (I would advocate against
>> making it a keyword for this reason.) This knob is relatively easy to turn,
>> though, so it's conceivable to use "value" today, and then if/when we start
>> using "data" in the future, allow the use of "data" where we use "value",
>> eventually deprecating and removing "value". It's a bit annoying to users
>> to keep changing it, but only a bit. I've been in this game long enough to
>> know that the future isn't quite predictable, and so I see the sense in
>> choosing the best thing for us now, leaving the door open to fixing it
>> later if necessary. I still advocate for "data", but I won't burst into
>> tears if we choose "value".
>>
>> I could see waiting a day or two for further commentary and then putting
>> it to a committee vote. In the end, I think this choice matters little.
>>
>
>
> For those who (like me) might have been a bit confused about the current
> state of things:
>
>    - There are 5 places that we want namespace specifiers now (possibly
>    more later): import, export, fixity, WARNING, DEPRECATED
>    - GHC's existing *ExplicitNamespaces* option allows *type* and
>    *pattern* keywords to be used in import, export
>    - The earlier proposal Require namespacing fixity declarations for
>    type names and WARNING/DEPRECATED pragmas
>    <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst>
>    was accepted, and allows *type* and *value* keywords in fixity,
>    WARNING, DEPRECATED
>    - This proposal Deprecated Entities
>    <https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst>
>    suggests adding *type* and *pattern* specifiers to DEPRECATED pragmas.
>    (note that DEPRECATED pragmas were covered by the earlier proposal, so this
>    conflicts)
>    - Vitaly's suggested modification of this proposal is to  adopt *type*
>    and *data* instead (for DEPRECATED pragmas), while Simon pointed out
>    that we already accepted a proposal for this, using *type* and *value*,
>    and that whatever we do we should do it consistently across import, export,
>    fixity, WARNING, DEPRECATED (yes!)
>
> I don't think it makes a lot of sense to accept this proposal, since it
> conflicts with the earlier one. Should we instead work on a modification of
> the earlier proposal to extend it to import/export lists, and also resolve
> the debate about *data/pattern/value*?
>
> Richard's concerns about future extensions to add namespacing in
> expressions seem valid to me, it would be unfortunate to use *value* now
> if that will cause problems later.
>
> Cheers
> Simon
>
>
>
>> Richard
>>
>> On Mar 11, 2019, at 9:12 AM, Vitaly Bragilevsky <bravit111 at gmail.com>
>> wrote:
>>
>> Hi Richard,
>>
>> Do you think that using "value" now is a real stopper for the future you
>> are talking about? Maybe we should start thinking about making "value" a
>> reserved keyword because it suits our purposes best as a namespace
>> specifier. It looks like this data/value debate is the only issue before
>> reaching the consensus on this proposal. So we have to do something about
>> it.
>>
>> Regards,
>> Vitaly
>>
>> On Sun, Mar 10, 2019 at 12:10 AM Richard Eisenberg <rae at cs.brynmawr.edu>
>> wrote:
>>
>>> My argument for `data` is as follows (quoted from earlier writing of
>>> mine):
>>>
>>> ---
>>> Though I understand the reasons against it, I'm an unabashed supporter
>>> of using the word "data" to supplant "pattern". My principal argument is
>>> that data can be used freely in the syntax, given that it's a keyword
>>> that has current meaning only as the first lexeme in a top-level
>>> declaration. (Specifically, I pine for a future where types and terms mix.
>>> We can then use type and data in the middle of expressions/types to
>>> denote namespaces.) It also works nicely to mean "data constructor". I
>>> agree that it doesn't work as well with functions or the potential
>>> confusion around "data Bool = True | False" (though, in that last example,
>>> we can pretend hard that the data applies only to the bits after the =
>>> ).
>>> ---
>>>
>>> In other words, I think `data` is more future-compatible than any of the
>>> alternatives, even though I agree that `value` flows more smoothly. We can
>>> think of `data` as meaning "data-level", not "data constructor" (though
>>> that admittedly takes a bit of mental gymnastics).
>>>
>>> Richard
>>>
>>>
>>> On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <bravit111 at gmail.com>
>>> wrote:
>>>
>>> I think we don't have a consensus on the particular word yet: is it data
>>> or value. I'd like to listen to Richard who was strongly in favor of data.
>>> We are in agreement about consistency though.
>>>
>>> Vitaly
>>>
>>>
>>> On Fri, Mar 8, 2019 at 8:45 PM Joachim Breitner <
>>> mail at joachim-breitner.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> I fully support this (I thought I brought it up before, but maybe not
>>>> strongly enough).
>>>>
>>>> Should we just include this change in #167? (If politicians can add
>>>> random riders to laws, so can we). Or does it need more thought?
>>>>
>>>> Cheers,
>>>> Joachim
>>>>
>>>>
>>>> Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via
>>>> ghc-steering-committee:
>>>> > I also argue that, to be consistent, whatever keyword we agree, we
>>>> should use it
>>>> > In the (accepted) infix/WARNING proposal
>>>> > In import and export lists – presumably for now in addition to
>>>> ‘pattern’, though we might end up deprecating the latter.
>>>> > Simon
>>>> >
>>>> > From: Vitaly Bragilevsky <bravit111 at gmail.com>
>>>> > Sent: 08 March 2019 14:44
>>>> > To: Simon Peyton Jones <simonpj at microsoft.com>
>>>> > Cc: Simon Marlow <marlowsd at gmail.com>; ghc-steering-committee <
>>>> ghc-steering-committee at haskell.org>
>>>> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
>>>> accept
>>>> >
>>>> > Simon PJ argues for "value" over "data" as a specifier:
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193
>>>> >
>>>> > I'm fine with this choice either (and I'm satisfied with the argument
>>>> that deprecating or setting fixity for value "value" is a rare case to be
>>>> considered seriously). If you have another opinion, please, speak up.
>>>> >
>>>> > Vitaly
>>>> >
>>>> > On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <
>>>> simonpj at microsoft.com> wrote:
>>>> > > I’ve made a post on the proposal thread asking why we don’t just
>>>> follow the already-adopted proposal for WARNING and infix pragmas.
>>>> > >
>>>> > > Simon
>>>> > >
>>>> > > From: ghc-steering-committee <
>>>> ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
>>>> > > Sent: 08 March 2019 07:57
>>>> > > To: Vitaly Bragilevsky <bravit111 at gmail.com>
>>>> > > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
>>>> > > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities,
>>>> rec: accept
>>>> > >
>>>> > > Yes, I think this is the right way to go.
>>>> > >
>>>> > > Cheers
>>>> > > Simon
>>>> > >
>>>> > > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <
>>>> bravit111 at gmail.com> wrote:
>>>> > > > Hi everyone,
>>>> > > >
>>>> > > > I was asked to shepherd the proposal #167 (Deprecated Entities,
>>>> https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst).
>>>> It is proposed to extend (nonpositional) DEPRECATED pragma with the two
>>>> specifiers to disambiguate deprecating named type-level and value-level
>>>> things. In its current formulation, the proposal suggests to use the
>>>> specifiers "type" for type-level things and "pattern" for value-level
>>>> things as follows:
>>>> > > >
>>>> > > > data Bar = Bar
>>>> > > > {-# DEPRECATED type Bar "Don't use type Bar" #-}
>>>> > > > data Baz = Baz
>>>> > > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
>>>> > > >
>>>> > > > Using this pragma without specifiers should mean deprecating both
>>>> (as is works now).
>>>> > > >
>>>> > > > After discussing this proposal within the committee (see
>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html),
>>>> I recommend acceptance with one change, namely using "data" instead of
>>>> "pattern" for deprecating value-level things.
>>>> > > >
>>>> > > > Reasons for choosing "data":
>>>> > > > * it's a reserved keyword (as opposed to "value", which is
>>>> another option)
>>>> > > > * we are deprecating data constructors here
>>>> > > > * it just feels right (sorry!)
>>>> > > >
>>>> > > > Reasons against "data":
>>>> > > > * it can be confusing whether we mean data type or data
>>>> constructor
>>>> > > > * we use "value" and "pattern" in other places meaning basically
>>>> the same thing
>>>> > > >
>>>> > > > If the committee decides to go this way, then the wider community
>>>> may think about other proposals, such as
>>>> > > > * adding positional DEPRECATED pragmas (including class instances
>>>> deprecation)
>>>> > > > * fixing inconsistencies with the fixity declarations (
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst)
>>>> and updating ExplicitNamespaces in import/export lists
>>>> > > > * deprecating usage of nonpositional DEPRECATED pragma without
>>>> the specifiers
>>>> > > >
>>>> > > > Silence is understood as agreement.
>>>> > > >
>>>> > > > Regards,
>>>> > > > Vitaly
>>>> > > >
>>>> > > > _______________________________________________
>>>> > > > ghc-steering-committee mailing list
>>>> > > > ghc-steering-committee at haskell.org
>>>> > > >
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> >
>>>> > _______________________________________________
>>>> > ghc-steering-committee mailing list
>>>> > ghc-steering-committee at haskell.org
>>>> >
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> --
>>>> Joachim Breitner
>>>>   mail at joachim-breitner.de
>>>>   http://www.joachim-breitner.de/
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>>
>>>
>> _______________________________________________
>> 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/20190313/84e6bcc5/attachment-0001.html>

From mail at joachim-breitner.de  Wed Mar 13 16:26:53 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 13 Mar 2019 17:26:53 +0100
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <CALpVSmNjiD-2-8Hr9mfKNkcpUB1qidyJwqxpFFs_FL3HqzjbvA@mail.gmail.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
 <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
 <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>
 <CALpVSmOy2UgH-3cj_OwO+XdmOxcbMa4Hp99oce8w9UvUDvHggA@mail.gmail.com>
 <A2C6D022-99AD-4C72-937E-F4B946374A1C@cs.brynmawr.edu>
 <CANsrgP+tsNNbttzdyC_7aoojjj_g-PDOFkSMBOafdRAJYiu8aw@mail.gmail.com>
 <CALpVSmNjiD-2-8Hr9mfKNkcpUB1qidyJwqxpFFs_FL3HqzjbvA@mail.gmail.com>
Message-ID: <0189fe7f6c67a36d5b930904b4c1ec7a6c5b2be8.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 13.03.2019, 18:57 +0300 schrieb Vitaly Bragilevsky:
> Joachim, I'm not sure how to proceed here. I don't think that this is
> the case for "Needs Revision". I could start another thread with the
> recommendation to reject this proposal with the reason that another
> (accepted) proposal subsumes this one but it doesn't make too much
> sense either.

well, it seems that there is some clean-up to do. We can say “Needs
revision” and ask the authors (maybe with your help) to turn this
proposal into one that addresses all the points, maybe subsuming prior
proposals along the way.

But that is not much different than rejecting this and drafting a new
one. So maybe the latter is cleaner.

The more important question is: Who wants to do that “grand unifying
ExplicitNamespaces proposal”?


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190313/cd201f51/attachment.sig>

From mail at joachim-breitner.de  Thu Mar 14 14:47:27 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 14 Mar 2019 15:47:27 +0100
Subject: [ghc-steering-committee] #179: Tweak the printing of foralls,
	recommendation: accept
In-Reply-To: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
Message-ID: <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>

Dear Committee,

Richard, in collarboration with Simon PJ, proposes some tweaks to how
foralls are printed by GHC.

In particular, whenever a type variable is printed with an forall, it
is printed with {a} unless it is a specified variable. And there are
tweaks to what :type does with its argument that makes it more useful,
and obviates the need for a separate :type +v.
https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst

I like that it actually simplifies the UI (by removing :type +v), so I
recommend acceptance.

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190314/d061ae42/attachment.sig>

From mail at joachim-breitner.de  Thu Mar 14 14:48:01 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 14 Mar 2019 15:48:01 +0100
Subject: [ghc-steering-committee] #210: -Wredundant-minimal-methods,
 recommendation: accept
In-Reply-To: <DB7PR83MB0298A6E86B49C3742542FCE0AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <f78f9f59bda00c7d08fa3a7c35b8f02223e01d31.camel@joachim-breitner.de>
 <DB7PR83MB0298A6E86B49C3742542FCE0AD710@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <9d68d5872bc855d5546285132bb9e0f799b99a1b.camel@joachim-breitner.de>

Hi,

great, I’ll marks this as accepted, with "-Wredundant-minimal-methods".

Cheers,
Joachim

Am Montag, den 04.03.2019, 11:41 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> I'm happy to support this.  And yes 
> 
> Simon
> 
> > -----Original Message-----
> > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> > On Behalf Of Joachim Breitner
> > Sent: 02 March 2019 16:17
> > To: ghc-steering-committee at haskell.org
> > Subject: [ghc-steering-committee] #210: -Wredundant-minimal-methods,
> > recommendation: accept
> > 
> > Dear Committee,
> > 
> > Levent Erkök has proposed to introduce a warning when a type class
> > specifies a methods as definitely requires (via a MINIMAL pragma), but
> > still gives a default implementation:
> > https://github.com/LeventErkok/ghc-proposals/blob/master/proposals/0000-
> > minimal-should-warn-extras.rst
> > 
> > This seems both useful and and harmless to me, so I propose we accept
> > the proposal.
> > 
> > If we want to do some bike shedding: I think
> >    -Wredundant-minimal-methods
> > has a better flow than the proposed
> >    -Wminimal-redundant-methods
> > After all, we want to be warned about redundancy of minimal methods,
> > not minimality of redundant methods.
> > 
> > Cheers,
> > Simon
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190314/0b98b76e/attachment.sig>

From rae at richarde.dev  Thu Mar 14 19:29:46 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 14 Mar 2019 15:29:46 -0400
Subject: [ghc-steering-committee] Proposal #209: Levity polymorphic
 lift. Recommendation: accept
In-Reply-To: <bff01274-4e9b-4c34-bd39-680cb9053916@www.fastmail.com>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
 <DB7PR83MB029819400A9669497730E074AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7d0c15f7-06ec-4a0a-bbb8-faa1907f661d@www.fastmail.com>
 <DB7PR83MB0298EE7DFE19DEB0961B343BAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAGK9nupp7A5nJ=q3arxCCUSTQgMM+W33XcpSGgtSzso93VDO=Q@mail.gmail.com>
 <C0491A7D-5451-4E19-B270-A97659AE0074@cs.brynmawr.edu>
 <bff01274-4e9b-4c34-bd39-680cb9053916@www.fastmail.com>
Message-ID: <8A88C4A9-3077-44E6-A9E9-D4C7CF0313F5@richarde.dev>



> On Mar 7, 2019, at 10:27 PM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> 
> I imagine we could get away with
> 
> default liftTyped :: (r ~ 'LiftedRep, Data t) => t -> Q (TExp t)
> liftTyped = unsafeTExpCoerce . liftData

Sadly, this won't work. GHC just isn't clever enough. The problem is that, for (Data t) to be well-typed, we need (r ~ LiftedRep). This means that the typedness of one constraint depends on another. The internal language can do this fine, but type inference isn't up to the challenge. We'll get there some day. But I think this way is a dead-end for now.

So it sounds (to me) that the best way forward is to remove the default implementation of liftTyped altogether....

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190314/2b92e9d5/attachment.html>

From iavor.diatchki at gmail.com  Thu Mar 14 22:18:48 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 14 Mar 2019 15:18:48 -0700
Subject: [ghc-steering-committee] #179: Tweak the printing of foralls,
 recommendation: accept
In-Reply-To: <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>
Message-ID: <CAGK9nuqVMje8Z+HKgz6OD8HpW4c3zZmWRjgKX5J2YbcKKj57tQ@mail.gmail.com>

Overall I am all for simplifying this stuff, but the bit where constraints
with no variables are not simplified seems quite confusing.   More
concretely, using the example from the proposal:

bar :: forall a b. (a ~ Int) => a -> b -> a

Is it the case that `:t bar @Bool` will print

bar :: (Bool ~ Int) => Bool -> b -> Bool

This looks particularly confusing without the explicit `forall`, although
it seems questionable either way.

-Iavor



On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> Richard, in collarboration with Simon PJ, proposes some tweaks to how
> foralls are printed by GHC.
>
> In particular, whenever a type variable is printed with an forall, it
> is printed with {a} unless it is a specified variable. And there are
> tweaks to what :type does with its argument that makes it more useful,
> and obviates the need for a separate :type +v.
>
> https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst
>
> I like that it actually simplifies the UI (by removing :type +v), so I
> recommend acceptance.
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7
> 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN
> R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM
> DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+
> cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA
> hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr
> mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M
> 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE
> r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt
> fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H
> c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05
> rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg=
> =1qbg
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20190314/44ced9f9/attachment.html>

From rae at richarde.dev  Thu Mar 14 23:45:49 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 14 Mar 2019 19:45:49 -0400
Subject: [ghc-steering-committee] #179: Tweak the printing of foralls,
 recommendation: accept
In-Reply-To: <CAGK9nuqVMje8Z+HKgz6OD8HpW4c3zZmWRjgKX5J2YbcKKj57tQ@mail.gmail.com>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>
 <CAGK9nuqVMje8Z+HKgz6OD8HpW4c3zZmWRjgKX5J2YbcKKj57tQ@mail.gmail.com>
Message-ID: <08E3F317-362B-414A-A705-11C60A6AF679@richarde.dev>


> On Mar 14, 2019, at 6:18 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> bar :: forall a b. (a ~ Int) => a -> b -> a
> 
> Is it the case that `:t bar @Bool` will print
> 
> bar :: (Bool ~ Int) => Bool -> b -> Bool
> 
> This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the next variable to be instantiated is `a`. This is why we have `:type +v`.

The direction in the proposal came about in wondering if it's possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios.

Richard

> 
> -Iavor
> 
> 
> 
> On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Dear Committee,
> 
> Richard, in collarboration with Simon PJ, proposes some tweaks to how
> foralls are printed by GHC.
> 
> In particular, whenever a type variable is printed with an forall, it
> is printed with {a} unless it is a specified variable. And there are
> tweaks to what :type does with its argument that makes it more useful,
> and obviates the need for a separate :type +v.
> https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst <https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst>
> 
> I like that it actually simplifies the UI (by removing :type +v), so I
> recommend acceptance.
> 
> Cheers,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7
> 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN
> R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM
> DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+
> cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA
> hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr
> mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M
> 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE
> r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt
> fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H
> c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05
> rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg=
> =1qbg
> -----END PGP SIGNATURE-----
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/20190314/2901ef28/attachment-0001.html>

From rae at richarde.dev  Fri Mar 15 03:14:43 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 14 Mar 2019 23:14:43 -0400
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <0189fe7f6c67a36d5b930904b4c1ec7a6c5b2be8.camel@joachim-breitner.de>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
 <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
 <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>
 <CALpVSmOy2UgH-3cj_OwO+XdmOxcbMa4Hp99oce8w9UvUDvHggA@mail.gmail.com>
 <A2C6D022-99AD-4C72-937E-F4B946374A1C@cs.brynmawr.edu>
 <CANsrgP+tsNNbttzdyC_7aoojjj_g-PDOFkSMBOafdRAJYiu8aw@mail.gmail.com>
 <CALpVSmNjiD-2-8Hr9mfKNkcpUB1qidyJwqxpFFs_FL3HqzjbvA@mail.gmail.com>
 <0189fe7f6c67a36d5b930904b4c1ec7a6c5b2be8.camel@joachim-breitner.de>
Message-ID: <D667E9D3-AB5C-4962-A843-CB0F79F50E5C@richarde.dev>

Being a sucker for punishment, I have done this: https://github.com/goldfirere/ghc-proposals/blob/namespaces/proposals/0000-namespaces.rst <https://github.com/goldfirere/ghc-proposals/blob/namespaces/proposals/0000-namespaces.rst>

Richard

> On Mar 13, 2019, at 12:26 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> The more important question is: Who wants to do that “grand unifying
> ExplicitNamespaces proposal”?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190314/1563cef3/attachment.html>

From simonpj at microsoft.com  Fri Mar 15 08:26:21 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Mar 2019 08:26:21 +0000
Subject: [ghc-steering-committee] #179: Tweak the printing of foralls,
 recommendation: accept
In-Reply-To: <08E3F317-362B-414A-A705-11C60A6AF679@richarde.dev>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>
 <CAGK9nuqVMje8Z+HKgz6OD8HpW4c3zZmWRjgKX5J2YbcKKj57tQ@mail.gmail.com>
 <08E3F317-362B-414A-A705-11C60A6AF679@richarde.dev>
Message-ID: <DB7PR83MB0298F6833FA9735938F13F9BAD440@DB7PR83MB0298.EURPRD83.prod.outlook.com>

This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Why?  GHC often suppresses foralls when printing types; and had -fprint-explicit-foralls to stop doing that.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 14 March 2019 23:46
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept


On Mar 14, 2019, at 6:18 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

bar :: forall a b. (a ~ Int) => a -> b -> a

Is it the case that `:t bar @Bool` will print

bar :: (Bool ~ Int) => Bool -> b -> Bool

This looks particularly confusing without the explicit `forall`, although it seems questionable either way.

Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the next variable to be instantiated is `a`. This is why we have `:type +v`.

The direction in the proposal came about in wondering if it's possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios.

Richard



-Iavor



On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

Richard, in collarboration with Simon PJ, proposes some tweaks to how
foralls are printed by GHC.

In particular, whenever a type variable is printed with an forall, it
is printed with {a} unless it is a specified variable. And there are
tweaks to what :type does with its argument that makes it more useful,
and obviates the need for a separate :type +v.
https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst

I like that it actually simplifies the UI (by removing :type +v), so I
recommend acceptance.

Cheers,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7
9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN
R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM
DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+
cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA
hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr
mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M
9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE
r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt
fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H
c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05
rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg=
=1qbg
-----END PGP SIGNATURE-----
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto: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/20190315/cfa31c90/attachment-0001.html>

From bravit111 at gmail.com  Fri Mar 15 11:04:53 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Fri, 15 Mar 2019 14:04:53 +0300
Subject: [ghc-steering-committee] #195: Make Q (TExp a) into a newtype,
	rec: accept
In-Reply-To: <CALpVSmPNrEPDKJm3xbtAMyhgUbyfKLUvTHqPgWAjcfgzOT-N0g@mail.gmail.com>
References: <CALpVSmPNrEPDKJm3xbtAMyhgUbyfKLUvTHqPgWAjcfgzOT-N0g@mail.gmail.com>
Message-ID: <CALpVSmPvTRh1gs3aDKeTyHquB3ROHefhQm3cXYe7jtHeqqaJEg@mail.gmail.com>

Hi,

This proposal is being revised by the author due to an interaction with
other proposals on TH. I've changed the label at Github to "Needs revision".

Regards,
Vitaly



On Fri, Mar 8, 2019 at 9:40 AM Vitaly Bragilevsky <bravit111 at gmail.com>
wrote:

> Hi everyone,
>
> Matthew Pickering proposed to make Q (TExp a) into a newtype called Code.
> Proposal #195:
> https://github.com/ghc-proposals/ghc-proposals/blob/22e97d7693edb0b3676c948a123e57ea93c462e3/proposals/0000-code-texp.rst
> Pull request discussion:
> https://github.com/ghc-proposals/ghc-proposals/pull/195
>
> It looks like the motivation behind this proposal boils down to the
> convenience of writing instances which seems a good thing. The minor
> problem I see is the proposed name "Code" as it looks a little bit too
> abstract for Typed Template Haskell expressions. Nevertheless, I recommend
> to accept the proposal as it is. Silence is understood as agreement.
>
> Regards,
> Vitaly
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190315/6a17ade7/attachment.html>

From iavor.diatchki at gmail.com  Fri Mar 15 17:04:56 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 15 Mar 2019 10:04:56 -0700
Subject: [ghc-steering-committee] #179: Tweak the printing of foralls,
 recommendation: accept
In-Reply-To: <DB7PR83MB0298F6833FA9735938F13F9BAD440@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>
 <CAGK9nuqVMje8Z+HKgz6OD8HpW4c3zZmWRjgKX5J2YbcKKj57tQ@mail.gmail.com>
 <08E3F317-362B-414A-A705-11C60A6AF679@richarde.dev>
 <DB7PR83MB0298F6833FA9735938F13F9BAD440@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nuojLMuO6QxN0-JpBXjbJVwrrCqO1Qjy-2uD3Bmf7g1iBw@mail.gmail.com>

I just mean that without explicit foralls the fact that there is another
quantified variable is not quite obvious, and so to me it looks quite
surprising that the context didn't get simplified.

This is a bit orthogonal, but what would you expect to see in this case:

type T b = Bool
bar :: (a ~ Int) => a -> T b -> a

:t bar
:t bar @Bool

I guess the answer to these depends on if `b` is quantified or not.





On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> This looks particularly confusing without the explicit `forall`, although
> it seems questionable either way.
>
>
>
> Why?  GHC often suppresses foralls when printing types; and had
> -fprint-explicit-foralls to stop doing that.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Richard Eisenberg
> *Sent:* 14 March 2019 23:46
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
> *Subject:* Re: [ghc-steering-committee] #179: Tweak the printing of
> foralls, recommendation: accept
>
>
>
>
>
> On Mar 14, 2019, at 6:18 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>
>
> bar :: forall a b. (a ~ Int) => a -> b -> a
>
>
>
> Is it the case that `:t bar @Bool` will print
>
>
>
> bar :: (Bool ~ Int) => Bool -> b -> Bool
>
>
>
> This looks particularly confusing without the explicit `forall`, although
> it seems questionable either way.
>
>
>
> Yes, you understand correctly. `:t bar @Bool` will print that unfortunate
> type. I agree this is questionable. But I don't know how to do better. The
> current state of affairs is awkward in a different way, in that `:t bar
> @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b ->
> Int`, even though a further visible type application is possible. Perhaps
> worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the
> next variable to be instantiated is `a`. This is why we have `:type +v`.
>
>
>
> The direction in the proposal came about in wondering if it's possible to
> improve the mechanics of `:t` (without the `+v`). After we thought of doing
> maximal instantiation of inferred arguments (but no generalization), then
> we realized we could drop `:type +v` as redundant. I agree it's something
> of an uneasy compromise here, but I think any choice is going to have
> unfortunate behavior in some scenarios.
>
>
>
> Richard
>
>
>
>
>
> -Iavor
>
>
>
>
>
>
>
> On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Dear Committee,
>
> Richard, in collarboration with Simon PJ, proposes some tweaks to how
> foralls are printed by GHC.
>
> In particular, whenever a type variable is printed with an forall, it
> is printed with {a} unless it is a specified variable. And there are
> tweaks to what :type does with its argument that makes it more useful,
> and obviates the need for a separate :type +v.
>
> https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst
>
> I like that it actually simplifies the UI (by removing :type +v), so I
> recommend acceptance.
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7
> 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN
> R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM
> DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+
> cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA
> hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr
> mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M
> 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE
> r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt
> fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H
> c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05
> rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg=
> =1qbg
> -----END PGP SIGNATURE-----
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> 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/20190315/71d43749/attachment.html>

From rae at richarde.dev  Fri Mar 15 18:03:01 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 15 Mar 2019 14:03:01 -0400
Subject: [ghc-steering-committee] #179: Tweak the printing of foralls,
 recommendation: accept
In-Reply-To: <CAGK9nuojLMuO6QxN0-JpBXjbJVwrrCqO1Qjy-2uD3Bmf7g1iBw@mail.gmail.com>
References: <60a52ca934167ab68ecab76bde5789f74e242181.camel@joachim-breitner.de>
 <baf92eee08c3d851f3145295db267f121b21beec.camel@joachim-breitner.de>
 <CAGK9nuqVMje8Z+HKgz6OD8HpW4c3zZmWRjgKX5J2YbcKKj57tQ@mail.gmail.com>
 <08E3F317-362B-414A-A705-11C60A6AF679@richarde.dev>
 <DB7PR83MB0298F6833FA9735938F13F9BAD440@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAGK9nuojLMuO6QxN0-JpBXjbJVwrrCqO1Qjy-2uD3Bmf7g1iBw@mail.gmail.com>
Message-ID: <5DEA3DD0-273F-4951-8803-6775231A52CC@richarde.dev>



> On Mar 15, 2019, at 1:04 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> This is a bit orthogonal, but what would you expect to see in this case:
> 
> type T b = Bool
> bar :: (a ~ Int) => a -> T b -> a
> 
> :t bar

Without -fprint-explicit-foralls: (a ~ Int) => a -> T b -> a
With -fprint-explicit-foralls: forall a b. (a ~ Int) => a -> T b -> a

> :t bar @Bool

Without -fprint-explicit-foralls: (Bool ~ Int) => Bool -> T b -> Bool
With -fprint-explicit-foralls: forall b. (Bool ~ Int) => Bool -> T b -> Bool

> 
> I guess the answer to these depends on if `b` is quantified or not.

b *is* quantified -- the quantification happens on the type as the user writes it.

Richard

> 
> 
> 
> 
> 
> On Fri, Mar 15, 2019 at 1:26 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> This looks particularly confusing without the explicit `forall`, although it seems questionable either way.
> 
>  
> 
> Why?  GHC often suppresses foralls when printing types; and had -fprint-explicit-foralls to stop doing that.
> 
>  
> 
> Simon
> 
>  
> 
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Richard Eisenberg
> Sent: 14 March 2019 23:46
> To: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>
> Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
> Subject: Re: [ghc-steering-committee] #179: Tweak the printing of foralls, recommendation: accept
> 
>  
> 
>  
> 
> On Mar 14, 2019, at 6:18 PM, Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
> 
>  
> 
> bar :: forall a b. (a ~ Int) => a -> b -> a
> 
>  
> 
> Is it the case that `:t bar @Bool` will print
> 
>  
> 
> bar :: (Bool ~ Int) => Bool -> b -> Bool
> 
>  
> 
> This looks particularly confusing without the explicit `forall`, although it seems questionable either way.
> 
>  
> 
> Yes, you understand correctly. `:t bar @Bool` will print that unfortunate type. I agree this is questionable. But I don't know how to do better. The current state of affairs is awkward in a different way, in that `:t bar @Bool` errors (that's OK) and `:t bar @Int` prints `forall {b}. Int -> b -> Int`, even though a further visible type application is possible. Perhaps worse, `:t bar` today prints `forall {b}. Int -> b -> Int` even though the next variable to be instantiated is `a`. This is why we have `:type +v`.
> 
>  
> 
> The direction in the proposal came about in wondering if it's possible to improve the mechanics of `:t` (without the `+v`). After we thought of doing maximal instantiation of inferred arguments (but no generalization), then we realized we could drop `:type +v` as redundant. I agree it's something of an uneasy compromise here, but I think any choice is going to have unfortunate behavior in some scenarios.
> 
>  
> 
> Richard
> 
> 
> 
> 
>  
> 
> -Iavor
> 
>  
> 
>  
> 
>  
> 
> On Thu, Mar 14, 2019 at 7:47 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> 
> Dear Committee,
> 
> Richard, in collarboration with Simon PJ, proposes some tweaks to how
> foralls are printed by GHC.
> 
> In particular, whenever a type variable is printed with an forall, it
> is printed with {a} unless it is a specified variable. And there are
> tweaks to what :type does with its argument that makes it more useful,
> and obviates the need for a separate :type +v.
> https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst <https://github.com/goldfirere/ghc-proposals/blob/printing-foralls/proposals/0000-printing-foralls.rst>
> 
> I like that it actually simplifies the UI (by removing :type +v), so I
> recommend acceptance.
> 
> Cheers,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iQIzBAABCAAdFiEEGkYIf5Vdk8V8YFcbPZCKs/D79R8FAlyKaX8ACgkQPZCKs/D7
> 9R/7oxAAgU213SuV+1lr/JExnMSPNWD6s7CPTWdauLK+tHYUv1MD3HeZlBZb2pvN
> R/swC6jdm95vKXWeMVhfYGFGepOdMEKzqBWLDf3fCO29MlHlb4barwtEZOZ9AbaM
> DSyE+RjVQ35ATZPvfFTYdBacBrvCivoRWcUdi10ps6rizI86gKeCiG1PN5nVMNV+
> cpvTpFWRm/xmbtU4xFWuZ9FjL0bfO6yJCueX07gTkdZYW4vnvWSdis6CInkQZ7SA
> hXbTEYNT9zMCGvJMG+NQN+5c0h3GJlUoTsNGd0PsQnkvoYiLjM52eM5hzkz5zFRr
> mMYT381T1nnIl505IFGuT/je5KAn7wTImIXvvclwDxfjCBn3J1IRVAbikgwlTU4M
> 9L+tlQiTKI8OZpbgpPjjRj4hWrnX1gzWiIGwtPYtQuPhkDhEvq0xex8qEKpd7waE
> r5klTYyZrC0LGaHyX5G5yunGLWqnlLKOHAPI20Z1bxVPtDJZ/4g6AoCYSNqBLsHt
> fMTFflHdKTlsCOETPGhaxgf6PP0WvZtNdgTrB2rL5jzKJSOKc1rVRFAdYIr5PP3H
> c4aZGce/ChyFazHeF7hH5UZ7yyB0gMc3T+do6I8vySp0YGeRweb36FU13CduMS05
> rvzb6GIkNFz/Fx2MascE9kZtGvDT9BlxGXqJ9rL/huXquIwN6Gg=
> =1qbg
> -----END PGP SIGNATURE-----
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/20190315/a956a216/attachment-0001.html>

From eric at seidel.io  Sat Mar 16 14:40:28 2019
From: eric at seidel.io (Eric Seidel)
Date: Sat, 16 Mar 2019 10:40:28 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=23209=3A_Levity_poly?=
 =?utf-8?q?morphic_lift=2E_Recommendation=3A_accept?=
In-Reply-To: <8A88C4A9-3077-44E6-A9E9-D4C7CF0313F5@richarde.dev>
References: <fd1024c0-fd8d-44d2-b0b3-26cce60c74ce@www.fastmail.com>
 <F8996CF1-EECC-48AB-957C-2424193ADFFD@cs.brynmawr.edu>
 <e5e9dc6a-a708-4f4d-9c6d-bbeada4cf5a4@www.fastmail.com>
 <1E69A6CF-D809-44D9-9903-3DEEF6AB13C3@cs.brynmawr.edu>
 <DB7PR83MB029804CF61E876E1F4EB2D6FAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <B3E6575E-3A0B-40D3-9A5B-924981E8AF99@seidel.io>
 <DB7PR83MB029819400A9669497730E074AD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <7d0c15f7-06ec-4a0a-bbb8-faa1907f661d@www.fastmail.com>
 <DB7PR83MB0298EE7DFE19DEB0961B343BAD720@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CAGK9nupp7A5nJ=q3arxCCUSTQgMM+W33XcpSGgtSzso93VDO=Q@mail.gmail.com>
 <C0491A7D-5451-4E19-B270-A97659AE0074@cs.brynmawr.edu>
 <bff01274-4e9b-4c34-bd39-680cb9053916@www.fastmail.com>
 <8A88C4A9-3077-44E6-A9E9-D4C7CF0313F5@richarde.dev>
Message-ID: <a4160553-3c61-4327-937a-2c86ff4c8cfe@www.fastmail.com>

Too bad. It sounds like we agree then that removing the default implementation is the best option we have. I've proposed that on GitHub and will approve the modified proposal assuming there aren't any last objections.

On Thu, Mar 14, 2019, at 15:29, Richard Eisenberg wrote:
> 
> 
> > On Mar 7, 2019, at 10:27 PM, Eric Seidel <eric at seidel.io> wrote:
> > 
> > I imagine we could get away with
> > 
> > default liftTyped :: (r ~ 'LiftedRep, Data t) => t -> Q (TExp t)
> > liftTyped = unsafeTExpCoerce . liftData
> 
> Sadly, this won't work. GHC just isn't clever enough. The problem is 
> that, for (Data t) to be well-typed, we need (r ~ LiftedRep). This 
> means that the typedness of one constraint depends on another. The 
> internal language can do this fine, but type inference isn't up to the 
> challenge. We'll get there some day. But I think this way is a dead-end 
> for now.
> 
> So it sounds (to me) that the best way forward is to remove the default 
> implementation of liftTyped altogether....
> 
> Richard

From simonpj at microsoft.com  Tue Mar 19 13:52:34 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 19 Mar 2019 13:52:34 +0000
Subject: [ghc-steering-committee] GHC proposal #203: PtrRep. Recommendation:
	accept
Message-ID: <DB7PR83MB0298D50C104F06DB43A5973CAD400@DB7PR83MB0298.EURPRD83.prod.outlook.com>

Colleagues

I propose that we accept proposal #203 on lifted-ness polymorphism.
https://github.com/andrewthad/ghc-proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst

In particular, the definition of RuntimeRep changes from
	data RuntimeRep
	  = LiftedRep
	  | UnliftedRep
	  | IntRep
	  | ...
to
	data Levity = Lifted | Unlifted
	data RuntimeRep
	  = PtrRep Levity
	  | IntRep
	  | ...

The goal here is to support levity *polymorphism*, with the main payoff being the ability to store both lifted and unlifted values in the same data types.  So, for example

data Array# :: forall (v :: Levity). TYPE ('PtrRep v) -> Type
data MutableArray# :: forall (v :: Levity). Type -> TYPE ('PtrRep v) -> Type

This is a real win compared to having one data type for lifted and one for unlifted values.  But they have the same *representation*: both are represented by a pointer.

I believe (although the proposal does not aquite say) that the proposal fully subsumes the earlier (accepted) proposal for unlifted arrays
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0021-unlifted-array.rst
So that's good!

This proposal seems like a pretty clear win.   The only downside is (as so often) that the full types of data types and functions gets a bit more complicated.  But we've already accepted that with the levity polymorphism stuff we already have.   

Silence = assent 😊

Simon


| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Joachim Breitner
| Sent: 03 February 2019 14:13
| To: ghc-steering-committee at haskell.org
| Subject: [ghc-steering-committee] Please review #203: PtrRep, Shepherd:
| Simon PJ
| 
| Dear Committee,
| 
| this is your secretary speaking:
| 
| PtrRep has been proposed by Andrew Martin:
| https://github.com/ghc-proposals/ghc-proposals/pull/203
| https://github.com/andrewthad/ghc-
| proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst
| 
| I propose Simon PJ as the shepherd (he already glimpsed at it, so
| hopefully already has an opinion.)
| 
| Please reach consensus as described in
| https://github.com/ghc-proposals/ghc-proposals#committee-process
| I suggest you make a recommendation, in a new e-mail thread with the
| proposal number in the subject, about the decision, maybe point out
| debatable points, and assume that anyone who stays quiet agrees with
| you.
| 
| Thanks,
| Joachim
| --
| Joachim Breitner
|   mail at joachim-breitner.de
|   http://www.joachim-breitner.de/


From rae at richarde.dev  Tue Mar 19 15:02:57 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 19 Mar 2019 11:02:57 -0400
Subject: [ghc-steering-committee] GHC proposal #203: PtrRep.
 Recommendation: accept
In-Reply-To: <DB7PR83MB0298D50C104F06DB43A5973CAD400@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <DB7PR83MB0298D50C104F06DB43A5973CAD400@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <889A7290-4316-465B-99DE-942141ABD1DD@richarde.dev>

I think this is an easy win -- if it works. Although there were opportunities to realize this before now, I'm not sure it does.

The proposal mentions this new type:

> makeStableName# :: forall {v :: Levity} (a :: TYPE ('PtrRep v)). a -> State# RealWorld -> (#State# RealWorld, StableName# a#)

But that looks like the definition of this function will have a levity-polymorphic binder. With normal levity-polymorphic binders, we're in a real bind, because we don't whether to use a pointer or not. We have no such challenge here... but we still have a challenge: is makeStableName# strict in its argument or not? Maybe the answer is that every call site of makeStableName# has to sort this out. I suppose that would work, but it also means that we cannot abstract over makeStableName# -- that is, we won't be able to write myMakeStableName# = makeStableName# and with the same type.

Am I barking up the wrong tree here?

Thanks,
Richard

> On Mar 19, 2019, at 9:52 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> Colleagues
> 
> I propose that we accept proposal #203 on lifted-ness polymorphism.
> https://github.com/andrewthad/ghc-proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst
> 
> In particular, the definition of RuntimeRep changes from
> 	data RuntimeRep
> 	  = LiftedRep
> 	  | UnliftedRep
> 	  | IntRep
> 	  | ...
> to
> 	data Levity = Lifted | Unlifted
> 	data RuntimeRep
> 	  = PtrRep Levity
> 	  | IntRep
> 	  | ...
> 
> The goal here is to support levity *polymorphism*, with the main payoff being the ability to store both lifted and unlifted values in the same data types.  So, for example
> 
> data Array# :: forall (v :: Levity). TYPE ('PtrRep v) -> Type
> data MutableArray# :: forall (v :: Levity). Type -> TYPE ('PtrRep v) -> Type
> 
> This is a real win compared to having one data type for lifted and one for unlifted values.  But they have the same *representation*: both are represented by a pointer.
> 
> I believe (although the proposal does not aquite say) that the proposal fully subsumes the earlier (accepted) proposal for unlifted arrays
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0021-unlifted-array.rst
> So that's good!
> 
> This proposal seems like a pretty clear win.   The only downside is (as so often) that the full types of data types and functions gets a bit more complicated.  But we've already accepted that with the levity polymorphism stuff we already have.   
> 
> Silence = assent 😊
> 
> Simon
> 
> 
> | -----Original Message-----
> | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> | On Behalf Of Joachim Breitner
> | Sent: 03 February 2019 14:13
> | To: ghc-steering-committee at haskell.org
> | Subject: [ghc-steering-committee] Please review #203: PtrRep, Shepherd:
> | Simon PJ
> | 
> | Dear Committee,
> | 
> | this is your secretary speaking:
> | 
> | PtrRep has been proposed by Andrew Martin:
> | https://github.com/ghc-proposals/ghc-proposals/pull/203
> | https://github.com/andrewthad/ghc-
> | proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst
> | 
> | I propose Simon PJ as the shepherd (he already glimpsed at it, so
> | hopefully already has an opinion.)
> | 
> | Please reach consensus as described in
> | https://github.com/ghc-proposals/ghc-proposals#committee-process
> | I suggest you make a recommendation, in a new e-mail thread with the
> | proposal number in the subject, about the decision, maybe point out
> | debatable points, and assume that anyone who stays quiet agrees with
> | you.
> | 
> | Thanks,
> | Joachim
> | --
> | Joachim Breitner
> |   mail at joachim-breitner.de
> |   http://www.joachim-breitner.de/
> 
> _______________________________________________
> 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/20190319/e6fb2703/attachment.html>

From simonpj at microsoft.com  Tue Mar 19 16:19:58 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 19 Mar 2019 16:19:58 +0000
Subject: [ghc-steering-committee] GHC proposal #203: PtrRep.
 Recommendation: accept
In-Reply-To: <727BB5E0-841F-41DE-8AB0-1C44C8312D5D@cs.brynmawr.edu>
References: <DB7PR83MB0298D50C104F06DB43A5973CAD400@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <727BB5E0-841F-41DE-8AB0-1C44C8312D5D@cs.brynmawr.edu>
Message-ID: <DB7PR83MB0298017BBBE331016937C870AD400@DB7PR83MB0298.EURPRD83.prod.outlook.com>

|  But that looks like the definition of this function will have a levity-
|  polymorphic binder.

I think not.  It's a *primitive* and doesn't have definition as a Haskell function.

At any *call* the existing restrictions will ensure that the levity of the argument is monomorphic, so we know its strictness.

Indeed we can make personal levity-polymorphic versions of makeStableName#; but that's no worse than today.

In short, the only parts that use levity polymorphism are the primitive data types and primitive functions -- but that is still a hugely welcome benefit. 

Plus, as the paper showed, levity polymorphism works more often than you might expect -- that was our discovery when doing the levity polymorphism paper (Section 7). https://www.microsoft.com/en-us/research/publication/levity-polymorphism/

Simon

|  -----Original Message-----
|  From: Richard Eisenberg <rae at cs.brynmawr.edu>
|  Sent: 19 March 2019 15:01
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] GHC proposal #203: PtrRep.
|  Recommendation: accept
|  
|  I think this is an easy win -- if it works. Although there were
|  opportunities to realize this before now, I'm not sure it does.
|  
|  The proposal mentions this new type:
|  
|  > makeStableName# :: forall {v :: Levity} (a :: TYPE ('PtrRep v)). a ->
|  > State# RealWorld -> (#State# RealWorld, StableName# a#)
|  
|  But that looks like the definition of this function will have a levity-
|  polymorphic binder. With normal levity-polymorphic binders, we're in a real
|  bind, because we don't whether to use a pointer or not. We have no such
|  challenge here... but we still have a challenge: is makeStableName# strict
|  in its argument or not? Maybe the answer is that every call site of
|  makeStableName# has to sort this out. I suppose that would work, but it
|  also means that we cannot abstract over makeStableName# -- that is, we
|  won't be able to write myMakeStableName# = makeStableName# and with the
|  same type.
|  
|  Am I barking up the wrong tree here?
|  
|  Thanks,
|  Richard
|  
|  > On Mar 19, 2019, at 9:52 AM, Simon Peyton Jones via ghc-steering-
|  committee <ghc-steering-committee at haskell.org> wrote:
|  >
|  > Colleagues
|  >
|  > I propose that we accept proposal #203 on lifted-ness polymorphism.
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > ub.com%2Fandrewthad%2Fghc-proposals%2Fblob%2Fpointer_rep%2Fproposals%2
|  > F0000-pointer-rep.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ca3d
|  > e64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
|  > C0%7C636886044859486112&amp;sdata=kiNFop0sQAqf%2BdvlIqXqt7foIj86%2FoYW
|  > kM4nmkn0aRs%3D&amp;reserved=0
|  >
|  > In particular, the definition of RuntimeRep changes from
|  > 	data RuntimeRep
|  > 	  = LiftedRep
|  > 	  | UnliftedRep
|  > 	  | IntRep
|  > 	  | ...
|  > to
|  > 	data Levity = Lifted | Unlifted
|  > 	data RuntimeRep
|  > 	  = PtrRep Levity
|  > 	  | IntRep
|  > 	  | ...
|  >
|  > The goal here is to support levity *polymorphism*, with the main
|  > payoff being the ability to store both lifted and unlifted values in
|  > the same data types.  So, for example
|  >
|  > data Array# :: forall (v :: Levity). TYPE ('PtrRep v) -> Type data
|  > MutableArray# :: forall (v :: Levity). Type -> TYPE ('PtrRep v) ->
|  > Type
|  >
|  > This is a real win compared to having one data type for lifted and one
|  for unlifted values.  But they have the same *representation*: both are
|  represented by a pointer.
|  >
|  > I believe (although the proposal does not aquite say) that the
|  > proposal fully subsumes the earlier (accepted) proposal for unlifted
|  > arrays
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  > ub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0
|  > 021-unlifted-array.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ca3
|  > de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  > 7C0%7C636886044859486112&amp;sdata=AHFBdsOZK9zUHPHtL7kuyFG6PIcc5lYFdBO
|  > Uew%2BMLSE%3D&amp;reserved=0
|  > So that's good!
|  >
|  > This proposal seems like a pretty clear win.   The only downside is (as
|  so often) that the full types of data types and functions gets a bit more
|  complicated.  But we've already accepted that with the levity polymorphism
|  stuff we already have.
|  >
|  > Silence = assent 😊
|  >
|  > Simon
|  >
|  >
|  > | -----Original Message-----
|  > | From: ghc-steering-committee
|  > | <ghc-steering-committee-bounces at haskell.org>
|  > | On Behalf Of Joachim Breitner
|  > | Sent: 03 February 2019 14:13
|  > | To: ghc-steering-committee at haskell.org
|  > | Subject: [ghc-steering-committee] Please review #203: PtrRep, Shepherd:
|  > | Simon PJ
|  > |
|  > | Dear Committee,
|  > |
|  > | this is your secretary speaking:
|  > |
|  > | PtrRep has been proposed by Andrew Martin:
|  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
|  > | thub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F203&amp;data=02%7C
|  > | 01%7Csimonpj%40microsoft.com%7Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72
|  > | f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112&amp;sdat
|  > | a=m5ruL8NdOhxWIH%2BpCDvgt%2Fz%2BnEUvip39gZsNjOTN51w%3D&amp;reserved=
|  > | 0
|  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
|  > | thub.com%2Fandrewthad%2Fghc-&amp;data=02%7C01%7Csimonpj%40microsoft.
|  > | com%7Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd01
|  > | 1db47%7C1%7C0%7C636886044859486112&amp;sdata=RZcFrrw8iROwoEVBHxou%2B
|  > | D41SCZ7pHyNBSicj1vP5tw%3D&amp;reserved=0
|  > | proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst
|  > |
|  > | I propose Simon PJ as the shepherd (he already glimpsed at it, so
|  > | hopefully already has an opinion.)
|  > |
|  > | Please reach consensus as described in
|  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
|  > | thub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&amp;dat
|  > | a=02%7C01%7Csimonpj%40microsoft.com%7Ca3de64d79ccc4d98ebc808d6ac7bc0
|  > | f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112&a
|  > | mp;sdata=A5MyvZAJCtdEzs%2B65kPrjG5jihSiLH5kJ1YVCr%2B8ZV0%3D&amp;rese
|  > | rved=0 I suggest you make a recommendation, in a new e-mail thread
|  > | with the proposal number in the subject, about the decision, maybe
|  > | point out debatable points, and assume that anyone who stays quiet
|  > | agrees with you.
|  > |
|  > | Thanks,
|  > | Joachim
|  > | --
|  > | Joachim Breitner
|  > |   mail at joachim-breitner.de
|  > |
|  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
|  > | .joachim-breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7
|  > | Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47
|  > | %7C1%7C0%7C636886044859486112&amp;sdata=hQsVqHn4C8QI46PxWq1H6WGNEWpr
|  > | PJVXCe4ZpxWo2zw%3D&amp;reserved=0
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a
|  > mp;data=02%7C01%7Csimonpj%40microsoft.com%7Ca3de64d79ccc4d98ebc808d6ac
|  > 7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112
|  > &amp;sdata=l2tcX8N2KgdEF4RskU%2BewuzdDwAd38u8odTUqYsD6ww%3D&amp;reserv
|  > ed=0


From simonpj at microsoft.com  Wed Mar 13 13:39:23 2019
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 13 Mar 2019 13:39:23 +0000
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <CANsrgP+tsNNbttzdyC_7aoojjj_g-PDOFkSMBOafdRAJYiu8aw@mail.gmail.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
 <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
 <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>
 <CALpVSmOy2UgH-3cj_OwO+XdmOxcbMa4Hp99oce8w9UvUDvHggA@mail.gmail.com>
 <A2C6D022-99AD-4C72-937E-F4B946374A1C@cs.brynmawr.edu>
 <CANsrgP+tsNNbttzdyC_7aoojjj_g-PDOFkSMBOafdRAJYiu8aw@mail.gmail.com>
Message-ID: <DB7PR83MB0298471AE7535DC5335469B5AD4A0@DB7PR83MB0298.EURPRD83.prod.outlook.com>

I don't think it makes a lot of sense to accept this proposal, since it conflicts with the earlier one. Should we instead work on a modification of the earlier proposal to extend it to import/export lists, and also resolve the debate about data/pattern/value?

Good summary.  We clearly need something that behaves uniformly in the five situations Simon describes.  Whether we think of it as “a modification of an earlier proposal” or “a  new proposal” doesn’t really matter.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 13 March 2019 13:35
To: Richard Eisenberg <rae at cs.brynmawr.edu>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept

On Mon, 11 Mar 2019 at 13:26, Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
"value" would not work as the namespace indicator I envision for the future, as it's a commonly used variable name. (I would advocate against making it a keyword for this reason.) This knob is relatively easy to turn, though, so it's conceivable to use "value" today, and then if/when we start using "data" in the future, allow the use of "data" where we use "value", eventually deprecating and removing "value". It's a bit annoying to users to keep changing it, but only a bit. I've been in this game long enough to know that the future isn't quite predictable, and so I see the sense in choosing the best thing for us now, leaving the door open to fixing it later if necessary. I still advocate for "data", but I won't burst into tears if we choose "value".

I could see waiting a day or two for further commentary and then putting it to a committee vote. In the end, I think this choice matters little.


For those who (like me) might have been a bit confused about the current state of things:

  *   There are 5 places that we want namespace specifiers now (possibly more later): import, export, fixity, WARNING, DEPRECATED
  *   GHC's existing ExplicitNamespaces option allows type and pattern keywords to be used in import, export
  *   The earlier proposal Require namespacing fixity declarations for type names and WARNING/DEPRECATED pragmas<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0008-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398072333&sdata=ZDHMErg3a2TOIPwJoDlnFtkzspZDakmTuDrArpqtJEA%3D&reserved=0>  was accepted, and allows type and value keywords in fixity, WARNING, DEPRECATED
  *   This proposal Deprecated Entities<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnineonine%2Fghc-proposals%2Fblob%2Fdepr-entities%2Fproposals%2F0000-deprecated-entities.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398072333&sdata=o2ljHn9Yjn3Ezf%2FPTIIGT48aRSvg6hm22kwIfilr6%2FY%3D&reserved=0> suggests adding type and pattern specifiers to DEPRECATED pragmas. (note that DEPRECATED pragmas were covered by the earlier proposal, so this conflicts)
  *   Vitaly's suggested modification of this proposal is to  adopt type and data instead (for DEPRECATED pragmas), while Simon pointed out that we already accepted a proposal for this, using type and value, and that whatever we do we should do it consistently across import, export, fixity, WARNING, DEPRECATED (yes!)
I don't think it makes a lot of sense to accept this proposal, since it conflicts with the earlier one. Should we instead work on a modification of the earlier proposal to extend it to import/export lists, and also resolve the debate about data/pattern/value?

Richard's concerns about future extensions to add namespacing in expressions seem valid to me, it would be unfortunate to use value now if that will cause problems later.

Cheers
Simon



Richard


On Mar 11, 2019, at 9:12 AM, Vitaly Bragilevsky <bravit111 at gmail.com<mailto:bravit111 at gmail.com>> wrote:

Hi Richard,

Do you think that using "value" now is a real stopper for the future you are talking about? Maybe we should start thinking about making "value" a reserved keyword because it suits our purposes best as a namespace specifier. It looks like this data/value debate is the only issue before reaching the consensus on this proposal. So we have to do something about it.

Regards,
Vitaly

On Sun, Mar 10, 2019 at 12:10 AM Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
My argument for `data` is as follows (quoted from earlier writing of mine):

---
Though I understand the reasons against it, I'm an unabashed supporter of using the word "data" to supplant "pattern". My principal argument is that data can be used freely in the syntax, given that it's a keyword that has current meaning only as the first lexeme in a top-level declaration. (Specifically, I pine for a future where types and terms mix. We can then use type and data in the middle of expressions/types to denote namespaces.) It also works nicely to mean "data constructor". I agree that it doesn't work as well with functions or the potential confusion around "data Bool = True | False" (though, in that last example, we can pretend hard that the data applies only to the bits after the =).
---

In other words, I think `data` is more future-compatible than any of the alternatives, even though I agree that `value` flows more smoothly. We can think of `data` as meaning "data-level", not "data constructor" (though that admittedly takes a bit of mental gymnastics).

Richard



On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <bravit111 at gmail.com<mailto:bravit111 at gmail.com>> wrote:

I think we don't have a consensus on the particular word yet: is it data or value. I'd like to listen to Richard who was strongly in favor of data. We are in agreement about consistency though.

Vitaly


On Fri, Mar 8, 2019 at 8:45 PM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

I fully support this (I thought I brought it up before, but maybe not
strongly enough).

Should we just include this change in #167? (If politicians can add
random riders to laws, so can we). Or does it need more thought?

Cheers,
Joachim


Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> I also argue that, to be consistent, whatever keyword we agree, we should use it
> In the (accepted) infix/WARNING proposal
> In import and export lists – presumably for now in addition to ‘pattern’, though we might end up deprecating the latter.
> Simon
>
> From: Vitaly Bragilevsky <bravit111 at gmail.com<mailto:bravit111 at gmail.com>>
> Sent: 08 March 2019 14:44
> To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
> Cc: Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at gmail.com>>; ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
>
> Simon PJ argues for "value" over "data" as a specifier: https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F167%23issuecomment-470947193&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398082326&sdata=bap1ILHXYU%2Bxblq5N3DapBvpr5Se3TdNiwLi8kHT3I0%3D&reserved=0>
>
> I'm fine with this choice either (and I'm satisfied with the argument that deprecating or setting fixity for value "value" is a rare case to be considered seriously). If you have another opinion, please, speak up.
>
> Vitaly
>
> On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
> > I’ve made a post on the proposal thread asking why we don’t just follow the already-adopted proposal for WARNING and infix pragmas.
> >
> > Simon
> >
> > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Simon Marlow
> > Sent: 08 March 2019 07:57
> > To: Vitaly Bragilevsky <bravit111 at gmail.com<mailto:bravit111 at gmail.com>>
> > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
> >
> > Yes, I think this is the right way to go.
> >
> > Cheers
> > Simon
> >
> > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com<mailto:bravit111 at gmail.com>> wrote:
> > > Hi everyone,
> > >
> > > I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnineonine%2Fghc-proposals%2Fblob%2Fdepr-entities%2Fproposals%2F0000-deprecated-entities.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398082326&sdata=V%2Bgqa%2FslqR01WIiGKDyuXFSYqp4RkFdbHcB6G1l2l1w%3D&reserved=0>). It is proposed to extend (nonpositional) DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. In its current formulation, the proposal suggests to use the specifiers "type" for type-level things and "pattern" for value-level things as follows:
> > >
> > > data Bar = Bar
> > > {-# DEPRECATED type Bar "Don't use type Bar" #-}
> > > data Baz = Baz
> > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
> > >
> > > Using this pragma without specifiers should mean deprecating both (as is works now).
> > >
> > > After discussing this proposal within the committee (see https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-February%2F000894.html&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398092323&sdata=YTuIVN7wsC%2FmzJ51PH2RGCPLiecKhvkEFO0Ug3Aq7fg%3D&reserved=0>), I recommend acceptance with one change, namely using "data" instead of "pattern" for deprecating value-level things.
> > >
> > > Reasons for choosing "data":
> > > * it's a reserved keyword (as opposed to "value", which is another option)
> > > * we are deprecating data constructors here
> > > * it just feels right (sorry!)
> > >
> > > Reasons against "data":
> > > * it can be confusing whether we mean data type or data constructor
> > > * we use "value" and "pattern" in other places meaning basically the same thing
> > >
> > > If the committee decides to go this way, then the wider community may think about other proposals, such as
> > > * adding positional DEPRECATED pragmas (including class instances deprecation)
> > > * fixing inconsistencies with the fixity declarations (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0008-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398092323&sdata=ktRl25ulQKFOI7cxTFabP0wTcg7C9g77LzxPO1riyVs%3D&reserved=0>) and updating ExplicitNamespaces in import/export lists
> > > * deprecating usage of nonpositional DEPRECATED pragma without the specifiers
> > >
> > > Silence is understood as agreement.
> > >
> > > Regards,
> > > Vitaly
> > >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398102314&sdata=VC3xfGC13FRwTHAklISNNhA1rcoql3OZVTPDkUddWGY%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398102314&sdata=VC3xfGC13FRwTHAklISNNhA1rcoql3OZVTPDkUddWGY%3D&reserved=0>
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398112311&sdata=uuKaUz37cFsSoxYHkKX%2Ba2DoSTUtw50aMrga5FCW8LE%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398112311&sdata=ngNXSvxU3dcuQq0SOQZf8DNtP5Sz4sGbg9Y2eSu%2BeIo%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398122306&sdata=Oyy8xoNizqkTE4RovIMahuiWA6hvoVtib0S%2FgLStY0c%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398122306&sdata=Oyy8xoNizqkTE4RovIMahuiWA6hvoVtib0S%2FgLStY0c%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190313/d71e6ce9/attachment-0001.html>

From rae at richarde.dev  Wed Mar 20 03:22:06 2019
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 19 Mar 2019 23:22:06 -0400
Subject: [ghc-steering-committee] GHC proposal #203: PtrRep.
 Recommendation: accept
In-Reply-To: <DB7PR83MB0298017BBBE331016937C870AD400@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <DB7PR83MB0298D50C104F06DB43A5973CAD400@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <727BB5E0-841F-41DE-8AB0-1C44C8312D5D@cs.brynmawr.edu>
 <DB7PR83MB0298017BBBE331016937C870AD400@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <0A91B676-E13F-4A1B-BB4F-415FDC1851C1@richarde.dev>

OK -- yes, that all makes sense. I support acceptance.

Richard

> On Mar 19, 2019, at 12:19 PM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> |  But that looks like the definition of this function will have a levity-
> |  polymorphic binder.
> 
> I think not.  It's a *primitive* and doesn't have definition as a Haskell function.
> 
> At any *call* the existing restrictions will ensure that the levity of the argument is monomorphic, so we know its strictness.
> 
> Indeed we can make personal levity-polymorphic versions of makeStableName#; but that's no worse than today.
> 
> In short, the only parts that use levity polymorphism are the primitive data types and primitive functions -- but that is still a hugely welcome benefit. 
> 
> Plus, as the paper showed, levity polymorphism works more often than you might expect -- that was our discovery when doing the levity polymorphism paper (Section 7). https://www.microsoft.com/en-us/research/publication/levity-polymorphism/
> 
> Simon
> 
> |  -----Original Message-----
> |  From: Richard Eisenberg <rae at cs.brynmawr.edu>
> |  Sent: 19 March 2019 15:01
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> |  Cc: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] GHC proposal #203: PtrRep.
> |  Recommendation: accept
> |  
> |  I think this is an easy win -- if it works. Although there were
> |  opportunities to realize this before now, I'm not sure it does.
> |  
> |  The proposal mentions this new type:
> |  
> |  > makeStableName# :: forall {v :: Levity} (a :: TYPE ('PtrRep v)). a ->
> |  > State# RealWorld -> (#State# RealWorld, StableName# a#)
> |  
> |  But that looks like the definition of this function will have a levity-
> |  polymorphic binder. With normal levity-polymorphic binders, we're in a real
> |  bind, because we don't whether to use a pointer or not. We have no such
> |  challenge here... but we still have a challenge: is makeStableName# strict
> |  in its argument or not? Maybe the answer is that every call site of
> |  makeStableName# has to sort this out. I suppose that would work, but it
> |  also means that we cannot abstract over makeStableName# -- that is, we
> |  won't be able to write myMakeStableName# = makeStableName# and with the
> |  same type.
> |  
> |  Am I barking up the wrong tree here?
> |  
> |  Thanks,
> |  Richard
> |  
> |  > On Mar 19, 2019, at 9:52 AM, Simon Peyton Jones via ghc-steering-
> |  committee <ghc-steering-committee at haskell.org> wrote:
> |  >
> |  > Colleagues
> |  >
> |  > I propose that we accept proposal #203 on lifted-ness polymorphism.
> |  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  > ub.com%2Fandrewthad%2Fghc-proposals%2Fblob%2Fpointer_rep%2Fproposals%2
> |  > F0000-pointer-rep.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ca3d
> |  > e64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
> |  > C0%7C636886044859486112&amp;sdata=kiNFop0sQAqf%2BdvlIqXqt7foIj86%2FoYW
> |  > kM4nmkn0aRs%3D&amp;reserved=0
> |  >
> |  > In particular, the definition of RuntimeRep changes from
> |  > 	data RuntimeRep
> |  > 	  = LiftedRep
> |  > 	  | UnliftedRep
> |  > 	  | IntRep
> |  > 	  | ...
> |  > to
> |  > 	data Levity = Lifted | Unlifted
> |  > 	data RuntimeRep
> |  > 	  = PtrRep Levity
> |  > 	  | IntRep
> |  > 	  | ...
> |  >
> |  > The goal here is to support levity *polymorphism*, with the main
> |  > payoff being the ability to store both lifted and unlifted values in
> |  > the same data types.  So, for example
> |  >
> |  > data Array# :: forall (v :: Levity). TYPE ('PtrRep v) -> Type data
> |  > MutableArray# :: forall (v :: Levity). Type -> TYPE ('PtrRep v) ->
> |  > Type
> |  >
> |  > This is a real win compared to having one data type for lifted and one
> |  for unlifted values.  But they have the same *representation*: both are
> |  represented by a pointer.
> |  >
> |  > I believe (although the proposal does not aquite say) that the
> |  > proposal fully subsumes the earlier (accepted) proposal for unlifted
> |  > arrays
> |  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> |  > ub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0
> |  > 021-unlifted-array.rst&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ca3
> |  > de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> |  > 7C0%7C636886044859486112&amp;sdata=AHFBdsOZK9zUHPHtL7kuyFG6PIcc5lYFdBO
> |  > Uew%2BMLSE%3D&amp;reserved=0
> |  > So that's good!
> |  >
> |  > This proposal seems like a pretty clear win.   The only downside is (as
> |  so often) that the full types of data types and functions gets a bit more
> |  complicated.  But we've already accepted that with the levity polymorphism
> |  stuff we already have.
> |  >
> |  > Silence = assent 😊
> |  >
> |  > Simon
> |  >
> |  >
> |  > | -----Original Message-----
> |  > | From: ghc-steering-committee
> |  > | <ghc-steering-committee-bounces at haskell.org>
> |  > | On Behalf Of Joachim Breitner
> |  > | Sent: 03 February 2019 14:13
> |  > | To: ghc-steering-committee at haskell.org
> |  > | Subject: [ghc-steering-committee] Please review #203: PtrRep, Shepherd:
> |  > | Simon PJ
> |  > |
> |  > | Dear Committee,
> |  > |
> |  > | this is your secretary speaking:
> |  > |
> |  > | PtrRep has been proposed by Andrew Martin:
> |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> |  > | thub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F203&amp;data=02%7C
> |  > | 01%7Csimonpj%40microsoft.com%7Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72
> |  > | f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112&amp;sdat
> |  > | a=m5ruL8NdOhxWIH%2BpCDvgt%2Fz%2BnEUvip39gZsNjOTN51w%3D&amp;reserved=
> |  > | 0
> |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> |  > | thub.com%2Fandrewthad%2Fghc-&amp;data=02%7C01%7Csimonpj%40microsoft.
> |  > | com%7Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd01
> |  > | 1db47%7C1%7C0%7C636886044859486112&amp;sdata=RZcFrrw8iROwoEVBHxou%2B
> |  > | D41SCZ7pHyNBSicj1vP5tw%3D&amp;reserved=0
> |  > | proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst
> |  > |
> |  > | I propose Simon PJ as the shepherd (he already glimpsed at it, so
> |  > | hopefully already has an opinion.)
> |  > |
> |  > | Please reach consensus as described in
> |  > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> |  > | thub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&amp;dat
> |  > | a=02%7C01%7Csimonpj%40microsoft.com%7Ca3de64d79ccc4d98ebc808d6ac7bc0
> |  > | f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112&a
> |  > | mp;sdata=A5MyvZAJCtdEzs%2B65kPrjG5jihSiLH5kJ1YVCr%2B8ZV0%3D&amp;rese
> |  > | rved=0 I suggest you make a recommendation, in a new e-mail thread
> |  > | with the proposal number in the subject, about the decision, maybe
> |  > | point out debatable points, and assume that anyone who stays quiet
> |  > | agrees with you.
> |  > |
> |  > | Thanks,
> |  > | Joachim
> |  > | --
> |  > | Joachim Breitner
> |  > |   mail at joachim-breitner.de
> |  > |
> |  > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> |  > | .joachim-breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7
> |  > | Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47
> |  > | %7C1%7C0%7C636886044859486112&amp;sdata=hQsVqHn4C8QI46PxWq1H6WGNEWpr
> |  > | PJVXCe4ZpxWo2zw%3D&amp;reserved=0
> |  >
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org
> |  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a
> |  > mp;data=02%7C01%7Csimonpj%40microsoft.com%7Ca3de64d79ccc4d98ebc808d6ac
> |  > 7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112
> |  > &amp;sdata=l2tcX8N2KgdEF4RskU%2BewuzdDwAd38u8odTUqYsD6ww%3D&amp;reserv
> |  > ed=0
> 
> _______________________________________________
> 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/20190319/b8500ea2/attachment.html>

From mail at joachim-breitner.de  Wed Mar 20 08:14:33 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 20 Mar 2019 09:14:33 +0100
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <CALpVSmNpVgrqJVSej39VPWTcAXLAu8hUNyZeaH=LPZrzHNfxyA@mail.gmail.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
 <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
 <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>
 <CALpVSmOy2UgH-3cj_OwO+XdmOxcbMa4Hp99oce8w9UvUDvHggA@mail.gmail.com>
 <A2C6D022-99AD-4C72-937E-F4B946374A1C@cs.brynmawr.edu>
 <CANsrgP+tsNNbttzdyC_7aoojjj_g-PDOFkSMBOafdRAJYiu8aw@mail.gmail.com>
 <DB7PR83MB0298471AE7535DC5335469B5AD4A0@DB7PR83MB0298.EURPRD83.prod.outlook.com>
 <CALpVSmNpVgrqJVSej39VPWTcAXLAu8hUNyZeaH=LPZrzHNfxyA@mail.gmail.com>
Message-ID: <0d93021507b08986a79faeab9e26f0accc52d187.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 20.03.2019, 11:02 +0300 schrieb Vitaly Bragilevsky:
> Joachim, I think we should declare this proposal rejected. We have
> enough voices for this decision it seems.

good point, done with a HT to the original author.

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190320/85f9c007/attachment-0001.sig>

From bravit111 at gmail.com  Wed Mar 20 08:02:00 2019
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Wed, 20 Mar 2019 11:02:00 +0300
Subject: [ghc-steering-committee] #167: Deprecated Entities, rec: accept
In-Reply-To: <DB7PR83MB0298471AE7535DC5335469B5AD4A0@DB7PR83MB0298.EURPRD83.prod.outlook.com>
References: <CALpVSmPKM7=g=_pDEFTUcn4G4ke72xvLcoBp4StrTfh9zmaw-g@mail.gmail.com>
 <CANsrgP+tjOHxMAYt5TAk69aLADE8Y8XC4PgrbZjyx3Vm_1CaSQ@mail.gmail.com>
 <AM0PR83MB02896F787BB1007B984ED634AD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <CALpVSmPCHdT1qk6x-O-ZhYSHea5Fys9tKWa0-LpnNp_wFVwgJQ@mail.gmail.com>
 <AM0PR83MB0289AB1A6321E7FF9DA23FEFAD4D0@AM0PR83MB0289.EURPRD83.prod.outlook.com>
 <57dd7a23207d9ebe6af69378391599304d2aed9d.camel@joachim-breitner.de>
 <CALpVSmOLPZ4VQLSMsrmApHEgMjwKeGqY4tqN_q+vdLnDyzWF5g@mail.gmail.com>
 <A3F85C42-0CDC-419E-952C-FC31BACDDB4E@cs.brynmawr.edu>
 <CALpVSmOy2UgH-3cj_OwO+XdmOxcbMa4Hp99oce8w9UvUDvHggA@mail.gmail.com>
 <A2C6D022-99AD-4C72-937E-F4B946374A1C@cs.brynmawr.edu>
 <CANsrgP+tsNNbttzdyC_7aoojjj_g-PDOFkSMBOafdRAJYiu8aw@mail.gmail.com>
 <DB7PR83MB0298471AE7535DC5335469B5AD4A0@DB7PR83MB0298.EURPRD83.prod.outlook.com>
Message-ID: <CALpVSmNpVgrqJVSej39VPWTcAXLAu8hUNyZeaH=LPZrzHNfxyA@mail.gmail.com>

Joachim, I think we should declare this proposal rejected. We have enough
voices for this decision it seems.

Vitaly

вт, 19 мар. 2019 г. в 21:49, Simon Peyton Jones via ghc-steering-committee <
ghc-steering-committee at haskell.org>:

> I don't think it makes a lot of sense to accept this proposal, since it
> conflicts with the earlier one. Should we instead work on a modification of
> the earlier proposal to extend it to import/export lists, and also resolve
> the debate about *data/pattern/value*?
>
>
>
> Good summary.  We clearly need something that behaves uniformly in the
> five situations Simon describes.  Whether we think of it as “a modification
> of an earlier proposal” or “a  new proposal” doesn’t really matter.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 13 March 2019 13:35
> *To:* Richard Eisenberg <rae at cs.brynmawr.edu>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>;
> Joachim Breitner <mail at joachim-breitner.de>
> *Subject:* Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
> accept
>
>
>
> On Mon, 11 Mar 2019 at 13:26, Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
> "value" would not work as the namespace indicator I envision for the
> future, as it's a commonly used variable name. (I would advocate against
> making it a keyword for this reason.) This knob is relatively easy to turn,
> though, so it's conceivable to use "value" today, and then if/when we start
> using "data" in the future, allow the use of "data" where we use "value",
> eventually deprecating and removing "value". It's a bit annoying to users
> to keep changing it, but only a bit. I've been in this game long enough to
> know that the future isn't quite predictable, and so I see the sense in
> choosing the best thing for us now, leaving the door open to fixing it
> later if necessary. I still advocate for "data", but I won't burst into
> tears if we choose "value".
>
>
>
> I could see waiting a day or two for further commentary and then putting
> it to a committee vote. In the end, I think this choice matters little.
>
>
>
>
>
> For those who (like me) might have been a bit confused about the current
> state of things:
>
>    - There are 5 places that we want namespace specifiers now (possibly
>    more later): import, export, fixity, WARNING, DEPRECATED
>    - GHC's existing *ExplicitNamespaces* option allows *type* and
>    *pattern* keywords to be used in import, export
>    - The earlier proposal Require namespacing fixity declarations for
>    type names and WARNING/DEPRECATED pragmas
>    <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0008-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398072333&sdata=ZDHMErg3a2TOIPwJoDlnFtkzspZDakmTuDrArpqtJEA%3D&reserved=0>
>    was accepted, and allows *type* and *value* keywords in fixity,
>    WARNING, DEPRECATED
>    - This proposal Deprecated Entities
>    <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnineonine%2Fghc-proposals%2Fblob%2Fdepr-entities%2Fproposals%2F0000-deprecated-entities.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398072333&sdata=o2ljHn9Yjn3Ezf%2FPTIIGT48aRSvg6hm22kwIfilr6%2FY%3D&reserved=0>
>    suggests adding *type* and *pattern* specifiers to DEPRECATED pragmas.
>    (note that DEPRECATED pragmas were covered by the earlier proposal, so this
>    conflicts)
>    - Vitaly's suggested modification of this proposal is to  adopt *type*
>    and * data* instead (for DEPRECATED pragmas), while Simon pointed out
>    that we already accepted a proposal for this, using *type* and *value*,
>    and that whatever we do we should do it consistently across import, export,
>    fixity, WARNING, DEPRECATED (yes!)
>
> I don't think it makes a lot of sense to accept this proposal, since it
> conflicts with the earlier one. Should we instead work on a modification of
> the earlier proposal to extend it to import/export lists, and also resolve
> the debate about *data/pattern/value*?
>
>
>
> Richard's concerns about future extensions to add namespacing in
> expressions seem valid to me, it would be unfortunate to use *value* now
> if that will cause problems later.
>
>
>
> Cheers
>
> Simon
>
>
>
>
>
>
>
> Richard
>
>
>
> On Mar 11, 2019, at 9:12 AM, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
>
>
>
> Hi Richard,
>
>
>
> Do you think that using "value" now is a real stopper for the future you
> are talking about? Maybe we should start thinking about making "value" a
> reserved keyword because it suits our purposes best as a namespace
> specifier. It looks like this data/value debate is the only issue before
> reaching the consensus on this proposal. So we have to do something about
> it.
>
>
>
> Regards,
>
> Vitaly
>
>
>
> On Sun, Mar 10, 2019 at 12:10 AM Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
> My argument for `data` is as follows (quoted from earlier writing of mine):
>
>
>
> ---
>
> Though I understand the reasons against it, I'm an unabashed supporter of
> using the word "data" to supplant "pattern". My principal argument is that
> data can be used freely in the syntax, given that it's a keyword that has
> current meaning only as the first lexeme in a top-level declaration.
> (Specifically, I pine for a future where types and terms mix. We can then
> use type and data in the middle of expressions/types to denote
> namespaces.) It also works nicely to mean "data constructor". I agree that
> it doesn't work as well with functions or the potential confusion around
> "data Bool = True | False" (though, in that last example, we can pretend
> hard that the data applies only to the bits after the =).
>
> ---
>
>
>
> In other words, I think `data` is more future-compatible than any of the
> alternatives, even though I agree that `value` flows more smoothly. We can
> think of `data` as meaning "data-level", not "data constructor" (though
> that admittedly takes a bit of mental gymnastics).
>
>
>
> Richard
>
>
>
>
>
> On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
>
>
>
> I think we don't have a consensus on the particular word yet: is it data
> or value. I'd like to listen to Richard who was strongly in favor of data.
> We are in agreement about consistency though.
>
>
>
> Vitaly
>
>
>
>
>
> On Fri, Mar 8, 2019 at 8:45 PM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi,
>
> I fully support this (I thought I brought it up before, but maybe not
> strongly enough).
>
> Should we just include this change in #167? (If politicians can add
> random riders to laws, so can we). Or does it need more thought?
>
> Cheers,
> Joachim
>
>
> Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
> > I also argue that, to be consistent, whatever keyword we agree, we
> should use it
> > In the (accepted) infix/WARNING proposal
> > In import and export lists – presumably for now in addition to
> ‘pattern’, though we might end up deprecating the latter.
> > Simon
> >
> > From: Vitaly Bragilevsky <bravit111 at gmail.com>
> > Sent: 08 March 2019 14:44
> > To: Simon Peyton Jones <simonpj at microsoft.com>
> > Cc: Simon Marlow <marlowsd at gmail.com>; ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
> accept
> >
> > Simon PJ argues for "value" over "data" as a specifier:
> https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F167%23issuecomment-470947193&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398082326&sdata=bap1ILHXYU%2Bxblq5N3DapBvpr5Se3TdNiwLi8kHT3I0%3D&reserved=0>
> >
> > I'm fine with this choice either (and I'm satisfied with the argument
> that deprecating or setting fixity for value "value" is a rare case to be
> considered seriously). If you have another opinion, please, speak up.
> >
> > Vitaly
> >
> > On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
> > > I’ve made a post on the proposal thread asking why we don’t just
> follow the already-adopted proposal for WARNING and infix pragmas.
> > >
> > > Simon
> > >
> > > From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
> > > Sent: 08 March 2019 07:57
> > > To: Vitaly Bragilevsky <bravit111 at gmail.com>
> > > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
> accept
> > >
> > > Yes, I think this is the right way to go.
> > >
> > > Cheers
> > > Simon
> > >
> > > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
> > > > Hi everyone,
> > > >
> > > > I was asked to shepherd the proposal #167 (Deprecated Entities,
> https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnineonine%2Fghc-proposals%2Fblob%2Fdepr-entities%2Fproposals%2F0000-deprecated-entities.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398082326&sdata=V%2Bgqa%2FslqR01WIiGKDyuXFSYqp4RkFdbHcB6G1l2l1w%3D&reserved=0>).
> It is proposed to extend (nonpositional) DEPRECATED pragma with the two
> specifiers to disambiguate deprecating named type-level and value-level
> things. In its current formulation, the proposal suggests to use the
> specifiers "type" for type-level things and "pattern" for value-level
> things as follows:
> > > >
> > > > data Bar = Bar
> > > > {-# DEPRECATED type Bar "Don't use type Bar" #-}
> > > > data Baz = Baz
> > > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
> > > >
> > > > Using this pragma without specifiers should mean deprecating both
> (as is works now).
> > > >
> > > > After discussing this proposal within the committee (see
> https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-February%2F000894.html&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398092323&sdata=YTuIVN7wsC%2FmzJ51PH2RGCPLiecKhvkEFO0Ug3Aq7fg%3D&reserved=0>),
> I recommend acceptance with one change, namely using "data" instead of
> "pattern" for deprecating value-level things.
> > > >
> > > > Reasons for choosing "data":
> > > > * it's a reserved keyword (as opposed to "value", which is another
> option)
> > > > * we are deprecating data constructors here
> > > > * it just feels right (sorry!)
> > > >
> > > > Reasons against "data":
> > > > * it can be confusing whether we mean data type or data constructor
> > > > * we use "value" and "pattern" in other places meaning basically the
> same thing
> > > >
> > > > If the committee decides to go this way, then the wider community
> may think about other proposals, such as
> > > > * adding positional DEPRECATED pragmas (including class instances
> deprecation)
> > > > * fixing inconsistencies with the fixity declarations (
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0008-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398092323&sdata=ktRl25ulQKFOI7cxTFabP0wTcg7C9g77LzxPO1riyVs%3D&reserved=0>)
> and updating ExplicitNamespaces in import/export lists
> > > > * deprecating usage of nonpositional DEPRECATED pragma without the
> specifiers
> > > >
> > > > Silence is understood as agreement.
> > > >
> > > > Regards,
> > > > Vitaly
> > > >
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398102314&sdata=VC3xfGC13FRwTHAklISNNhA1rcoql3OZVTPDkUddWGY%3D&reserved=0>
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398102314&sdata=VC3xfGC13FRwTHAklISNNhA1rcoql3OZVTPDkUddWGY%3D&reserved=0>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398112311&sdata=uuKaUz37cFsSoxYHkKX%2Ba2DoSTUtw50aMrga5FCW8LE%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398112311&sdata=ngNXSvxU3dcuQq0SOQZf8DNtP5Sz4sGbg9Y2eSu%2BeIo%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398122306&sdata=Oyy8xoNizqkTE4RovIMahuiWA6hvoVtib0S%2FgLStY0c%3D&reserved=0>
>
>
>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398122306&sdata=Oyy8xoNizqkTE4RovIMahuiWA6hvoVtib0S%2FgLStY0c%3D&reserved=0>
>
> _______________________________________________
> 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/20190320/08f4d150/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue Mar 26 17:17:19 2019
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 26 Mar 2019 10:17:19 -0700
Subject: [ghc-steering-committee] Discussion on #155 Type Variable in
	Labmdas
In-Reply-To: <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
Message-ID: <CAGK9nurqdZA3Zr3UXSVz9bdeThxH96RgsXu=-mDzukOLmdY6JQ@mail.gmail.com>

Hello,

On Sun, Mar 3, 2019 at 5:44 PM Eric Seidel <eric at seidel.io> wrote:

> One argument in favor of the proposal that I don't believe I've seen
> mentioned is that, now that we can explicitly apply types with the @
> syntax, it feels very intuitive to also bind them with the same syntax. So
> even if this proposal does not add much technically over
> ScopedTypeVariables, I think it's still a good idea.
>

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.

-Iavor


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190326/16d98c61/attachment.html>

From eric at seidel.io  Wed Mar 27 01:47:41 2019
From: eric at seidel.io (Eric Seidel)
Date: Tue, 26 Mar 2019 21:47:41 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Discussion_on_=23155_Type_Vari?=
 =?utf-8?q?able_in_Labmdas?=
In-Reply-To: <CAGK9nurqdZA3Zr3UXSVz9bdeThxH96RgsXu=-mDzukOLmdY6JQ@mail.gmail.com>
References: <CAGK9nuoHUJLq=OxQ9gZePNnEsvRPtw5f7s6mc-NCYVavpxw=SQ@mail.gmail.com>
 <CAGK9nups7=_tH9omDi2DCT84rskBqRp0oe_omxG23hy0N7TnCw@mail.gmail.com>
 <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com>
 <CAGK9nurqdZA3Zr3UXSVz9bdeThxH96RgsXu=-mDzukOLmdY6JQ@mail.gmail.com>
Message-ID: <5b7eb5a6-d961-43b2-a93d-96d23798413a@www.fastmail.com>

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

From mail at joachim-breitner.de  Fri Mar 29 23:23:19 2019
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 30 Mar 2019 00:23:19 +0100
Subject: [ghc-steering-committee] Please review #177: Simple constrained
 type families, Shepherd: Vitaly
Message-ID: <6f575250c72e2c1a21f52ce944c0e84da866be5b.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Simple constrained type families
has been proposed by Alex Williams
https://github.com/ghc-proposals/ghc-proposals/pull/117
https://github.com/typedrat/ghc-proposals/blob/constrained-type-families/proposals/0000-simple-constrained-type-families.rst

I propose Vitaly as the Shepherd.

Please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process
I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190330/c70aefc6/attachment.sig>