From rae at cs.brynmawr.edu  Mon Jul  2 12:25:48 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 2 Jul 2018 08:25:48 -0400
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <D2B9F8E7-4327-4434-850B-64E84A2024E7@cs.brynmawr.edu>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
 <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
 <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>
 <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de>
 <CAGK9nupt_1uc5V1pqeH69jRqoJZ74ojP=iLPg9VXy+r7f_r5FQ@mail.gmail.com>
 <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu>
 <AM5PR83MB01635CBB0899A45249AA73B4AD690@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nur9HO1Avi52WbKUAk4yKfUJgVRh_0KrAfin+48ezZAa=g@mail.gmail.com>
 <D780D81C-1032-41B6-B1C4-6B6151A53879@cs.brynmawr.edu>
 <CAGK9nupTaBXBQmCjN0Cr7bEG2P6GqxSBQBp0SS-jhzJzaKC0aQ@mail.gmail.com>
 <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu>
 <AM6PR83MB03095B896EEE6E3800113F78AD4F0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <CAGK9nuqfiTwf50W0aJg0ToxBkU1hU8tH-vYMO7erMEJr3SzvNA@mail.gmail.com>
 <AM0PR83MB0308B72F7C6B3EECD7D67739AD430@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <D2B9F8E7-4327-4434-850B-64E84A2024E7@cs.brynmawr.edu>
Message-ID: <2200FAEC-EDE0-432F-8F21-53AF18FD3991@cs.brynmawr.edu>

Yes -- it's a property of the type. This aspect wasn't highlighted in the original proposal because it's not a change. Types *already* have this inferred/specified distinction (and have since GHC 8.0), but users can't directly access the feature. This proposal is all about -- and only about -- concrete syntax.

Richard


From iavor.diatchki at gmail.com  Mon Jul  2 17:00:06 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 2 Jul 2018 10:00:06 -0700
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <2200FAEC-EDE0-432F-8F21-53AF18FD3991@cs.brynmawr.edu>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
 <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
 <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>
 <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de>
 <CAGK9nupt_1uc5V1pqeH69jRqoJZ74ojP=iLPg9VXy+r7f_r5FQ@mail.gmail.com>
 <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu>
 <AM5PR83MB01635CBB0899A45249AA73B4AD690@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nur9HO1Avi52WbKUAk4yKfUJgVRh_0KrAfin+48ezZAa=g@mail.gmail.com>
 <D780D81C-1032-41B6-B1C4-6B6151A53879@cs.brynmawr.edu>
 <CAGK9nupTaBXBQmCjN0Cr7bEG2P6GqxSBQBp0SS-jhzJzaKC0aQ@mail.gmail.com>
 <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu>
 <AM6PR83MB03095B896EEE6E3800113F78AD4F0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <CAGK9nuqfiTwf50W0aJg0ToxBkU1hU8tH-vYMO7erMEJr3SzvNA@mail.gmail.com>
 <AM0PR83MB0308B72F7C6B3EECD7D67739AD430@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <D2B9F8E7-4327-4434-850B-64E84A2024E7@cs.brynmawr.edu>
 <2200FAEC-EDE0-432F-8F21-53AF18FD3991@cs.brynmawr.edu>
Message-ID: <CAGK9nup-HL3p+gYyuwY4iBfZ5Ot=566zYWTsWc2NfO1PvpRCpw@mail.gmail.com>

OK, it sounds like we've worked out all the kinks, so I'll mark this as
accept and merge it in.



On Mon, Jul 2, 2018 at 5:25 AM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> Yes -- it's a property of the type. This aspect wasn't highlighted in the
> original proposal because it's not a change. Types *already* have this
> inferred/specified distinction (and have since GHC 8.0), but users can't
> directly access the feature. This proposal is all about -- and only about
> -- concrete syntax.
>
> Richard
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180702/a686ad50/attachment.html>

From simonpj at microsoft.com  Mon Jul  2 08:49:05 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 2 Jul 2018 08:49:05 +0000
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <CAGK9nuqfiTwf50W0aJg0ToxBkU1hU8tH-vYMO7erMEJr3SzvNA@mail.gmail.com>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
 <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
 <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>
 <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de>
 <CAGK9nupt_1uc5V1pqeH69jRqoJZ74ojP=iLPg9VXy+r7f_r5FQ@mail.gmail.com>
 <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu>
 <AM5PR83MB01635CBB0899A45249AA73B4AD690@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nur9HO1Avi52WbKUAk4yKfUJgVRh_0KrAfin+48ezZAa=g@mail.gmail.com>
 <D780D81C-1032-41B6-B1C4-6B6151A53879@cs.brynmawr.edu>
 <CAGK9nupTaBXBQmCjN0Cr7bEG2P6GqxSBQBp0SS-jhzJzaKC0aQ@mail.gmail.com>
 <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu>
 <AM6PR83MB03095B896EEE6E3800113F78AD4F0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <CAGK9nuqfiTwf50W0aJg0ToxBkU1hU8tH-vYMO7erMEJr3SzvNA@mail.gmail.com>
Message-ID: <AM0PR83MB0308B72F7C6B3EECD7D67739AD430@AM0PR83MB0308.EURPRD83.prod.outlook.com>

It really is not quite clear if the specificity is a property of the type itself, or the thing that has that type.
I think Richard has clarified now, right?  It’s a property of a type.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 29 June 2018 19:26
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}

I am supportive of accepting the proposal, but I think that we should address the point raised by Joachim on the the git-hub thread first  (https://github.com/ghc-proposals/ghc-proposals/pull/99#issuecomment-401060976<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F99%23issuecomment-401060976&data=02%7C01%7Csimonpj%40microsoft.com%7C895db05b58cc4765bd7808d5ddedc70f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636658935675847308&sdata=FqRb6%2F0hnMfQ8Bx%2BRtJdlR9VTe5Dk%2Bx6wjlin5x9x5s%3D&reserved=0>). It really is not quite clear if the specificity is a property of the type itself, or the thing that has that type.




On Thu, Jun 28, 2018 at 1:07 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I’m keen on this proposal. I am very keen to be able to express in a type or kind signature everything needful to use the value (or type constructor).   The proposal gives an example at the term level.  It’d be strengthened by an example at the type level.  Eg

type T1 :: forall {k}. (k->Type) -> k -> Type

data T1 f a = MkT (f a)



type T2 :: forall k. (k->Type) -> k -> Type

data T2 f (a::k) = MkT2 (f a)

Here T1 has an inferred kind variable, mentioned nowhere in the declaration.  The kind signature (which I have written as if it were code, which is the subject of a separate proposal) is inferred as shown.

T2 mentions k, so its kind signature looks a bit different.

What’s the difference?  It’s exactly in explicit kind application. You can write  (T1 @Type Maybe Int), but T2 can’t have that explicit kind argument.

The whole business of Required/Specified/Inferred is more complicated than I like, but if we have it (which we do right now) we should allow the programmer to specify exactly what they mean.

(An alternative is to abolish the Specified/Inferred distinction, but that carries significant costs of its own and no one is proposing it.)

Let’s accept!

Simon

From: Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>>
Sent: 28 June 2018 05:45
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; 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] Discussion on proposal #99: forall {k}

But we morally *do* have explicit kind application. See accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0015-type-level-type-applications.rst<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0015-type-level-type-applications.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C15fcb1b642114e05f1a808d5dcb1e5ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636657578984502957&sdata=%2B7wS%2F75AielivG1KfFAzGPXKSS5aHOtEVwy9Q6WyYLU%3D&reserved=0>  So the only reason that we don't have it is that GHC hasn't caught up to its specification. (I have a student working on this now.)

The reason that T2 and T3 are different here is that T2 mentions the k in the type declaration, while T3 mentions it only in the constructor declaration.

Richard

On Jun 26, 2018, at 6:52 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,
thanks for the revisions---I read through the new version, and I think I almost understand the plan.   I would say that for this proposal it makes more sense to just deal with explicit specificities at the value level, and never have the curly braces in type constructors.   Since we don't have an explicit kind application at the type level (e.g., we can't write `Proxy @Type`), I don't think it really makes sense to add the braces to type constructors.   If we ever implemented THAT feature, then we can discuss which declarations should have explicit and which should have implicit parameters.  In the current set of examples, I find it odd that `T2` does not have braces, but `T3` does.

-Iavor






On Wed, Jun 20, 2018 at 2:15 PM Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
I have posted the new proposal, at https://github.com/ghc-proposals/ghc-proposals/pull/148<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F148&data=02%7C01%7Csimonpj%40microsoft.com%7C15fcb1b642114e05f1a808d5dcb1e5ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636657578984502957&sdata=RQ4V%2FWdRz009o6sieAUpx7wQ6RCqWydsQGbENvHFZfM%3D&reserved=0>

I've also updated #99 to clarify where the new syntax is allowed.

For Iavor's examples:

data T1 a = C1 a

type T1 :: Type -> Type
C1 :: forall a. a -> T1 a

data T2 (a :: k) = C2 { f2 :: Proxy a }

type T2 :: forall k. k -> Type
C2 :: forall k (a :: k). Proxy a -> T2 a
f2 :: forall k (a :: k). T2 a -> Proxy a

data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a

type T3 :: forall {k}. k -> Type
C3 :: forall k (a :: k). Proxy a -> T3 a

data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a

type T4 :: forall {k}. k -> Type
C4 :: forall {k} (a :: k). Proxy a -> T3 a

data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a

Rejected, as k is used dependently but is not lexically dependent. (This is no change.) It we have

> data T5 k (a :: k) where C5 :: forall k (a :: k). Proxy a -> T5 k a

we would get

type T5 :: forall k -> k -> Type
C5 :: forall k (a :: k). Proxy a -> T5 k a

data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a

Rejected, like T6. If we revise to:

> data T6 k (a :: k) where C6 :: forall {k} (a::k). Proxy a -> T6 k a

we get

type T6 :: forall k -> k -> Type
C6 :: forall {k} (a::k). Proxy a -> T6 k a

I've updated the proposal itself to include these examples.

Does this help to clarify?

Richard

On May 25, 2018, at 1:56 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,

well, I thought that Richard was going to write a new proposal based on the feedback here, but it sounds like he is planning to revise #99, and then write a separate new one.    I guess we should discuss the proposal again once the changes are in.   I would encourage Richard to add some text and examples to clarify exactly what's in the proposal and what's not, and how things are supposed to work.  Here are some examples, for which it would be illuminating (to me) to see the types/kinds of all names introduced.

data T1 a = C1 a
data T2 (a :: k) = C2 { f2 :: Proxy a }
data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a
data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a
data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a
data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a

-Iavor


On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I’m keen to get #99 into GHC in some form.

My motivation (which could be a fourth bullet in the proposal) is that it should be possible for a programmer to write a fully-explicit type signature for anything GHC can infer.  But currently we can’t.  For typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it down.

based on the discussion so far, it seems that #99 in its current form might not be exactly what we want

Can you summarise the reasons it might not be exactly what we want?

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: 24 May 2018 21:17
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] Discussion on proposal #99: forall {k}

I do plan on turning Joachim's recent suggestion into a separate proposal, and then to modify #99. But the modification would remove only the bit about classes, not the feature overall. I don't have time to do this now, though -- will do next week.

Richard

On May 24, 2018, at 1:54 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,

based on the discussion so far, it seems that #99 in its current form might not be exactly what we want, so I'd say that we should reject it for the moment.   Overall, I agree that it would be nice to come up with a consistent notation for things that are currently happening in GHC but we can't write, so perhaps we could revisit this with a revised proposal at a later time?

-Iavor




On Sat, May 5, 2018 at 8:48 PM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg:
> Joachim, you are always a fount of interesting ideas.
>
> > On May 2, 2018, at 2:51 PM, Joachim Breitner <mail at joachim-breitner
> > .de> wrote:
> >
> >   class C k (a : k) where meth :: a
> >   meth :: forall {k} a. C k a -> k -> Constraint
>
> I think this is brilliant. But not only for this proposal! Imagine
> this:
>
> class Num a where
>   fromInteger :: Integer -> a
>
> fromInteger :: Integer -> forall a. Num a => a
>
> If we do that, then #129 is essentially solved, at no further cost to
> anyone. (Note that in all Haskell98-style code, no one will ever be
> able to notice the changed type of fromInteger.)
>
> This approach also allows for the possibility of reordering
> quantified type variables for Haskell98-style constructors, if anyone
> should want to do it.
>
> And it allows for updated types (including quantified variable
> ordering, etc.) for record selectors.
>
> And it allows (maybe?) for giving good types to GADT record
> selectors:
>
> data X a where
>   Foo :: { bar :: Int } -> X Int
>   Quux :: { bar :: Bool } -> X Bool
> bar :: X a -> a
>
> GHC currently rejects the declaration for X, but it could be accepted
> if only we could specify the correct type of bar. And now we can. I
> don't particularly want to cook up the typing rules here, but I don't
> think I'm totally crazy.
>
> GADT record selectors aside, the rule for these could be that the
> top-level type signature must be equivalent w.r.t. the subtype
> relation with the original type signature. That is, if the new
> signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy
> enough to check for. The implementation would probably do a little
> worker/wrapper stunt.

I smell a new proposal… what does this mean for #99? Will you want to
revise it?

Cheers,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca43c362fd18e4163aeba08d5c1b34be2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636627898179266033&sdata=1cwPEVKXCcP3DuCHXOFuA%2BbEBniRLjcKI%2BAZji5vR4Q%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
_______________________________________________
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/20180702/632afac5/attachment-0001.html>

From simonpj at microsoft.com  Mon Jul  2 12:25:45 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 2 Jul 2018 12:25:45 +0000
Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k}
In-Reply-To: <D2B9F8E7-4327-4434-850B-64E84A2024E7@cs.brynmawr.edu>
References: <CAGK9nuqSLUuf6FuzDHhr0PofG=KpjRVGee0J_j2LU+p4kt76rg@mail.gmail.com>
 <AM5PR83MB01638A81718CBB12CA0BCE45AD810@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nuqEyHcrt9YZoMg+kawhNJ8jH7YFRyf1cJDNYyVgaMYsLw@mail.gmail.com>
 <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu>
 <ad6d92eb536d12c18fc79bdf27a16ecfa6b3f115.camel@joachim-breitner.de>
 <D79E106D-D788-4FEC-8388-A6EFDD6B7AF4@cs.brynmawr.edu>
 <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de>
 <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu>
 <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de>
 <CAGK9nupt_1uc5V1pqeH69jRqoJZ74ojP=iLPg9VXy+r7f_r5FQ@mail.gmail.com>
 <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu>
 <AM5PR83MB01635CBB0899A45249AA73B4AD690@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nur9HO1Avi52WbKUAk4yKfUJgVRh_0KrAfin+48ezZAa=g@mail.gmail.com>
 <D780D81C-1032-41B6-B1C4-6B6151A53879@cs.brynmawr.edu>
 <CAGK9nupTaBXBQmCjN0Cr7bEG2P6GqxSBQBp0SS-jhzJzaKC0aQ@mail.gmail.com>
 <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu>
 <AM6PR83MB03095B896EEE6E3800113F78AD4F0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <CAGK9nuqfiTwf50W0aJg0ToxBkU1hU8tH-vYMO7erMEJr3SzvNA@mail.gmail.com>
 <AM0PR83MB0308B72F7C6B3EECD7D67739AD430@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <D2B9F8E7-4327-4434-850B-64E84A2024E7@cs.brynmawr.edu>
Message-ID: <AM0PR83MB030809F3EAACA7253441D661AD430@AM0PR83MB0308.EURPRD83.prod.outlook.com>

It’s already present in the implementation, but it’s not already present in any explicitly-stated language proposal. So this proposal might be a good opportunity to fix that deficiency.

S

From: Richard Eisenberg <rae at cs.brynmawr.edu>
Sent: 02 July 2018 13:23
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Iavor Diatchki <iavor.diatchki at gmail.com>; ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}

Yes -- it's a property of the type. This aspect wasn't highlighted in the original proposal because it's not a change. Types *already* have this inferred/specified distinction (and have since GHC 8.0), but users can't directly access the feature. This proposal is all about -- and only about -- concrete syntax.

Richard


On Jul 2, 2018, at 4:49 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

It really is not quite clear if the specificity is a property of the type itself, or the thing that has that type.
I think Richard has clarified now, right?  It’s a property of a type.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Sent: 29 June 2018 19:26
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:ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k}

I am supportive of accepting the proposal, but I think that we should address the point raised by Joachim on the the git-hub thread first  (https://github.com/ghc-proposals/ghc-proposals/pull/99#issuecomment-401060976<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F99%23issuecomment-401060976&data=02%7C01%7Csimonpj%40microsoft.com%7C895db05b58cc4765bd7808d5ddedc70f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636658935675847308&sdata=FqRb6%2F0hnMfQ8Bx%2BRtJdlR9VTe5Dk%2Bx6wjlin5x9x5s%3D&reserved=0>). It really is not quite clear if the specificity is a property of the type itself, or the thing that has that type.




On Thu, Jun 28, 2018 at 1:07 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I’m keen on this proposal. I am very keen to be able to express in a type or kind signature everything needful to use the value (or type constructor).   The proposal gives an example at the term level.  It’d be strengthened by an example at the type level.  Eg

type T1 :: forall {k}. (k->Type) -> k -> Type

data T1 f a = MkT (f a)



type T2 :: forall k. (k->Type) -> k -> Type

data T2 f (a::k) = MkT2 (f a)

Here T1 has an inferred kind variable, mentioned nowhere in the declaration.  The kind signature (which I have written as if it were code, which is the subject of a separate proposal) is inferred as shown.

T2 mentions k, so its kind signature looks a bit different.

What’s the difference?  It’s exactly in explicit kind application. You can write  (T1 @Type Maybe Int), but T2 can’t have that explicit kind argument.

The whole business of Required/Specified/Inferred is more complicated than I like, but if we have it (which we do right now) we should allow the programmer to specify exactly what they mean.

(An alternative is to abolish the Specified/Inferred distinction, but that carries significant costs of its own and no one is proposing it.)

Let’s accept!

Simon

From: Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>>
Sent: 28 June 2018 05:45
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; 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] Discussion on proposal #99: forall {k}

But we morally *do* have explicit kind application. See accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0015-type-level-type-applications.rst<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0015-type-level-type-applications.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C15fcb1b642114e05f1a808d5dcb1e5ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636657578984502957&sdata=%2B7wS%2F75AielivG1KfFAzGPXKSS5aHOtEVwy9Q6WyYLU%3D&reserved=0>  So the only reason that we don't have it is that GHC hasn't caught up to its specification. (I have a student working on this now.)

The reason that T2 and T3 are different here is that T2 mentions the k in the type declaration, while T3 mentions it only in the constructor declaration.

Richard

On Jun 26, 2018, at 6:52 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,
thanks for the revisions---I read through the new version, and I think I almost understand the plan.   I would say that for this proposal it makes more sense to just deal with explicit specificities at the value level, and never have the curly braces in type constructors.   Since we don't have an explicit kind application at the type level (e.g., we can't write `Proxy @Type`), I don't think it really makes sense to add the braces to type constructors.   If we ever implemented THAT feature, then we can discuss which declarations should have explicit and which should have implicit parameters.  In the current set of examples, I find it odd that `T2` does not have braces, but `T3` does.

-Iavor






On Wed, Jun 20, 2018 at 2:15 PM Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
I have posted the new proposal, at https://github.com/ghc-proposals/ghc-proposals/pull/148<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F148&data=02%7C01%7Csimonpj%40microsoft.com%7C15fcb1b642114e05f1a808d5dcb1e5ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636657578984502957&sdata=RQ4V%2FWdRz009o6sieAUpx7wQ6RCqWydsQGbENvHFZfM%3D&reserved=0>

I've also updated #99 to clarify where the new syntax is allowed.

For Iavor's examples:

data T1 a = C1 a

type T1 :: Type -> Type
C1 :: forall a. a -> T1 a

data T2 (a :: k) = C2 { f2 :: Proxy a }

type T2 :: forall k. k -> Type
C2 :: forall k (a :: k). Proxy a -> T2 a
f2 :: forall k (a :: k). T2 a -> Proxy a

data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a

type T3 :: forall {k}. k -> Type
C3 :: forall k (a :: k). Proxy a -> T3 a

data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a

type T4 :: forall {k}. k -> Type
C4 :: forall {k} (a :: k). Proxy a -> T3 a

data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a

Rejected, as k is used dependently but is not lexically dependent. (This is no change.) It we have

> data T5 k (a :: k) where C5 :: forall k (a :: k). Proxy a -> T5 k a

we would get

type T5 :: forall k -> k -> Type
C5 :: forall k (a :: k). Proxy a -> T5 k a

data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a

Rejected, like T6. If we revise to:

> data T6 k (a :: k) where C6 :: forall {k} (a::k). Proxy a -> T6 k a

we get

type T6 :: forall k -> k -> Type
C6 :: forall {k} (a::k). Proxy a -> T6 k a

I've updated the proposal itself to include these examples.

Does this help to clarify?

Richard

On May 25, 2018, at 1:56 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,

well, I thought that Richard was going to write a new proposal based on the feedback here, but it sounds like he is planning to revise #99, and then write a separate new one.    I guess we should discuss the proposal again once the changes are in.   I would encourage Richard to add some text and examples to clarify exactly what's in the proposal and what's not, and how things are supposed to work.  Here are some examples, for which it would be illuminating (to me) to see the types/kinds of all names introduced.

data T1 a = C1 a
data T2 (a :: k) = C2 { f2 :: Proxy a }
data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a
data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a
data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a
data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a

-Iavor


On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I’m keen to get #99 into GHC in some form.

My motivation (which could be a fourth bullet in the proposal) is that it should be possible for a programmer to write a fully-explicit type signature for anything GHC can infer.  But currently we can’t.  For typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it down.

based on the discussion so far, it seems that #99 in its current form might not be exactly what we want

Can you summarise the reasons it might not be exactly what we want?

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: 24 May 2018 21:17
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] Discussion on proposal #99: forall {k}

I do plan on turning Joachim's recent suggestion into a separate proposal, and then to modify #99. But the modification would remove only the bit about classes, not the feature overall. I don't have time to do this now, though -- will do next week.

Richard

On May 24, 2018, at 1:54 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,

based on the discussion so far, it seems that #99 in its current form might not be exactly what we want, so I'd say that we should reject it for the moment.   Overall, I agree that it would be nice to come up with a consistent notation for things that are currently happening in GHC but we can't write, so perhaps we could revisit this with a revised proposal at a later time?

-Iavor




On Sat, May 5, 2018 at 8:48 PM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg:
> Joachim, you are always a fount of interesting ideas.
>
> > On May 2, 2018, at 2:51 PM, Joachim Breitner <mail at joachim-breitner
> > .de> wrote:
> >
> >   class C k (a : k) where meth :: a
> >   meth :: forall {k} a. C k a -> k -> Constraint
>
> I think this is brilliant. But not only for this proposal! Imagine
> this:
>
> class Num a where
>   fromInteger :: Integer -> a
>
> fromInteger :: Integer -> forall a. Num a => a
>
> If we do that, then #129 is essentially solved, at no further cost to
> anyone. (Note that in all Haskell98-style code, no one will ever be
> able to notice the changed type of fromInteger.)
>
> This approach also allows for the possibility of reordering
> quantified type variables for Haskell98-style constructors, if anyone
> should want to do it.
>
> And it allows for updated types (including quantified variable
> ordering, etc.) for record selectors.
>
> And it allows (maybe?) for giving good types to GADT record
> selectors:
>
> data X a where
>   Foo :: { bar :: Int } -> X Int
>   Quux :: { bar :: Bool } -> X Bool
> bar :: X a -> a
>
> GHC currently rejects the declaration for X, but it could be accepted
> if only we could specify the correct type of bar. And now we can. I
> don't particularly want to cook up the typing rules here, but I don't
> think I'm totally crazy.
>
> GADT record selectors aside, the rule for these could be that the
> top-level type signature must be equivalent w.r.t. the subtype
> relation with the original type signature. That is, if the new
> signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy
> enough to check for. The implementation would probably do a little
> worker/wrapper stunt.

I smell a new proposal… what does this mean for #99? Will you want to
revise it?

Cheers,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca43c362fd18e4163aeba08d5c1b34be2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636627898179266033&sdata=1cwPEVKXCcP3DuCHXOFuA%2BbEBniRLjcKI%2BAZji5vR4Q%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
_______________________________________________
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/20180702/cf76bce6/attachment-0001.html>

From ben at well-typed.com  Mon Jul  2 21:02:05 2018
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 02 Jul 2018 17:02:05 -0400
Subject: [ghc-steering-committee] Remove TypeOperators => NoStarIsType
	"migration" (#146); Recommendation: accept
In-Reply-To: <87wounvti9.fsf@smart-cactus.org>
References: <87wounvti9.fsf@smart-cactus.org>
Message-ID: <871scltkqc.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Hi everyone,
>
> We are being asked to consider pull request #146. This proposal is an
> amendment to the accepted Proposal 0020 [1], removing a migration
> mechanism which was found in practice to hurt more than help.
>
If anyone has any objection do say so. If none is expressed in the next
two days I will merge.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180702/7382345c/attachment.sig>

From mail at joachim-breitner.de  Tue Jul  3 22:58:02 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 03 Jul 2018 18:58:02 -0400
Subject: [ghc-steering-committee] Please Review: Replace atomicModifyMutVar#
 (#149), Shepherd: Simon Marlow
Message-ID: <7db6bbcdc16428489ea92a3a748886752094cb3b.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Replace atomicModifyMutVar# (#149) by David Feuer was proposed.
https://github.com/ghc-proposals/ghc-proposals/pull/149

I propose Simon Marlow as the shepherd, because this is RTS-land.

Simon, 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/20180703/0f921881/attachment.sig>

From marlowsd at gmail.com  Wed Jul  4 09:19:28 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 4 Jul 2018 10:19:28 +0100
Subject: [ghc-steering-committee] Replace atomicModifyMutVar# (#149),
	recommendation: accept
Message-ID: <CANsrgPLrQSi4Dqet1HoXtAtXQ6oUGf2HTsJ3_+1p1W1E1-rNuw@mail.gmail.com>

https://github.com/ghc-proposals/ghc-proposals/pull/149

This proposal is essentially an optimisation to the atomicModifyMutVar#
primitive. I won't repeat the details here, but it amounts to moving one of
the thunks produced by atomicModifyMutVar# out of the primop and into the
atomicModifyIORef wrapper. The advantage is that in the case of the strict
version of the wrapper, atomicModifyIORef', this extra thunk is eliminated
entirely, rather than being created by the primop and then immediately
evaluated by the wrapper.

I propose we accept the proposal to add the new primop in section 2.1,
along with the straightforward additions proposed in sections 2.2 and 2.3.
(the old primop will be removed, but can be defined in GHC.Exts  as a
wrapper around the new primop for backwards compat)

However, the additions to the Data.IORef library should be considered by
the libraries committee separately. (there are naming issues to be resolved
in particular).

Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180704/3fb0fdfc/attachment.html>

From simonpj at microsoft.com  Thu Jul  5 15:24:13 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 5 Jul 2018 15:24:13 +0000
Subject: [ghc-steering-committee] Replace atomicModifyMutVar# (#149),
	recommendation: accept
In-Reply-To: <CANsrgPLrQSi4Dqet1HoXtAtXQ6oUGf2HTsJ3_+1p1W1E1-rNuw@mail.gmail.com>
References: <CANsrgPLrQSi4Dqet1HoXtAtXQ6oUGf2HTsJ3_+1p1W1E1-rNuw@mail.gmail.com>
Message-ID: <AM0PR83MB030858C64832074A871140D2AD400@AM0PR83MB0308.EURPRD83.prod.outlook.com>

It sounds good to me – I have not dug into the details but it seems to have had enough scrutiny.

Note that it replaces one primop with another, with the old one being re-defined as an ordinary function for back-compat.   The proposal does not just add an extra primop.  Right?

I’m supportive, albeit not very well informed.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 04 July 2018 10:19
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Replace atomicModifyMutVar# (#149), recommendation: accept

https://github.com/ghc-proposals/ghc-proposals/pull/149<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F149&data=02%7C01%7Csimonpj%40microsoft.com%7Caf6991e741df405fd5a308d5e18f477f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662927862631135&sdata=biPMT2Nj9w7jJHUSdHU3eaHMS9wOzIbm7w%2B6txXLpeE%3D&reserved=0>

This proposal is essentially an optimisation to the atomicModifyMutVar# primitive. I won't repeat the details here, but it amounts to moving one of the thunks produced by atomicModifyMutVar# out of the primop and into the atomicModifyIORef wrapper. The advantage is that in the case of the strict version of the wrapper, atomicModifyIORef', this extra thunk is eliminated entirely, rather than being created by the primop and then immediately evaluated by the wrapper.

I propose we accept the proposal to add the new primop in section 2.1, along with the straightforward additions proposed in sections 2.2 and 2.3. (the old primop will be removed, but can be defined in GHC.Exts  as a wrapper around the new primop for backwards compat)

However, the additions to the Data.IORef library should be considered by the libraries committee separately. (there are naming issues to be resolved in particular).

Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180705/c16d1444/attachment.html>

From marlowsd at gmail.com  Thu Jul  5 18:40:46 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 5 Jul 2018 19:40:46 +0100
Subject: [ghc-steering-committee] Replace atomicModifyMutVar# (#149),
 recommendation: accept
In-Reply-To: <AM0PR83MB030858C64832074A871140D2AD400@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <CANsrgPLrQSi4Dqet1HoXtAtXQ6oUGf2HTsJ3_+1p1W1E1-rNuw@mail.gmail.com>
 <AM0PR83MB030858C64832074A871140D2AD400@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CANsrgPJ6Ljnaw+u7GJbqjOJ_cnZ3j0UEi4nxFH2c9Y+hycHWCw@mail.gmail.com>

On 5 July 2018 at 16:24, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> It sounds good to me – I have not dug into the details but it seems to
> have had enough scrutiny.
>
>
>
> Note that it *replaces one primop with another*, with the old one being
> re-defined as an ordinary function for back-compat.   The proposal does not
> just add an extra primop.  Right?
>
>
Yes, that's right.

Simon


>
>
> I’m supportive, albeit not very well informed.
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 04 July 2018 10:19
> *To:* ghc-steering-committee at haskell.org
> *Subject:* [ghc-steering-committee] Replace atomicModifyMutVar# (#149),
> recommendation: accept
>
>
>
> https://github.com/ghc-proposals/ghc-proposals/pull/149
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F149&data=02%7C01%7Csimonpj%40microsoft.com%7Caf6991e741df405fd5a308d5e18f477f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662927862631135&sdata=biPMT2Nj9w7jJHUSdHU3eaHMS9wOzIbm7w%2B6txXLpeE%3D&reserved=0>
>
>
>
> This proposal is essentially an optimisation to the atomicModifyMutVar#
> primitive. I won't repeat the details here, but it amounts to moving one of
> the thunks produced by atomicModifyMutVar# out of the primop and into the
> atomicModifyIORef wrapper. The advantage is that in the case of the strict
> version of the wrapper, atomicModifyIORef', this extra thunk is eliminated
> entirely, rather than being created by the primop and then immediately
> evaluated by the wrapper.
>
>
>
> I propose we accept the proposal to add the new primop in section 2.1,
> along with the straightforward additions proposed in sections 2.2 and 2.3.
> (the old primop will be removed, but can be defined in GHC.Exts  as a
> wrapper around the new primop for backwards compat)
>
>
>
> However, the additions to the Data.IORef library should be considered by
> the libraries committee separately. (there are naming issues to be resolved
> in particular).
>
>
>
> Cheers
>
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180705/b30ec3fd/attachment.html>

From mail at joachim-breitner.de  Sat Jul  7 14:48:17 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 07 Jul 2018 10:48:17 -0400
Subject: [ghc-steering-committee] Solicitation for a new member
Message-ID: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>

Dear Committee,

Ryan Newton has expressed interest in being rotated out of the
committee. I spoke to the Simons, and they indicate we should ask for
public nominations. Here is a draft of a mail I’d send to the usual
mailing lists. Please comment.

==========================
Dear community,

the GHC Steering committee is seeking nomination for a new member, and
ask for self-nominations.

The committee scrutinizes, nitpicks, improves, weights and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC
Our processes are described in the README in
https://github.com/ghc-proposals/ghc-proposals
which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability 
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and 
   specifications,
 * make constructive comments and improvements,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

Particular pluses that we look for are
 * candidates who have been in the community for some time, and/or
 * who have expertise in language design and implementation in
   related language, which they can share with us.

The committee work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. Please
keep that in mind if your email inbox is already flowing over.

There is no shortage of people who are very eager to get fancy new
features into the language, both in the committee and the wider
community. I therefore explicitly invite “conservative” members of the
community to join the committee.

The GHC developers themselves are nicely represented already. Having
hacked on GHC is not a requirement.


To nominate yourself, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de until July 20th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

You cannot nominate others. But if you know of anyone else you’d think
should be on the committee, please do encourage them, or talk to us and
we can encourage them.

On behalf of the committee,
Joachim Breitner
==========================


Note worth discussing:

 * I see no point in non-self-nominations. We can only have members
   that want to do this.

 * Do we want to encourage “conservative” members? Is that the right  
   wording? (I see the committee a bit as a flood gate that protects
   against premature and not-worth-it changes. We are doing a good
   job of that – most of my proposals get rejected ;-) – but I think
   it would not hurt to explicitly keep it that way.

 * One could consider public nominations and deliberations, but I feel
   that a public discussion of who we think is the “best” is not very
   nice.


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/20180707/ecb6b427/attachment.sig>

From rae at cs.brynmawr.edu  Sat Jul  7 21:03:52 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sat, 7 Jul 2018 17:03:52 -0400
Subject: [ghc-steering-committee] Solicitation for a new member
In-Reply-To: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>
References: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>
Message-ID: <E6CE081B-57CA-4370-9EE1-0228131E556A@cs.brynmawr.edu>

+1 from me. I explicitly support conservatism on the committee.

Richard

> On Jul 7, 2018, at 10:48 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear Committee,
> 
> Ryan Newton has expressed interest in being rotated out of the
> committee. I spoke to the Simons, and they indicate we should ask for
> public nominations. Here is a draft of a mail I’d send to the usual
> mailing lists. Please comment.
> 
> ==========================
> Dear community,
> 
> the GHC Steering committee is seeking nomination for a new member, and
> ask for self-nominations.
> 
> The committee scrutinizes, nitpicks, improves, weights and eventually
> accepts or rejects proposals that extend or change the language
> supported by GHC and other (public-facing) aspects of GHC
> Our processes are described in the README in
> https://github.com/ghc-proposals/ghc-proposals
> which is also the GitHub repository where proposals are proposed.
> 
> We are looking for a member who has the ability 
> * to understand such language extension proposals,
> * to find holes and missing corner cases in the specifications,
> * foresee the interaction with other language features and 
>   specifications,
> * make constructive comments and improvements,
> * judge the cost/benefit ratio and
> * finally come to a justifiable conclusion.
> 
> Particular pluses that we look for are
> * candidates who have been in the community for some time, and/or
> * who have expertise in language design and implementation in
>   related language, which they can share with us.
> 
> The committee work requires a small, but non-trivial amount of time,
> especially when you are assigned a proposal for shepherding. Please
> keep that in mind if your email inbox is already flowing over.
> 
> There is no shortage of people who are very eager to get fancy new
> features into the language, both in the committee and the wider
> community. I therefore explicitly invite “conservative” members of the
> community to join the committee.
> 
> The GHC developers themselves are nicely represented already. Having
> hacked on GHC is not a requirement.
> 
> 
> To nominate yourself, please send an email to me (as the committee
> secretary) at mail at joachim-breitner.de until July 20th. I will
> distribute the nominations among the committee, and we will keep the
> nominations and our deliberations private.
> 
> You cannot nominate others. But if you know of anyone else you’d think
> should be on the committee, please do encourage them, or talk to us and
> we can encourage them.
> 
> On behalf of the committee,
> Joachim Breitner
> ==========================
> 
> 
> Note worth discussing:
> 
> * I see no point in non-self-nominations. We can only have members
>   that want to do this.
> 
> * Do we want to encourage “conservative” members? Is that the right  
>   wording? (I see the committee a bit as a flood gate that protects
>   against premature and not-worth-it changes. We are doing a good
>   job of that – most of my proposals get rejected ;-) – but I think
>   it would not hurt to explicitly keep it that way.
> 
> * One could consider public nominations and deliberations, but I feel
>   that a public discussion of who we think is the “best” is not very
>   nice.
> 
> 
> 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


From mail at joachim-breitner.de  Mon Jul  9 01:47:59 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 08 Jul 2018 21:47:59 -0400
Subject: [ghc-steering-committee] Deprecating Exports (#134);
 Recommendation: accept
In-Reply-To: <AE19F501-D902-40E4-A0AA-9E38F4FC9617@cs.brynmawr.edu>
References: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de>
 <4486bc5bb722ddc615a0f2199c85dd20dca89910.camel@joachim-breitner.de>
 <AE19F501-D902-40E4-A0AA-9E38F4FC9617@cs.brynmawr.edu>
Message-ID: <8aef3b219cc1034840980c609f7b65de5fc87979.camel@joachim-breitner.de>

Hi Richard,

have your reservations been addressed and/or resolved?

My impression is that overall, we approve of the feature, and I suggest
we accept the proposal as it, confident that any remaining corner cases
will be resolved in the process of implementing it, and in a way that
will be fine.

Cheers,
Joachim

Am Samstag, den 23.06.2018, 23:46 -0400 schrieb Richard Eisenberg:
> I have some reservations, though I like the overall idea. I've posted on GitHub.
> 
> Richard
> 
> > On Jun 23, 2018, at 12:13 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Dear Committee,
> > 
> > Am Donnerstag, den 24.05.2018, 12:23 +0200 schrieb Joachim Breitner:
> > > alanasp has proposed a Deprecating Exports mechanism:
> > > https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst
> > > 
> > > I suggest acceptance!
> > 
> > thanks Iavor, Simon and Richard for refining the proposal (and sorry
> > for missing some of the obvious shortcomings). I believe the author
> > addressed the concerns, and now the proposal is better.
> > 
> > I even more suggest acceptance. If there is still disagreement, please
> > speak up.
> > 
> > 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
> 
> _______________________________________________
> 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/20180708/068750fc/attachment.sig>

From rae at cs.brynmawr.edu  Mon Jul  9 02:10:50 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 8 Jul 2018 22:10:50 -0400
Subject: [ghc-steering-committee] Deprecating Exports (#134);
 Recommendation: accept
In-Reply-To: <8aef3b219cc1034840980c609f7b65de5fc87979.camel@joachim-breitner.de>
References: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de>
 <4486bc5bb722ddc615a0f2199c85dd20dca89910.camel@joachim-breitner.de>
 <AE19F501-D902-40E4-A0AA-9E38F4FC9617@cs.brynmawr.edu>
 <8aef3b219cc1034840980c609f7b65de5fc87979.camel@joachim-breitner.de>
Message-ID: <0181259F-D39E-4A4A-AEDA-594CDC85600D@cs.brynmawr.edu>

I generally agree, but Simon M and I have both staked out opposite opinions on the second bullet in https://github.com/ghc-proposals/ghc-proposals/pull/134#issuecomment-399726779 <https://github.com/ghc-proposals/ghc-proposals/pull/134#issuecomment-399726779>   Simon, do you have a response to my thoughts there?

I'm happy enough to let my other complaint be lazily resolved during implementation.

Thanks,
Richard

> On Jul 8, 2018, at 9:47 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi Richard,
> 
> have your reservations been addressed and/or resolved?
> 
> My impression is that overall, we approve of the feature, and I suggest
> we accept the proposal as it, confident that any remaining corner cases
> will be resolved in the process of implementing it, and in a way that
> will be fine.
> 
> Cheers,
> Joachim
> 
> Am Samstag, den 23.06.2018, 23:46 -0400 schrieb Richard Eisenberg:
>> I have some reservations, though I like the overall idea. I've posted on GitHub.
>> 
>> Richard
>> 
>>> On Jun 23, 2018, at 12:13 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>> 
>>> Dear Committee,
>>> 
>>> Am Donnerstag, den 24.05.2018, 12:23 +0200 schrieb Joachim Breitner:
>>>> alanasp has proposed a Deprecating Exports mechanism:
>>>> https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst
>>>> 
>>>> I suggest acceptance!
>>> 
>>> thanks Iavor, Simon and Richard for refining the proposal (and sorry
>>> for missing some of the obvious shortcomings). I believe the author
>>> addressed the concerns, and now the proposal is better.
>>> 
>>> I even more suggest acceptance. If there is still disagreement, please
>>> speak up.
>>> 
>>> 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
>> 
>> _______________________________________________
>> 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/20180708/6b0b4cb0/attachment.html>

From rae at cs.brynmawr.edu  Mon Jul  9 03:41:34 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 8 Jul 2018 23:41:34 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
Message-ID: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>

I have volunteered to shepherd Proposal #111: Linear Types. The pull request is here: https://github.com/ghc-proposals/ghc-proposals/pull/111

The authors propose adding linear functions to GHC. The argument to a linear function must be used exactly once in the function body. Motivation for this feature abounds -- essentially, linear types allow for better static checking around resource allocation and deallocation. I refer you to the proposal (and published paper) for more details here. The proposal also contains multiplicity polymorphism, where a higher-order function can be polymorphic in the multiplicity of a supplied function. Datatypes are linear by default, with a long list of (in my opinion, non-obvious) rules around syntax and exceptions to those rules. Constructors have a different multiplicity when used in an expression than they do when used in a pattern, for example. The authors leave type inference as an open question and do not state how the feature would work with either view patterns or pattern synonyms. The proposal comes with a companion document detailing the changes to Core. These changes seem appropriate.

The current proposal has a fair number of open questions. I've written a long comment on the GitHub trail detailing what I was uncertain of. The proposal is not currently near the level of crispness of the proposals we normally accept. For a smaller proposal, I would just send it back to the authors without really giving it to the committee. However, there has been a great deal of effort behind writing this proposal and building an implementation, and so I think it's only fair that we give some thought about the general direction being worked in here.

As to the features themselves: I'm personally far from convinced. Though I see no better way to achieve the authors' goals, the feature they have proposed is full of both sharp and dark corners. If implemented, there would be regular questions cropping up as to why such-and-such is the case or why the design is the way it is. However, this is well motivated and eagerly anticipated. And I don't think we'll be able to conjure up a better design without gaining experience with the proposed design, however flawed.

I thus recommend: Encouragement to continue the proposal and implementation, with an eye toward acceptance. Furthermore, if/when merged, I would like to advertise that the feature is subject to change, with no backward compatibility guarantee, for several versions. If the feature is implemented and merged, we will learn more about it and then perhaps refine it in the future.

Richard

From marlowsd at gmail.com  Mon Jul  9 07:23:11 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 9 Jul 2018 08:23:11 +0100
Subject: [ghc-steering-committee] Solicitation for a new member
In-Reply-To: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>
References: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>
Message-ID: <CANsrgP+tkuMjJta41V=T_RgbbFY2A4XdQU+tPHBz_i54fYsoJA@mail.gmail.com>

This looks great to me.

On the amount of time required - can we put a ballpark figure on this?
Perhaps 2 hours per week on average, more when going in depth into
proposals. How much do other people spend? I worry that "small but
non-trivial" means different things to different people.

I'm ok with "conservative".

Cheers
Simon

On 7 July 2018 at 15:48, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Dear Committee,
>
> Ryan Newton has expressed interest in being rotated out of the
> committee. I spoke to the Simons, and they indicate we should ask for
> public nominations. Here is a draft of a mail I’d send to the usual
> mailing lists. Please comment.
>
> ==========================
> Dear community,
>
> the GHC Steering committee is seeking nomination for a new member, and
> ask for self-nominations.
>
> The committee scrutinizes, nitpicks, improves, weights and eventually
> accepts or rejects proposals that extend or change the language
> supported by GHC and other (public-facing) aspects of GHC
> Our processes are described in the README in
> https://github.com/ghc-proposals/ghc-proposals
> which is also the GitHub repository where proposals are proposed.
>
> We are looking for a member who has the ability
>  * to understand such language extension proposals,
>  * to find holes and missing corner cases in the specifications,
>  * foresee the interaction with other language features and
>    specifications,
>  * make constructive comments and improvements,
>  * judge the cost/benefit ratio and
>  * finally come to a justifiable conclusion.
>
> Particular pluses that we look for are
>  * candidates who have been in the community for some time, and/or
>  * who have expertise in language design and implementation in
>    related language, which they can share with us.
>
> The committee work requires a small, but non-trivial amount of time,
> especially when you are assigned a proposal for shepherding. Please
> keep that in mind if your email inbox is already flowing over.
>
> There is no shortage of people who are very eager to get fancy new
> features into the language, both in the committee and the wider
> community. I therefore explicitly invite “conservative” members of the
> community to join the committee.
>
> The GHC developers themselves are nicely represented already. Having
> hacked on GHC is not a requirement.
>
>
> To nominate yourself, please send an email to me (as the committee
> secretary) at mail at joachim-breitner.de until July 20th. I will
> distribute the nominations among the committee, and we will keep the
> nominations and our deliberations private.
>
> You cannot nominate others. But if you know of anyone else you’d think
> should be on the committee, please do encourage them, or talk to us and
> we can encourage them.
>
> On behalf of the committee,
> Joachim Breitner
> ==========================
>
>
> Note worth discussing:
>
>  * I see no point in non-self-nominations. We can only have members
>    that want to do this.
>
>  * Do we want to encourage “conservative” members? Is that the right
>    wording? (I see the committee a bit as a flood gate that protects
>    against premature and not-worth-it changes. We are doing a good
>    job of that – most of my proposals get rejected ;-) – but I think
>    it would not hurt to explicitly keep it that way.
>
>  * One could consider public nominations and deliberations, but I feel
>    that a public discussion of who we think is the “best” is not very
>    nice.
>
>
> 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/20180709/04e7ce61/attachment-0001.html>

From simonpj at microsoft.com  Mon Jul  9 08:34:40 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 9 Jul 2018 08:34:40 +0000
Subject: [ghc-steering-committee] Solicitation for a new member
In-Reply-To: <CANsrgP+tkuMjJta41V=T_RgbbFY2A4XdQU+tPHBz_i54fYsoJA@mail.gmail.com>
References: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>
 <CANsrgP+tkuMjJta41V=T_RgbbFY2A4XdQU+tPHBz_i54fYsoJA@mail.gmail.com>
Message-ID: <AM6PR83MB0309A521A20DC16816CE558AAD440@AM6PR83MB0309.EURPRD83.prod.outlook.com>

Ryan Newton has expressed interest in being rotated out of the
committee. I spoke to the Simons, and they indicate we should ask for
public nominations. Here is a draft of a mail I’d send to the usual
mailing lists. Please comment.

Good draft.  I support “conservative”.  I have made some suggesting drafting amendments (highlighted) below.

I think nominations of someone else are ok, provided said person has explicitly consented.  It’s affirming to be nominated, but it erodes that affirmation if the person doing the encouraging has to say “but you have to nominate yourself”.

Simon


==========================
Dear community,

the GHC Steering committee is seeking nomination for a new member, and
ask for self-nominations.

The committee scrutinizes, nitpicks, improves, weights and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC
Our processes are described in the README in
https://github.com/ghc-proposals/ghc-proposals<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0>
which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and
   specifications,
 * make constructive comments and improvements,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

We look for committee members who have some of these properties:
* have substantial experience in writing Haskell applications or libraries,
    which they can use to inform judgements about the utility or otherwise
    of proposed features
* have made active contributions to the Haskell community,
    for some time
 * have expertise in language design and implementation, in
    either Haskell or related language, which they can share with us.

The GHC developers themselves are already well represented already.  We
seek Haskell users more than GHC hackers.

The committee’s work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. Please
keep that in mind if your email inbox is already overflowing.

There is no shortage of people who are very eager to get fancy new
features into the language, both in the committee and the wider
community.  But each new feature imposes a cost, to implement, to learn,
and (particularly) through its uexpected interaction with other features.
We need to strike a balance, one that encourages innovation (as Haskell
always has) while still making Haskell attractive for real-world production
use.   We therefore explicitly invite “conservative” members of the
community to join the committee.

To nominate yourself, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de<mailto:mail at joachim-breitner.de> until July 20th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

You can nominate others, but you must obtain their explicit consent to do so.
(We don’t want to choose someone who turns out to be unable to serve.)

On behalf of the committee,
Joachim Breitner
==========================


From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 09 July 2018 08:23
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Solicitation for a new member

This looks great to me.

On the amount of time required - can we put a ballpark figure on this? Perhaps 2 hours per week on average, more when going in depth into proposals. How much do other people spend? I worry that "small but non-trivial" means different things to different people.

I'm ok with "conservative".

Cheers
Simon

On 7 July 2018 at 15:48, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

Ryan Newton has expressed interest in being rotated out of the
committee. I spoke to the Simons, and they indicate we should ask for
public nominations. Here is a draft of a mail I’d send to the usual
mailing lists. Please comment.

==========================
Dear community,

the GHC Steering committee is seeking nomination for a new member, and
ask for self-nominations.

The committee scrutinizes, nitpicks, improves, weights and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC
Our processes are described in the README in
https://github.com/ghc-proposals/ghc-proposals<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0>
which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and
   specifications,
 * make constructive comments and improvements,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

Particular pluses that we look for are
 * candidates who have been in the community for some time, and/or
 * who have expertise in language design and implementation in
   related language, which they can share with us.

The committee work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. Please
keep that in mind if your email inbox is already flowing over.

There is no shortage of people who are very eager to get fancy new
features into the language, both in the committee and the wider
community. I therefore explicitly invite “conservative” members of the
community to join the committee.

The GHC developers themselves are nicely represented already. Having
hacked on GHC is not a requirement.


To nominate yourself, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de<mailto:mail at joachim-breitner.de> until July 20th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

You cannot nominate others. But if you know of anyone else you’d think
should be on the committee, please do encourage them, or talk to us and
we can encourage them.

On behalf of the committee,
Joachim Breitner
==========================


Note worth discussing:

 * I see no point in non-self-nominations. We can only have members
   that want to do this.

 * Do we want to encourage “conservative” members? Is that the right
   wording? (I see the committee a bit as a flood gate that protects
   against premature and not-worth-it changes. We are doing a good
   job of that – most of my proposals get rejected ;-) – but I think
   it would not hurt to explicitly keep it that way.

 * One could consider public nominations and deliberations, but I feel
   that a public discussion of who we think is the “best” is not very
   nice.


Cheers,
Joachim

--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065259412&sdata=vab8j7i%2F9tp7QLt4CicceON5iDPoj779PGgH7KBEXpo%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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180709/3198cb6a/attachment-0001.html>

From simonpj at microsoft.com  Mon Jul  9 08:42:05 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 9 Jul 2018 08:42:05 +0000
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
Message-ID: <AM6PR83MB0309D627DBC918ACC6CD2CCCAD440@AM6PR83MB0309.EURPRD83.prod.outlook.com>

Richard writes

|  As to the features themselves: I'm personally far from convinced. Though I
|  see no better way to achieve the authors' goals, the feature they have
|  proposed is full of both sharp and dark corners. If implemented, there would
|  be regular questions cropping up as to why such-and-such is the case or why
|  the design is the way it is. However, this is well motivated and eagerly
|  anticipated. And I don't think we'll be able to conjure up a better design
|  without gaining experience with the proposed design, however flawed.
|  
|  I thus recommend: Encouragement to continue the proposal and implementation,
|  with an eye toward acceptance. Furthermore, if/when merged, I would like to
|  advertise that the feature is subject to change, with no backward
|  compatibility guarantee, for several versions. If the feature is implemented
|  and merged, we will learn more about it and then perhaps refine it in the
|  future.

I'm mostly with Richard here.  Linearity is a "big feature".  We have to change Core, and that's something we do very seldom.  (The TypeInType stuff is comparable.)

I'm a bit more positive than Richard.  I've spent years looking for a way to make sense of linearity, and this is the first time I have seen a proposal that
- fits with the language
- looks as if it could pay its way

But it is "big" and without experience we don’t have a good way to evaluate it.  It's a chicken and egg problem: we can't get that experience without trying it.  Neither the costs nor the benefits are apparent yet.  But it's too interesting to drop.

I think we should be encouraging.  The next hurdle is to see whether the implementation turns out reasonable, or if it litters the compiler with ad-hoc gubbins. We'll see.  Matthew is on the job.

Declaration of interest: I'm a co-author.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
|  Behalf Of Richard Eisenberg
|  Sent: 09 July 2018 04:42
|  To: ghc-steering-committee <ghc-steering-committee at haskell.org>
|  Subject: [ghc-steering-committee] Proposal #111: Linear Types
|  
|  I have volunteered to shepherd Proposal #111: Linear Types. The pull request
|  is here:
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F111&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C90f84d3b
|  5c3b42dfa7b108d5e54de405%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667
|  045071264050&amp;sdata=EB82E10Yedfp0E83OuTjK5F%2BfHX7CHKP%2Fuf7NRytlxM%3D&am
|  p;reserved=0
|  
|  The authors propose adding linear functions to GHC. The argument to a linear
|  function must be used exactly once in the function body. Motivation for this
|  feature abounds -- essentially, linear types allow for better static
|  checking around resource allocation and deallocation. I refer you to the
|  proposal (and published paper) for more details here. The proposal also
|  contains multiplicity polymorphism, where a higher-order function can be
|  polymorphic in the multiplicity of a supplied function. Datatypes are linear
|  by default, with a long list of (in my opinion, non-obvious) rules around
|  syntax and exceptions to those rules. Constructors have a different
|  multiplicity when used in an expression than they do when used in a pattern,
|  for example. The authors leave type inference as an open question and do not
|  state how the feature would work with either view patterns or pattern
|  synonyms. The proposal comes with a companion document detailing the changes
|  to Core. These changes seem appropriate.
|  
|  The current proposal has a fair number of open questions. I've written a
|  long comment on the GitHub trail detailing what I was uncertain of. The
|  proposal is not currently near the level of crispness of the proposals we
|  normally accept. For a smaller proposal, I would just send it back to the
|  authors without really giving it to the committee. However, there has been a
|  great deal of effort behind writing this proposal and building an
|  implementation, and so I think it's only fair that we give some thought
|  about the general direction being worked in here.
|  
|  As to the features themselves: I'm personally far from convinced. Though I
|  see no better way to achieve the authors' goals, the feature they have
|  proposed is full of both sharp and dark corners. If implemented, there would
|  be regular questions cropping up as to why such-and-such is the case or why
|  the design is the way it is. However, this is well motivated and eagerly
|  anticipated. And I don't think we'll be able to conjure up a better design
|  without gaining experience with the proposed design, however flawed.
|  
|  I thus recommend: Encouragement to continue the proposal and implementation,
|  with an eye toward acceptance. Furthermore, if/when merged, I would like to
|  advertise that the feature is subject to change, with no backward
|  compatibility guarantee, for several versions. If the feature is implemented
|  and merged, we will learn more about it and then perhaps refine it in the
|  future.
|  
|  Richard
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From chak at justtesting.org  Mon Jul  9 11:40:54 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Mon, 9 Jul 2018 13:40:54 +0200
Subject: [ghc-steering-committee] Solicitation for a new member
In-Reply-To: <AM6PR83MB0309A521A20DC16816CE558AAD440@AM6PR83MB0309.EURPRD83.prod.outlook.com>
References: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>
 <CANsrgP+tkuMjJta41V=T_RgbbFY2A4XdQU+tPHBz_i54fYsoJA@mail.gmail.com>
 <AM6PR83MB0309A521A20DC16816CE558AAD440@AM6PR83MB0309.EURPRD83.prod.outlook.com>
Message-ID: <21A297A5-725D-4711-B498-113647BCB06C@justtesting.org>

I agree with Simon’s point about self-nominations; otherwise, I like Joachim’s proposal.

Manuel

> Am 09.07.2018 um 10:34 schrieb Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>:
> 
> Ryan Newton has expressed interest in being rotated out of the
> committee. I spoke to the Simons, and they indicate we should ask for
> public nominations. Here is a draft of a mail I’d send to the usual
> mailing lists. Please comment.
> 
> Good draft.  I support “conservative”.  I have made some suggesting drafting amendments (highlighted) below.
> 
> I think nominations of someone else are ok, provided said person has explicitly consented.  It’s affirming to be nominated, but it erodes that affirmation if the person doing the encouraging has to say “but you have to nominate yourself”.
> 
> Simon
> 
> 
> ==========================
> Dear community,
> 
> the GHC Steering committee is seeking nomination for a new member, and
> ask for self-nominations.
> 
> The committee scrutinizes, nitpicks, improves, weights and eventually
> accepts or rejects proposals that extend or change the language
> supported by GHC and other (public-facing) aspects of GHC
> Our processes are described in the README in
> https://github.com/ghc-proposals/ghc-proposals <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0>
> which is also the GitHub repository where proposals are proposed.
> 
> We are looking for a member who has the ability
>  * to understand such language extension proposals,
>  * to find holes and missing corner cases in the specifications,
>  * foresee the interaction with other language features and
>    specifications,
>  * make constructive comments and improvements,
>  * judge the cost/benefit ratio and
>  * finally come to a justifiable conclusion.
> 
> We look for committee members who have some of these properties:
> * have substantial experience in writing Haskell applications or libraries,
>     which they can use to inform judgements about the utility or otherwise
>     of proposed features
> * have made active contributions to the Haskell community,
>     for some time
>  * have expertise in language design and implementation, in
>     either Haskell or related language, which they can share with us.
> 
> The GHC developers themselves are already well represented already.  We
> seek Haskell users more than GHC hackers.
> 
> The committee’s work requires a small, but non-trivial amount of time,
> especially when you are assigned a proposal for shepherding. Please
> keep that in mind if your email inbox is already overflowing.
> 
> There is no shortage of people who are very eager to get fancy new
> features into the language, both in the committee and the wider
> community.  But each new feature imposes a cost, to implement, to learn,
> and (particularly) through its uexpected interaction with other features.
> We need to strike a balance, one that encourages innovation (as Haskell
> always has) while still making Haskell attractive for real-world production
> use.   We therefore explicitly invite “conservative” members of the
> community to join the committee.
> 
> To nominate yourself, please send an email to me (as the committee
> secretary) at mail at joachim-breitner.de <mailto:mail at joachim-breitner.de> until July 20th. I will
> distribute the nominations among the committee, and we will keep the
> nominations and our deliberations private.
> 
> You can nominate others, but you must obtain their explicit consent to do so.
> (We don’t want to choose someone who turns out to be unable to serve.)
> 
> On behalf of the committee,
> Joachim Breitner
> ==========================
> 
> 
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
> Sent: 09 July 2018 08:23
> To: Joachim Breitner <mail at joachim-breitner.de>
> Cc: ghc-steering-committee at haskell.org
> Subject: Re: [ghc-steering-committee] Solicitation for a new member
> 
> This looks great to me.
> 
> 
> 
> On the amount of time required - can we put a ballpark figure on this? Perhaps 2 hours per week on average, more when going in depth into proposals. How much do other people spend? I worry that "small but non-trivial" means different things to different people.
> 
> 
> 
> I'm ok with "conservative".
> 
> 
> 
> Cheers
> 
> Simon
> 
> 
> 
> On 7 July 2018 at 15:48, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> 
> Dear Committee,
> 
> Ryan Newton has expressed interest in being rotated out of the
> committee. I spoke to the Simons, and they indicate we should ask for
> public nominations. Here is a draft of a mail I’d send to the usual
> mailing lists. Please comment.
> 
> ==========================
> Dear community,
> 
> the GHC Steering committee is seeking nomination for a new member, and
> ask for self-nominations.
> 
> The committee scrutinizes, nitpicks, improves, weights and eventually
> accepts or rejects proposals that extend or change the language
> supported by GHC and other (public-facing) aspects of GHC
> Our processes are described in the README in
> https://github.com/ghc-proposals/ghc-proposals <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0>
> which is also the GitHub repository where proposals are proposed.
> 
> We are looking for a member who has the ability
>  * to understand such language extension proposals,
>  * to find holes and missing corner cases in the specifications,
>  * foresee the interaction with other language features and
>    specifications,
>  * make constructive comments and improvements,
>  * judge the cost/benefit ratio and
>  * finally come to a justifiable conclusion.
> 
> Particular pluses that we look for are
>  * candidates who have been in the community for some time, and/or
>  * who have expertise in language design and implementation in
>    related language, which they can share with us.
> 
> The committee work requires a small, but non-trivial amount of time,
> especially when you are assigned a proposal for shepherding. Please
> keep that in mind if your email inbox is already flowing over.
> 
> There is no shortage of people who are very eager to get fancy new
> features into the language, both in the committee and the wider
> community. I therefore explicitly invite “conservative” members of the
> community to join the committee.
> 
> The GHC developers themselves are nicely represented already. Having
> hacked on GHC is not a requirement.
> 
> 
> To nominate yourself, please send an email to me (as the committee
> secretary) at mail at joachim-breitner.de <mailto:mail at joachim-breitner.de> until July 20th. I will
> distribute the nominations among the committee, and we will keep the
> nominations and our deliberations private.
> 
> You cannot nominate others. But if you know of anyone else you’d think
> should be on the committee, please do encourage them, or talk to us and
> we can encourage them.
> 
> On behalf of the committee,
> Joachim Breitner
> ==========================
> 
> 
> Note worth discussing:
> 
>  * I see no point in non-self-nominations. We can only have members
>    that want to do this.
> 
>  * Do we want to encourage “conservative” members? Is that the right
>    wording? (I see the committee a bit as a flood gate that protects
>    against premature and not-worth-it changes. We are doing a good
>    job of that – most of my proposals get rejected ;-) – but I think
>    it would not hurt to explicitly keep it that way.
> 
>  * One could consider public nominations and deliberations, but I feel
>    that a public discussion of who we think is the “best” is not very
>    nice.
> 
> 
> Cheers,
> Joachim
> 
> --
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065259412&sdata=vab8j7i%2F9tp7QLt4CicceON5iDPoj779PGgH7KBEXpo%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://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/20180709/61187649/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180709/61187649/attachment-0001.sig>

From rae at cs.brynmawr.edu  Mon Jul  9 12:29:59 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 9 Jul 2018 08:29:59 -0400
Subject: [ghc-steering-committee] Solicitation for a new member
In-Reply-To: <21A297A5-725D-4711-B498-113647BCB06C@justtesting.org>
References: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>
 <CANsrgP+tkuMjJta41V=T_RgbbFY2A4XdQU+tPHBz_i54fYsoJA@mail.gmail.com>
 <AM6PR83MB0309A521A20DC16816CE558AAD440@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <21A297A5-725D-4711-B498-113647BCB06C@justtesting.org>
Message-ID: <2A3A0D97-17D6-4694-AD3A-C3E027C4FAD9@cs.brynmawr.edu>

Should we explicitly ask for responsiveness?

For example, in the desired "properties" bullets, add:

* normally responds to a technical email within 1-2 weeks

And I would agree with the assessment that this takes ~2 hours/week.

Richard

> On Jul 9, 2018, at 7:40 AM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> 
> I agree with Simon’s point about self-nominations; otherwise, I like Joachim’s proposal.
> 
> Manuel
> 
>> Am 09.07.2018 um 10:34 schrieb Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>>:
>> 
>> Ryan Newton has expressed interest in being rotated out of the
>> committee. I spoke to the Simons, and they indicate we should ask for
>> public nominations. Here is a draft of a mail I’d send to the usual
>> mailing lists. Please comment.
>>  
>> Good draft.  I support “conservative”.  I have made some suggesting drafting amendments (highlighted) below.
>>  
>> I think nominations of someone else are ok, provided said person has explicitly consented.  It’s affirming to be nominated, but it erodes that affirmation if the person doing the encouraging has to say “but you have to nominate yourself”.
>>  
>> Simon
>>  
>>  
>> ==========================
>> Dear community,
>> 
>> the GHC Steering committee is seeking nomination for a new member, and
>> ask for self-nominations.
>> 
>> The committee scrutinizes, nitpicks, improves, weights and eventually
>> accepts or rejects proposals that extend or change the language
>> supported by GHC and other (public-facing) aspects of GHC
>> Our processes are described in the README in
>> https://github.com/ghc-proposals/ghc-proposals <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0>
>> which is also the GitHub repository where proposals are proposed.
>> 
>> We are looking for a member who has the ability 
>>  * to understand such language extension proposals,
>>  * to find holes and missing corner cases in the specifications,
>>  * foresee the interaction with other language features and 
>>    specifications,
>>  * make constructive comments and improvements,
>>  * judge the cost/benefit ratio and
>>  * finally come to a justifiable conclusion.
>> 
>> We look for committee members who have some of these properties:
>> * have substantial experience in writing Haskell applications or libraries,
>>     which they can use to inform judgements about the utility or otherwise
>>     of proposed features
>> * have made active contributions to the Haskell community,
>>     for some time
>>  * have expertise in language design and implementation, in
>>     either Haskell or related language, which they can share with us.
>> 
>> The GHC developers themselves are already well represented already.  We
>> seek Haskell users more than GHC hackers.
>> 
>> The committee’s work requires a small, but non-trivial amount of time,
>> especially when you are assigned a proposal for shepherding. Please
>> keep that in mind if your email inbox is already overflowing.
>> 
>> There is no shortage of people who are very eager to get fancy new
>> features into the language, both in the committee and the wider
>> community.  But each new feature imposes a cost, to implement, to learn,
>> and (particularly) through its uexpected interaction with other features.
>> We need to strike a balance, one that encourages innovation (as Haskell
>> always has) while still making Haskell attractive for real-world production
>> use.   We therefore explicitly invite “conservative” members of the
>> community to join the committee.
>> 
>> To nominate yourself, please send an email to me (as the committee
>> secretary) at mail at joachim-breitner.de <mailto:mail at joachim-breitner.de> until July 20th. I will
>> distribute the nominations among the committee, and we will keep the
>> nominations and our deliberations private.
>> 
>> You can nominate others, but you must obtain their explicit consent to do so.
>> (We don’t want to choose someone who turns out to be unable to serve.)
>> 
>> On behalf of the committee,
>> Joachim Breitner
>> ==========================
>> 
>>  
>> 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: 09 July 2018 08:23
>> To: Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
>> Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> Subject: Re: [ghc-steering-committee] Solicitation for a new member
>>  
>> This looks great to me.
>> 
>>  
>> 
>> On the amount of time required - can we put a ballpark figure on this? Perhaps 2 hours per week on average, more when going in depth into proposals. How much do other people spend? I worry that "small but non-trivial" means different things to different people.
>> 
>>  
>> 
>> I'm ok with "conservative".
>> 
>>  
>> 
>> Cheers
>> 
>> Simon
>> 
>>  
>> 
>> On 7 July 2018 at 15:48, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>> 
>> Dear Committee,
>> 
>> Ryan Newton has expressed interest in being rotated out of the
>> committee. I spoke to the Simons, and they indicate we should ask for
>> public nominations. Here is a draft of a mail I’d send to the usual
>> mailing lists. Please comment.
>> 
>> ==========================
>> Dear community,
>> 
>> the GHC Steering committee is seeking nomination for a new member, and
>> ask for self-nominations.
>> 
>> The committee scrutinizes, nitpicks, improves, weights and eventually
>> accepts or rejects proposals that extend or change the language
>> supported by GHC and other (public-facing) aspects of GHC
>> Our processes are described in the README in
>> https://github.com/ghc-proposals/ghc-proposals <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0>
>> which is also the GitHub repository where proposals are proposed.
>> 
>> We are looking for a member who has the ability 
>>  * to understand such language extension proposals,
>>  * to find holes and missing corner cases in the specifications,
>>  * foresee the interaction with other language features and 
>>    specifications,
>>  * make constructive comments and improvements,
>>  * judge the cost/benefit ratio and
>>  * finally come to a justifiable conclusion.
>> 
>> Particular pluses that we look for are
>>  * candidates who have been in the community for some time, and/or
>>  * who have expertise in language design and implementation in
>>    related language, which they can share with us.
>> 
>> The committee work requires a small, but non-trivial amount of time,
>> especially when you are assigned a proposal for shepherding. Please
>> keep that in mind if your email inbox is already flowing over.
>> 
>> There is no shortage of people who are very eager to get fancy new
>> features into the language, both in the committee and the wider
>> community. I therefore explicitly invite “conservative” members of the
>> community to join the committee.
>> 
>> The GHC developers themselves are nicely represented already. Having
>> hacked on GHC is not a requirement.
>> 
>> 
>> To nominate yourself, please send an email to me (as the committee
>> secretary) at mail at joachim-breitner.de <mailto:mail at joachim-breitner.de> until July 20th. I will
>> distribute the nominations among the committee, and we will keep the
>> nominations and our deliberations private.
>> 
>> You cannot nominate others. But if you know of anyone else you’d think
>> should be on the committee, please do encourage them, or talk to us and
>> we can encourage them.
>> 
>> On behalf of the committee,
>> Joachim Breitner
>> ==========================
>> 
>> 
>> Note worth discussing:
>> 
>>  * I see no point in non-self-nominations. We can only have members
>>    that want to do this.
>> 
>>  * Do we want to encourage “conservative” members? Is that the right  
>>    wording? (I see the committee a bit as a flood gate that protects
>>    against premature and not-worth-it changes. We are doing a good
>>    job of that – most of my proposals get rejected ;-) – but I think
>>    it would not hurt to explicitly keep it that way.
>> 
>>  * One could consider public nominations and deliberations, but I feel
>>    that a public discussion of who we think is the “best” is not very
>>    nice.
>> 
>> 
>> Cheers,
>> Joachim
>> 
>> -- 
>> Joachim Breitner
>>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>   http://www.joachim-breitner.de/ <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065259412&sdata=vab8j7i%2F9tp7QLt4CicceON5iDPoj779PGgH7KBEXpo%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://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/20180709/00069bea/attachment-0001.html>

From mail at joachim-breitner.de  Mon Jul  9 13:35:15 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 09 Jul 2018 09:35:15 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
Message-ID: <a756984b1372c4e1e93d8f32445044346304f6b9.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 08.07.2018, 23:41 -0400 schrieb Richard Eisenberg:
> And I don't think we'll be able to conjure up a better design without
> gaining experience with the proposed design, however flawed.

I am wondering if we need in general a better way of allowing high-
risk/high-impact implementations to be tested in practice without
needing to merge them into the main compiler directly first.

In a way Liquid Haskell is an example here. If Refinement Types were
proposed in a GHC proposal a few years ago we’d be in a similarly hard
spot judging its merit. But the LH people chose a different path: They
(more or less) forked GHC, users who want to play around with it have
to install a separate program, but development can happen
independently, more rapidly and without the commitments to stability
that we expect from GHC. The downside is, of course, less adoption, no 
integration into existing libraries and maintenance overhead.

GHCJS is another example of that model.

How feasible would it to have a “lghc” fork that early adaptors can use
? I’d allow us to learn more about this feature, in particular its user
experience, user needs and adoption? If indeed existing code will
continue work as is, then a user of “lghc” still has all of Hackage at
their fingertips, so it seems somewhat realistic that a user who is
excited about linear types will actually use “lghc”.

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/20180709/af4433f4/attachment.sig>

From simonpj at microsoft.com  Mon Jul  9 13:43:38 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 9 Jul 2018 13:43:38 +0000
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <a756984b1372c4e1e93d8f32445044346304f6b9.camel@joachim-breitner.de>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <a756984b1372c4e1e93d8f32445044346304f6b9.camel@joachim-breitner.de>
Message-ID: <AM0PR83MB0308A91C097D23F16E0BE400AD440@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  How feasible would it to have a “lghc” fork that early adaptors can use ?

Obviously not impossible.  It'd imply a constant rebase burden. That's different to GHCJS and LH, which are much more modularly separable.

The key thing is the signal we send to the authors.  It could mean "go on a fork so we don't need to worry about you any more"  (After all, *anyone* can create a fork.... it does not need the committee's blessing.)   Or it could mean "we really like this and want to get more experience of it".  It'd be good to have a tangible way to express that difference.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
|  Behalf Of Joachim Breitner
|  Sent: 09 July 2018 14:35
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types
|  
|  Hi,
|  
|  Am Sonntag, den 08.07.2018, 23:41 -0400 schrieb Richard Eisenberg:
|  > And I don't think we'll be able to conjure up a better design without
|  > gaining experience with the proposed design, however flawed.
|  
|  I am wondering if we need in general a better way of allowing high-
|  risk/high-impact implementations to be tested in practice without needing to
|  merge them into the main compiler directly first.
|  
|  In a way Liquid Haskell is an example here. If Refinement Types were
|  proposed in a GHC proposal a few years ago we’d be in a similarly hard spot
|  judging its merit. But the LH people chose a different path: They (more or
|  less) forked GHC, users who want to play around with it have to install a
|  separate program, but development can happen independently, more rapidly and
|  without the commitments to stability that we expect from GHC. The downside
|  is, of course, less adoption, no integration into existing libraries and
|  maintenance overhead.
|  
|  GHCJS is another example of that model.
|  
|  How feasible would it to have a “lghc” fork that early adaptors can use ?
|  I’d allow us to learn more about this feature, in particular its user
|  experience, user needs and adoption? If indeed existing code will continue
|  work as is, then a user of “lghc” still has all of Hackage at their
|  fingertips, so it seems somewhat realistic that a user who is excited about
|  linear types will actually use “lghc”.
|  
|  Cheers,
|  Joachim
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C842bbce9f6c2404a
|  6ef108d5e5a0d59c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63666740129955
|  1567&amp;sdata=28CjA6toUq8RsGk1CxzeFrzI9xUhMsAi4PxJxJzO2zM%3D&amp;reserved=0

From rrnewton at indiana.edu  Mon Jul  9 13:46:14 2018
From: rrnewton at indiana.edu (Ryan Newton)
Date: Mon, 9 Jul 2018 09:46:14 -0400
Subject: [ghc-steering-committee] Solicitation for a new member
In-Reply-To: <2A3A0D97-17D6-4694-AD3A-C3E027C4FAD9@cs.brynmawr.edu>
References: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>
 <CANsrgP+tkuMjJta41V=T_RgbbFY2A4XdQU+tPHBz_i54fYsoJA@mail.gmail.com>
 <AM6PR83MB0309A521A20DC16816CE558AAD440@AM6PR83MB0309.EURPRD83.prod.outlook.com>
 <21A297A5-725D-4711-B498-113647BCB06C@justtesting.org>
 <2A3A0D97-17D6-4694-AD3A-C3E027C4FAD9@cs.brynmawr.edu>
Message-ID: <CACYs5AYBbh80-+7Rz2ZaMR17gQ4Sk5kyJSLE6ySvm9Smx2U9jg@mail.gmail.com>

+1 to Joachim's proposal.  Also, I wanted to thank him for handling this
and for all his other excellent management of this process.

I'm somewhat pulled away from the Haskell space at the moment (working
feverishly on a non-Haskell startup company during sabbatical), but I hope
to reengage with you all more fully at a future time.

Best regards,
  -Ryan



On Mon, Jul 9, 2018 at 8:30 AM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> Should we explicitly ask for responsiveness?
>
> For example, in the desired "properties" bullets, add:
>
> * normally responds to a technical email within 1-2 weeks
>
> And I would agree with the assessment that this takes ~2 hours/week.
>
> Richard
>
> On Jul 9, 2018, at 7:40 AM, Manuel M T Chakravarty <chak at justtesting.org>
> wrote:
>
> I agree with Simon’s point about self-nominations; otherwise, I like
> Joachim’s proposal.
>
> Manuel
>
> Am 09.07.2018 um 10:34 schrieb Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org>:
>
> Ryan Newton has expressed interest in being rotated out of the
> committee. I spoke to the Simons, and they indicate we should ask for
> public nominations. Here is a draft of a mail I’d send to the usual
> mailing lists. Please comment.
>
> Good draft.  I support “conservative”.  I have made some suggesting
> drafting amendments (highlighted) below.
>
> I think nominations of someone else are ok, provided said person has
> explicitly consented.  It’s affirming to be nominated, but it erodes that
> affirmation if the person doing the encouraging has to say “but you have to
> nominate yourself”.
>
> Simon
>
>
> ==========================
> Dear community,
>
> the GHC Steering committee is seeking nomination for a new member, and
> ask for self-nominations.
>
> The committee scrutinizes, nitpicks, improves, weights and eventually
> accepts or rejects proposals that extend or change the language
> supported by GHC and other (public-facing) aspects of GHC
> Our processes are described in the README in
> https://github.com/ghc-proposals/ghc-proposals
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0>
> which is also the GitHub repository where proposals are proposed.
>
> We are looking for a member who has the ability
>  * to understand such language extension proposals,
>  * to find holes and missing corner cases in the specifications,
>  * foresee the interaction with other language features and
>    specifications,
>  * make constructive comments and improvements,
>  * judge the cost/benefit ratio and
>  * finally come to a justifiable conclusion.
>
> We look for committee members who have some of these properties:
> * have substantial experience in writing Haskell applications or libraries,
>     which they can use to inform judgements about the utility or otherwise
>     of proposed features
> * have made active contributions to the Haskell community,
>     for some time
>  * have expertise in language design and implementation, in
>     either Haskell or related language, which they can share with us.
>
> The GHC developers themselves are already well represented already.  We
> seek Haskell *users* more than GHC hackers.
>
> The committee’s work requires a small, but non-trivial amount of time,
> especially when you are assigned a proposal for shepherding. Please
> keep that in mind if your email inbox is already overflowing.
>
> There is no shortage of people who are very eager to get fancy new
> features into the language, both in the committee and the wider
> community.  But each new feature imposes a cost, to implement, to learn,
> and (particularly) through its uexpected interaction with other features.
> We need to strike a balance, one that encourages innovation (as Haskell
> always has) while still making Haskell attractive for real-world production
> use.   We therefore explicitly invite “conservative” members of the
> community to join the committee.
>
> To nominate yourself, please send an email to me (as the committee
> secretary) at mail at joachim-breitner.de until July 20th. I will
> distribute the nominations among the committee, and we will keep the
> nominations and our deliberations private.
>
> You can nominate others, but you must obtain their explicit consent to do
> so.
> (We don’t want to choose someone who turns out to be unable to serve.)
>
> On behalf of the committee,
> Joachim Breitner
> ==========================
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org
> > *On Behalf Of *Simon Marlow
> *Sent:* 09 July 2018 08:23
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] Solicitation for a new member
>
>
> This looks great to me.
>
>
>
> On the amount of time required - can we put a ballpark figure on this?
> Perhaps 2 hours per week on average, more when going in depth into
> proposals. How much do other people spend? I worry that "small but
> non-trivial" means different things to different people.
>
>
>
> I'm ok with "conservative".
>
>
>
> Cheers
>
> Simon
>
>
>
> On 7 July 2018 at 15:48, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Dear Committee,
>
> Ryan Newton has expressed interest in being rotated out of the
> committee. I spoke to the Simons, and they indicate we should ask for
> public nominations. Here is a draft of a mail I’d send to the usual
> mailing lists. Please comment.
>
> ==========================
> Dear community,
>
> the GHC Steering committee is seeking nomination for a new member, and
> ask for self-nominations.
>
> The committee scrutinizes, nitpicks, improves, weights and eventually
> accepts or rejects proposals that extend or change the language
> supported by GHC and other (public-facing) aspects of GHC
> Our processes are described in the README in
> https://github.com/ghc-proposals/ghc-proposals
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065249408&sdata=X5dfzCxNJiKmvPkYrIEBTy4UZgCCmtiBJEXBsK21tVo%3D&reserved=0>
> which is also the GitHub repository where proposals are proposed.
>
> We are looking for a member who has the ability
>  * to understand such language extension proposals,
>  * to find holes and missing corner cases in the specifications,
>  * foresee the interaction with other language features and
>    specifications,
>  * make constructive comments and improvements,
>  * judge the cost/benefit ratio and
>  * finally come to a justifiable conclusion.
>
> Particular pluses that we look for are
>  * candidates who have been in the community for some time, and/or
>  * who have expertise in language design and implementation in
>    related language, which they can share with us.
>
> The committee work requires a small, but non-trivial amount of time,
> especially when you are assigned a proposal for shepherding. Please
> keep that in mind if your email inbox is already flowing over.
>
> There is no shortage of people who are very eager to get fancy new
> features into the language, both in the committee and the wider
> community. I therefore explicitly invite “conservative” members of the
> community to join the committee.
>
> The GHC developers themselves are nicely represented already. Having
> hacked on GHC is not a requirement.
>
>
> To nominate yourself, please send an email to me (as the committee
> secretary) at mail at joachim-breitner.de until July 20th. I will
> distribute the nominations among the committee, and we will keep the
> nominations and our deliberations private.
>
> You cannot nominate others. But if you know of anyone else you’d think
> should be on the committee, please do encourage them, or talk to us and
> we can encourage them.
>
> On behalf of the committee,
> Joachim Breitner
> ==========================
>
>
> Note worth discussing:
>
>  * I see no point in non-self-nominations. We can only have members
>    that want to do this.
>
>  * Do we want to encourage “conservative” members? Is that the right
>    wording? (I see the committee a bit as a flood gate that protects
>    against premature and not-worth-it changes. We are doing a good
>    job of that – most of my proposals get rejected ;-) – but I think
>    it would not hurt to explicitly keep it that way.
>
>  * One could consider public nominations and deliberations, but I feel
>    that a public discussion of who we think is the “best” is not very
>    nice.
>
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccac1713fd9614f04d17d08d5e56cdc25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667178065259412&sdata=vab8j7i%2F9tp7QLt4CicceON5iDPoj779PGgH7KBEXpo%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
>
>
> _______________________________________________
> 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/20180709/0564c92e/attachment-0001.html>

From rrnewton at indiana.edu  Mon Jul  9 13:51:28 2018
From: rrnewton at indiana.edu (Ryan Newton)
Date: Mon, 9 Jul 2018 09:51:28 -0400
Subject: [ghc-steering-committee] Replace atomicModifyMutVar# (#149),
 recommendation: accept
In-Reply-To: <CANsrgPJ6Ljnaw+u7GJbqjOJ_cnZ3j0UEi4nxFH2c9Y+hycHWCw@mail.gmail.com>
References: <CANsrgPLrQSi4Dqet1HoXtAtXQ6oUGf2HTsJ3_+1p1W1E1-rNuw@mail.gmail.com>
 <AM0PR83MB030858C64832074A871140D2AD400@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <CANsrgPJ6Ljnaw+u7GJbqjOJ_cnZ3j0UEi4nxFH2c9Y+hycHWCw@mail.gmail.com>
Message-ID: <CACYs5AaNf3aFao_33nQ4eoW+bDza3f=nqmRAEpx18KM5bbfUug@mail.gmail.com>

My only initial reservation was it being subsumed by mutable structs.  But
if it's small, self contained, already implemented, and doesn't increase
complexity -- why not?





On Thu, Jul 5, 2018 at 3:03 PM Simon Marlow <marlowsd at gmail.com> wrote:

> On 5 July 2018 at 16:24, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>
>> It sounds good to me – I have not dug into the details but it seems to
>> have had enough scrutiny.
>>
>>
>>
>> Note that it *replaces one primop with another*, with the old one being
>> re-defined as an ordinary function for back-compat.   The proposal does not
>> just add an extra primop.  Right?
>>
>>
> Yes, that's right.
>
> Simon
>
>
>>
>>
>> I’m supportive, albeit not very well informed.
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon Marlow
>> *Sent:* 04 July 2018 10:19
>> *To:* ghc-steering-committee at haskell.org
>> *Subject:* [ghc-steering-committee] Replace atomicModifyMutVar# (#149),
>> recommendation: accept
>>
>>
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/149
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F149&data=02%7C01%7Csimonpj%40microsoft.com%7Caf6991e741df405fd5a308d5e18f477f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662927862631135&sdata=biPMT2Nj9w7jJHUSdHU3eaHMS9wOzIbm7w%2B6txXLpeE%3D&reserved=0>
>>
>>
>>
>> This proposal is essentially an optimisation to the atomicModifyMutVar#
>> primitive. I won't repeat the details here, but it amounts to moving one of
>> the thunks produced by atomicModifyMutVar# out of the primop and into the
>> atomicModifyIORef wrapper. The advantage is that in the case of the strict
>> version of the wrapper, atomicModifyIORef', this extra thunk is eliminated
>> entirely, rather than being created by the primop and then immediately
>> evaluated by the wrapper.
>>
>>
>>
>> I propose we accept the proposal to add the new primop in section 2.1,
>> along with the straightforward additions proposed in sections 2.2 and 2.3.
>> (the old primop will be removed, but can be defined in GHC.Exts  as a
>> wrapper around the new primop for backwards compat)
>>
>>
>>
>> However, the additions to the Data.IORef library should be considered by
>> the libraries committee separately. (there are naming issues to be resolved
>> in particular).
>>
>>
>>
>> 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/20180709/95e48235/attachment.html>

From chak at justtesting.org  Mon Jul  9 15:03:40 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Mon, 9 Jul 2018 17:03:40 +0200
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <AM0PR83MB0308A91C097D23F16E0BE400AD440@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <a756984b1372c4e1e93d8f32445044346304f6b9.camel@joachim-breitner.de>
 <AM0PR83MB0308A91C097D23F16E0BE400AD440@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <FF0BFB79-4014-4EA9-8554-DFFE54CA064A@justtesting.org>

I don’t think relegating an accepted proposal to a fork is a reasonable alternative. Why go through the, for a large proposal, rather painful proposal process just so that you can do what you can also do without that blessing?

In fact, if we are going to take that stance, I think, we will seriously discourage contributions to GHC that involve more substantial language changes. I think that would be a very bad development as it makes GHC a much less attractive vehicle for that sort of research.

By their nature, proposals that fall into that category (that they have a serious impact on GHC) are also the ones that are the most painful to maintain as a fork. Serious impact means a large overlap with central elements of the compiler, which are constantly changing and hence require constant attention (rebasing, tracking bug fixes[1], etc) from the team maintaining the fork.

Specifically concerning the linear types proposal, I can assure you that maintaining the fork has very significant costs (time which maybe would have been better spent on improving the contribution rather than just chasing after the main compiler). At some point, these costs need to pay their dues and lead to inclusion into the compiler; otherwise, the fork will die like many in GHC’s past have.

I also don’t think, we can compare the situation to LH. Firstly, an extension needs to meet certain properties so that it can go into what is effectively a post-processor. Secondly, the structure of LH is currently rather incompatible with that of GHC (specifically generating type errors in a Core pass). So, having a separate implementation was probably the easier way to get started anyway.

As for GHCJS, they do pay a high price and constantly lag behind the main compiler. Moreover, they do ”only” change the backend. The maintenance burden for an extension that affects everything starting from the frontend is much higher.

In summary, I think, we need to bite the bullet. If the *potential* gain of an extension is sufficiently high and it passes the proposal process, I think, we need to allow it into the main compiler. Otherwise, GHC’s potential as a research vehicle will be seriously limited.

Cheers,
Manuel

[1] Including running into bugs that have already been fixed in the main compiler and wasting precious development time on them.

> Am 09.07.2018 um 15:43 schrieb Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>:
> 
> |  How feasible would it to have a “lghc” fork that early adaptors can use ?
> 
> Obviously not impossible.  It'd imply a constant rebase burden. That's different to GHCJS and LH, which are much more modularly separable.
> 
> The key thing is the signal we send to the authors.  It could mean "go on a fork so we don't need to worry about you any more"  (After all, *anyone* can create a fork.... it does not need the committee's blessing.)   Or it could mean "we really like this and want to get more experience of it".  It'd be good to have a tangible way to express that difference.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
> |  Behalf Of Joachim Breitner
> |  Sent: 09 July 2018 14:35
> |  To: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types
> |
> |  Hi,
> |
> |  Am Sonntag, den 08.07.2018, 23:41 -0400 schrieb Richard Eisenberg:
> |  > And I don't think we'll be able to conjure up a better design without
> |  > gaining experience with the proposed design, however flawed.
> |
> |  I am wondering if we need in general a better way of allowing high-
> |  risk/high-impact implementations to be tested in practice without needing to
> |  merge them into the main compiler directly first.
> |
> |  In a way Liquid Haskell is an example here. If Refinement Types were
> |  proposed in a GHC proposal a few years ago we’d be in a similarly hard spot
> |  judging its merit. But the LH people chose a different path: They (more or
> |  less) forked GHC, users who want to play around with it have to install a
> |  separate program, but development can happen independently, more rapidly and
> |  without the commitments to stability that we expect from GHC. The downside
> |  is, of course, less adoption, no integration into existing libraries and
> |  maintenance overhead.
> |
> |  GHCJS is another example of that model.
> |
> |  How feasible would it to have a “lghc” fork that early adaptors can use ?
> |  I’d allow us to learn more about this feature, in particular its user
> |  experience, user needs and adoption? If indeed existing code will continue
> |  work as is, then a user of “lghc” still has all of Hackage at their
> |  fingertips, so it seems somewhat realistic that a user who is excited about
> |  linear types will actually use “lghc”.
> |
> |  Cheers,
> |  Joachim
> |
> |  --
> |  Joachim Breitner
> |    mail at joachim-breitner.de
> |
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-
> |  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C842bbce9f6c2404a
> |  6ef108d5e5a0d59c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63666740129955
> |  1567&amp;sdata=28CjA6toUq8RsGk1CxzeFrzI9xUhMsAi4PxJxJzO2zM%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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180709/fe705f31/attachment.sig>

From marlowsd at gmail.com  Mon Jul  9 15:10:15 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 9 Jul 2018 16:10:15 +0100
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
Message-ID: <CANsrgPJLDb6rahyRTGPox_S+-+HTOvWO2vqLKG1Cgw849gsANQ@mail.gmail.com>

On 9 July 2018 at 04:41, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:

> I have volunteered to shepherd Proposal #111: Linear Types. The pull
> request is here: https://github.com/ghc-proposals/ghc-proposals/pull/111
>
> The authors propose adding linear functions to GHC. The argument to a
> linear function must be used exactly once in the function body. Motivation
> for this feature abounds -- essentially, linear types allow for better
> static checking around resource allocation and deallocation. I refer you to
> the proposal (and published paper) for more details here. The proposal also
> contains multiplicity polymorphism, where a higher-order function can be
> polymorphic in the multiplicity of a supplied function. Datatypes are
> linear by default, with a long list of (in my opinion, non-obvious) rules
> around syntax and exceptions to those rules. Constructors have a different
> multiplicity when used in an expression than they do when used in a
> pattern, for example. The authors leave type inference as an open question
> and do not state how the feature would work with either view patterns or
> pattern synonyms. The proposal comes with a companion document detailing
> the changes to Core. These changes seem appropriate.
>
> The current proposal has a fair number of open questions. I've written a
> long comment on the GitHub trail detailing what I was uncertain of. The
> proposal is not currently near the level of crispness of the proposals we
> normally accept. For a smaller proposal, I would just send it back to the
> authors without really giving it to the committee. However, there has been
> a great deal of effort behind writing this proposal and building an
> implementation, and so I think it's only fair that we give some thought
> about the general direction being worked in here.
>
> As to the features themselves: I'm personally far from convinced. Though I
> see no better way to achieve the authors' goals, the feature they have
> proposed is full of both sharp and dark corners. If implemented, there
> would be regular questions cropping up as to why such-and-such is the case
> or why the design is the way it is. However, this is well motivated and
> eagerly anticipated. And I don't think we'll be able to conjure up a better
> design without gaining experience with the proposed design, however flawed.
>

I'm feeling somewhat concerned about the power-to-weight ratio of linear
types, especially given that it doesn't cover exceptions.

Speaking with my industrialist hat on, as I look at our sprawling system
with a huge number of explicitly-managed resources, I should be squarely in
the target audience, but I'm not sure that linear types are going to help
us all that much.  Most resources are allocated with a bracket pattern
(bracket allocate deallocate $ \resource -> do ...) or using a withFoo
combinator.  These give clear scoping and exception-safety to resource
allocation, and linear types don't offer any safety improvements here - as
I understand it the bracket pattern will remain the safest way to manage
explicit resources in cases where it can be used. Files are not typically
opened and closed using separate operations, people use the withFile
combinator, because it's much easier to get right. The same goes for most
resources - common practice is to expose a withFoo combinator for every
explicitly managed resource.

In our system there are a few places where the bracket pattern doesn't fit.
The ones that spring to mind are where resources are allocated in C++ and
released in Haskell or allocated in Haskell and then released in a
different Haskell thread after receiving a message from C++. Linear types
might help model correct lifetime in these cases, but our experience has
been that safety in these cases has only been an issue where exceptions are
concerned - and linear types doesn't help with that.  In the case of
receiving a resource from C++ I need to carefully use
Control.Exception.mask and an exception handler to avoid leaks, which is by
far the hardest thing to get right. I would love to have some static
checking that this was done correctly throughout our codebase.

Perhaps what I should do is a complete audit of our codebase to evaluate
the opportunities for linear types to help.

I understand there are other motivations beyond explicit resource
management. But resource management is a big one, and it seems like linear
types don't help in some large fraction of cases, yet it's a deeply
invasive change. That worries me quite a lot.

(of course none of this should stop experimentation, but if we're taking
the temperature of the committee, currently I'm somewhat lukewarm)

Cheers
Simon

I thus recommend: Encouragement to continue the proposal and
> implementation, with an eye toward acceptance. Furthermore, if/when merged,
> I would like to advertise that the feature is subject to change, with no
> backward compatibility guarantee, for several versions. If the feature is
> implemented and merged, we will learn more about it and then perhaps refine
> it in the future.
>
> 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/20180709/0d7d696b/attachment-0001.html>

From rae at cs.brynmawr.edu  Tue Jul 10 00:00:45 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 9 Jul 2018 20:00:45 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <FF0BFB79-4014-4EA9-8554-DFFE54CA064A@justtesting.org>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <a756984b1372c4e1e93d8f32445044346304f6b9.camel@joachim-breitner.de>
 <AM0PR83MB0308A91C097D23F16E0BE400AD440@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <FF0BFB79-4014-4EA9-8554-DFFE54CA064A@justtesting.org>
Message-ID: <37CF77FB-E3B7-4998-860D-0F0CAA4FB90D@cs.brynmawr.edu>

I want to second Manuel's arguments here -- I don't think we can suggest that someone forks the compiler. In effect, this is already true during development. Speaking as the developer of TypeInType (which I think is an apt comparison in many respects to LinearTypes), operating on a fork cost me a lot of time indeed. There's no other way to do it during development, but it's not sustainable for very long.

Simon M, you've made good points about the motivations. Perhaps could you summarize your thoughts on the GitHub trail so we can get a response from the proposal authors?

Thanks,
Richard

> On Jul 9, 2018, at 11:03 AM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> 
> I don’t think relegating an accepted proposal to a fork is a reasonable alternative. Why go through the, for a large proposal, rather painful proposal process just so that you can do what you can also do without that blessing?
> 
> In fact, if we are going to take that stance, I think, we will seriously discourage contributions to GHC that involve more substantial language changes. I think that would be a very bad development as it makes GHC a much less attractive vehicle for that sort of research.
> 
> By their nature, proposals that fall into that category (that they have a serious impact on GHC) are also the ones that are the most painful to maintain as a fork. Serious impact means a large overlap with central elements of the compiler, which are constantly changing and hence require constant attention (rebasing, tracking bug fixes[1], etc) from the team maintaining the fork.
> 
> Specifically concerning the linear types proposal, I can assure you that maintaining the fork has very significant costs (time which maybe would have been better spent on improving the contribution rather than just chasing after the main compiler). At some point, these costs need to pay their dues and lead to inclusion into the compiler; otherwise, the fork will die like many in GHC’s past have.
> 
> I also don’t think, we can compare the situation to LH. Firstly, an extension needs to meet certain properties so that it can go into what is effectively a post-processor. Secondly, the structure of LH is currently rather incompatible with that of GHC (specifically generating type errors in a Core pass). So, having a separate implementation was probably the easier way to get started anyway.
> 
> As for GHCJS, they do pay a high price and constantly lag behind the main compiler. Moreover, they do ”only” change the backend. The maintenance burden for an extension that affects everything starting from the frontend is much higher.
> 
> In summary, I think, we need to bite the bullet. If the *potential* gain of an extension is sufficiently high and it passes the proposal process, I think, we need to allow it into the main compiler. Otherwise, GHC’s potential as a research vehicle will be seriously limited.
> 
> Cheers,
> Manuel
> 
> [1] Including running into bugs that have already been fixed in the main compiler and wasting precious development time on them.
> 
>> Am 09.07.2018 um 15:43 schrieb Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>:
>> 
>> |  How feasible would it to have a “lghc” fork that early adaptors can use ?
>> 
>> Obviously not impossible.  It'd imply a constant rebase burden. That's different to GHCJS and LH, which are much more modularly separable.
>> 
>> The key thing is the signal we send to the authors.  It could mean "go on a fork so we don't need to worry about you any more"  (After all, *anyone* can create a fork.... it does not need the committee's blessing.)   Or it could mean "we really like this and want to get more experience of it".  It'd be good to have a tangible way to express that difference.
>> 
>> Simon
>> 
>> |  -----Original Message-----
>> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
>> |  Behalf Of Joachim Breitner
>> |  Sent: 09 July 2018 14:35
>> |  To: ghc-steering-committee at haskell.org
>> |  Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types
>> |
>> |  Hi,
>> |
>> |  Am Sonntag, den 08.07.2018, 23:41 -0400 schrieb Richard Eisenberg:
>> |  > And I don't think we'll be able to conjure up a better design without
>> |  > gaining experience with the proposed design, however flawed.
>> |
>> |  I am wondering if we need in general a better way of allowing high-
>> |  risk/high-impact implementations to be tested in practice without needing to
>> |  merge them into the main compiler directly first.
>> |
>> |  In a way Liquid Haskell is an example here. If Refinement Types were
>> |  proposed in a GHC proposal a few years ago we’d be in a similarly hard spot
>> |  judging its merit. But the LH people chose a different path: They (more or
>> |  less) forked GHC, users who want to play around with it have to install a
>> |  separate program, but development can happen independently, more rapidly and
>> |  without the commitments to stability that we expect from GHC. The downside
>> |  is, of course, less adoption, no integration into existing libraries and
>> |  maintenance overhead.
>> |
>> |  GHCJS is another example of that model.
>> |
>> |  How feasible would it to have a “lghc” fork that early adaptors can use ?
>> |  I’d allow us to learn more about this feature, in particular its user
>> |  experience, user needs and adoption? If indeed existing code will continue
>> |  work as is, then a user of “lghc” still has all of Hackage at their
>> |  fingertips, so it seems somewhat realistic that a user who is excited about
>> |  linear types will actually use “lghc”.
>> |
>> |  Cheers,
>> |  Joachim
>> |
>> |  --
>> |  Joachim Breitner
>> |    mail at joachim-breitner.de
>> |
>> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-
>> |  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C842bbce9f6c2404a
>> |  6ef108d5e5a0d59c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63666740129955
>> |  1567&amp;sdata=28CjA6toUq8RsGk1CxzeFrzI9xUhMsAi4PxJxJzO2zM%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
> 
> _______________________________________________
> 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  Tue Jul 10 01:39:35 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 09 Jul 2018 21:39:35 -0400
Subject: [ghc-steering-committee] Solicitation for a new member
In-Reply-To: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>
References: <e11ee09d0472e1c3a14c59bd7ebc1a0a664c9530.camel@joachim-breitner.de>
Message-ID: <ea5b5278d5f7e6af306a555586a3caa7b8e99ca3.camel@joachim-breitner.de>

Hi,

thanks for all your feedback. Here is an updated draft – basically
Simons version, with the explicit time and responsiveness requirements
that Richard mentined, and I took the liberty of putting “education”
next to “real-world production use”. Will send this out in a day or
two.

Cheers,
Joachim

=====
Dear community,

the GHC Steering committee is seeking nomination for a new member, and
ask for self-nominations.

The committee scrutinizes, nitpicks, improves, weights and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC
Our processes are described in the README in
https://github.com/ghc-proposals/ghc-proposals
which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability 
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and 
   specifications,
 * make constructive comments and improvements,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

We look for committee members who have some of these properties:
 * have substantial experience in writing Haskell applications or
   libraries, which they can use to inform judgements about the utility
   or otherwise of proposed features
 * have made active contributions to the Haskell community, for some
   time
 * have expertise in language design and implementation, in either
   Haskell or related language, which they can share with us.

The GHC developers themselves are already well represented already.  We
seek Haskell _users_ more than GHC hackers.

The committee’s work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. We
estimate the workload to be around 2 hours per week, and our process
works best if members usually respond to technical emails within 1-2
weeks. Please keep that in mind if your email inbox is already
overflowing.

There is no shortage of people who are very eager to get fancy new
features into the language, both in the committee and the wider
community. But each new feature imposes a cost, to implement, to learn,
(particularly) through its unexpected interaction with other features.
We need to strike a balance, one that encourages innovation (as Haskell
always has) while still making Haskell attractive for real-world
production use and for teaching. We therefore explicitly invite
“conservative” members of the community to join the committee.

To nominate yourself, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de until July 23th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

You can nominate others, but please obtain their explicit consent to do
so. (We don’t want to choose someone who turns out to be unable to
serve.)

On behalf of the committee,
Joachim Breitner

=====
-- 
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/20180709/0f6aa4c8/attachment.sig>

From simonpj at microsoft.com  Tue Jul 10 07:26:21 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Jul 2018 07:26:21 +0000
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <37CF77FB-E3B7-4998-860D-0F0CAA4FB90D@cs.brynmawr.edu>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <a756984b1372c4e1e93d8f32445044346304f6b9.camel@joachim-breitner.de>
 <AM0PR83MB0308A91C097D23F16E0BE400AD440@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <FF0BFB79-4014-4EA9-8554-DFFE54CA064A@justtesting.org>
 <37CF77FB-E3B7-4998-860D-0F0CAA4FB90D@cs.brynmawr.edu>
Message-ID: <AM0PR83MB03088033C69951242F026619AD5B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  I want to second Manuel's arguments here -- I don't think we can suggest
|  that someone forks the compiler.

+1.  It's possible in theory, as I said, but in practice it'd kill the proposal.

It's also worth bearing in mind that the proposers have made a very substantial
investment in getting it this far, precisely because it is a "big" proposal.

Simon

|  -----Original Message-----
|  From: Richard Eisenberg <rae at cs.brynmawr.edu>
|  Sent: 10 July 2018 01:01
|  To: Manuel M T Chakravarty <chak at justtesting.org>
|  Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-
|  committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
|  Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types
|  
|  I want to second Manuel's arguments here -- I don't think we can suggest
|  that someone forks the compiler. In effect, this is already true during
|  development. Speaking as the developer of TypeInType (which I think is an
|  apt comparison in many respects to LinearTypes), operating on a fork cost me
|  a lot of time indeed. There's no other way to do it during development, but
|  it's not sustainable for very long.
|  
|  Simon M, you've made good points about the motivations. Perhaps could you
|  summarize your thoughts on the GitHub trail so we can get a response from
|  the proposal authors?
|  
|  Thanks,
|  Richard
|  
|  > On Jul 9, 2018, at 11:03 AM, Manuel M T Chakravarty <chak at justtesting.org>
|  wrote:
|  >
|  > I don’t think relegating an accepted proposal to a fork is a reasonable
|  alternative. Why go through the, for a large proposal, rather painful
|  proposal process just so that you can do what you can also do without that
|  blessing?
|  >
|  > In fact, if we are going to take that stance, I think, we will seriously
|  discourage contributions to GHC that involve more substantial language
|  changes. I think that would be a very bad development as it makes GHC a much
|  less attractive vehicle for that sort of research.
|  >
|  > By their nature, proposals that fall into that category (that they have a
|  serious impact on GHC) are also the ones that are the most painful to
|  maintain as a fork. Serious impact means a large overlap with central
|  elements of the compiler, which are constantly changing and hence require
|  constant attention (rebasing, tracking bug fixes[1], etc) from the team
|  maintaining the fork.
|  >
|  > Specifically concerning the linear types proposal, I can assure you that
|  maintaining the fork has very significant costs (time which maybe would have
|  been better spent on improving the contribution rather than just chasing
|  after the main compiler). At some point, these costs need to pay their dues
|  and lead to inclusion into the compiler; otherwise, the fork will die like
|  many in GHC’s past have.
|  >
|  > I also don’t think, we can compare the situation to LH. Firstly, an
|  extension needs to meet certain properties so that it can go into what is
|  effectively a post-processor. Secondly, the structure of LH is currently
|  rather incompatible with that of GHC (specifically generating type errors in
|  a Core pass). So, having a separate implementation was probably the easier
|  way to get started anyway.
|  >
|  > As for GHCJS, they do pay a high price and constantly lag behind the main
|  compiler. Moreover, they do ”only” change the backend. The maintenance
|  burden for an extension that affects everything starting from the frontend
|  is much higher.
|  >
|  > In summary, I think, we need to bite the bullet. If the *potential* gain
|  of an extension is sufficiently high and it passes the proposal process, I
|  think, we need to allow it into the main compiler. Otherwise, GHC’s
|  potential as a research vehicle will be seriously limited.
|  >
|  > Cheers,
|  > Manuel
|  >
|  > [1] Including running into bugs that have already been fixed in the main
|  compiler and wasting precious development time on them.
|  >
|  >> Am 09.07.2018 um 15:43 schrieb Simon Peyton Jones via ghc-steering-
|  committee <ghc-steering-committee at haskell.org>:
|  >>
|  >> |  How feasible would it to have a “lghc” fork that early adaptors can
|  use ?
|  >>
|  >> Obviously not impossible.  It'd imply a constant rebase burden. That's
|  different to GHCJS and LH, which are much more modularly separable.
|  >>
|  >> The key thing is the signal we send to the authors.  It could mean "go on
|  a fork so we don't need to worry about you any more"  (After all, *anyone*
|  can create a fork.... it does not need the committee's blessing.)   Or it
|  could mean "we really like this and want to get more experience of it".
|  It'd be good to have a tangible way to express that difference.
|  >>
|  >> Simon
|  >>
|  >> |  -----Original Message-----
|  >> |  From: ghc-steering-committee
|  >> | <ghc-steering-committee-bounces at haskell.org> On  Behalf Of Joachim
|  >> | Breitner
|  >> |  Sent: 09 July 2018 14:35
|  >> |  To: ghc-steering-committee at haskell.org
|  >> |  Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types
|  >> |
|  >> |  Hi,
|  >> |
|  >> |  Am Sonntag, den 08.07.2018, 23:41 -0400 schrieb Richard Eisenberg:
|  >> |  > And I don't think we'll be able to conjure up a better design
|  >> | without  > gaining experience with the proposed design, however flawed.
|  >> |
|  >> |  I am wondering if we need in general a better way of allowing
|  >> | high-  risk/high-impact implementations to be tested in practice
|  >> | without needing to  merge them into the main compiler directly first.
|  >> |
|  >> |  In a way Liquid Haskell is an example here. If Refinement Types
|  >> | were  proposed in a GHC proposal a few years ago we’d be in a
|  >> | similarly hard spot  judging its merit. But the LH people chose a
|  >> | different path: They (more or
|  >> |  less) forked GHC, users who want to play around with it have to
|  >> | install a  separate program, but development can happen
|  >> | independently, more rapidly and  without the commitments to
|  >> | stability that we expect from GHC. The downside  is, of course,
|  >> | less adoption, no integration into existing libraries and  maintenance
|  overhead.
|  >> |
|  >> |  GHCJS is another example of that model.
|  >> |
|  >> |  How feasible would it to have a “lghc” fork that early adaptors can
|  use ?
|  >> |  I’d allow us to learn more about this feature, in particular its
|  >> | user  experience, user needs and adoption? If indeed existing code
|  >> | will continue  work as is, then a user of “lghc” still has all of
|  >> | Hackage at their  fingertips, so it seems somewhat realistic that a
|  >> | user who is excited about  linear types will actually use “lghc”.
|  >> |
|  >> |  Cheers,
|  >> |  Joachim
|  >> |
|  >> |  --
|  >> |  Joachim Breitner
|  >> |    mail at joachim-breitner.de
|  >> |
|  >> |
|  >> | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
|  >> | .joachim-
|  >> | breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C842bbce
|  >> | 9f6c2404a
|  >> |
|  >> | 6ef108d5e5a0d59c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63666
|  >> | 740129955
|  >> |
|  >> | 1567&amp;sdata=28CjA6toUq8RsGk1CxzeFrzI9xUhMsAi4PxJxJzO2zM%3D&amp;r
|  >> | eserved=0
|  >> _______________________________________________
|  >> ghc-steering-committee mailing list
|  >> ghc-steering-committee at haskell.org
|  >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit
|  >> tee
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ
|  > ee


From mail at joachim-breitner.de  Tue Jul 10 15:56:20 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 10 Jul 2018 11:56:20 -0400
Subject: [ghc-steering-committee] Remove TypeOperators => NoStarIsType
 "migration" (#146); Recommendation: accept
In-Reply-To: <871scltkqc.fsf@smart-cactus.org>
References: <87wounvti9.fsf@smart-cactus.org> <871scltkqc.fsf@smart-cactus.org>
Message-ID: <d93ba4057b8abde37888046a8baca48f785de923.camel@joachim-breitner.de>

Hi,

Am Montag, den 02.07.2018, 17:02 -0400 schrieb Ben Gamari:
> Ben Gamari <ben at well-typed.com> writes:
> 
> > Hi everyone,
> > 
> > We are being asked to consider pull request #146. This proposal is an
> > amendment to the accepted Proposal 0020 [1], removing a migration
> > mechanism which was found in practice to hurt more than help.
> > 
> 
> If anyone has any objection do say so. If none is expressed in the next
> two days I will merge.

merged.

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/20180710/a2de0f3a/attachment.sig>

From mail at joachim-breitner.de  Wed Jul 11 12:38:21 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 11 Jul 2018 08:38:21 -0400
Subject: [ghc-steering-committee] Replace atomicModifyMutVar# (#149),
 recommendation: accept
In-Reply-To: <CANsrgPLrQSi4Dqet1HoXtAtXQ6oUGf2HTsJ3_+1p1W1E1-rNuw@mail.gmail.com>
References: <CANsrgPLrQSi4Dqet1HoXtAtXQ6oUGf2HTsJ3_+1p1W1E1-rNuw@mail.gmail.com>
Message-ID: <9ed990de0439da1fbf93892e412923c91bf5825f.camel@joachim-breitner.de>

Hi,

I see clear agreement, accepted!

Joachim

Am Mittwoch, den 04.07.2018, 10:19 +0100 schrieb Simon Marlow:
> https://github.com/ghc-proposals/ghc-proposals/pull/149
> 
> This proposal is essentially an optimisation to the atomicModifyMutVar# primitive. I won't repeat the details here, but it amounts to moving one of the thunks produced by atomicModifyMutVar# out of the primop and into the atomicModifyIORef wrapper. The advantage is that in the case of the strict version of the wrapper, atomicModifyIORef', this extra thunk is eliminated entirely, rather than being created by the primop and then immediately evaluated by the wrapper.
> 
> I propose we accept the proposal to add the new primop in section 2.1, along with the straightforward additions proposed in sections 2.2 and 2.3. (the old primop will be removed, but can be defined in GHC.Exts  as a wrapper around the new primop for backwards compat)
> 
> However, the additions to the Data.IORef library should be considered by the libraries committee separately. (there are naming issues to be resolved in particular).
> 
> Cheers
> Simon
> _______________________________________________
> 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/20180711/dd7509b2/attachment.sig>

From mail at joachim-breitner.de  Sat Jul 14 18:46:56 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 14 Jul 2018 14:46:56 -0400
Subject: [ghc-steering-committee] Please Review: Remove * syntax (#143),
	Shepherd: Ben Gamari
Message-ID: <511625ed2d985d563608185968ab0ecd44d25fa2.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Remove * kind syntax (#143) by Vladislav Zavialov was proposed.
https://github.com/ghc-proposals/ghc-proposals/pull/143

I propose Ben Gamari as the shepherd, because he probably has the stuff
paged in from shepherding #146

Ben, 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/20180714/aa1884b6/attachment.sig>

From mail at joachim-breitner.de  Sat Jul 14 18:52:24 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 14 Jul 2018 14:52:24 -0400
Subject: [ghc-steering-committee] Deprecating Exports (#134);
 Recommendation: accept
In-Reply-To: <0181259F-D39E-4A4A-AEDA-594CDC85600D@cs.brynmawr.edu>
References: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de>
 <4486bc5bb722ddc615a0f2199c85dd20dca89910.camel@joachim-breitner.de>
 <AE19F501-D902-40E4-A0AA-9E38F4FC9617@cs.brynmawr.edu>
 <8aef3b219cc1034840980c609f7b65de5fc87979.camel@joachim-breitner.de>
 <0181259F-D39E-4A4A-AEDA-594CDC85600D@cs.brynmawr.edu>
Message-ID: <a322ee1ef2a251bd5f530dcb82519c96a35328f5.camel@joachim-breitner.de>

Hi,

I sense that we are happy with the feature and specification so far,
with corner cases resolved during implementation, and thus accept it
now.

Cheers,
Joachim

Am Sonntag, den 08.07.2018, 22:10 -0400 schrieb Richard Eisenberg:
> I generally agree, but Simon M and I have both staked out opposite opinions on the second bullet in https://github.com/ghc-proposals/ghc-proposals/pull/134#issuecomment-399726779   Simon, do you have a response to my thoughts there?
> 
> I'm happy enough to let my other complaint be lazily resolved during implementation.
> 
> Thanks,
> Richard
> 
> > On Jul 8, 2018, at 9:47 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Hi Richard,
> > 
> > have your reservations been addressed and/or resolved?
> > 
> > My impression is that overall, we approve of the feature, and I suggest
> > we accept the proposal as it, confident that any remaining corner cases
> > will be resolved in the process of implementing it, and in a way that
> > will be fine.
> > 
> > Cheers,
> > Joachim
> > 
> > Am Samstag, den 23.06.2018, 23:46 -0400 schrieb Richard Eisenberg:
> > > I have some reservations, though I like the overall idea. I've posted on GitHub.
> > > 
> > > Richard
> > > 
> > > > On Jun 23, 2018, at 12:13 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > > > 
> > > > Dear Committee,
> > > > 
> > > > Am Donnerstag, den 24.05.2018, 12:23 +0200 schrieb Joachim Breitner:
> > > > > alanasp has proposed a Deprecating Exports mechanism:
> > > > > https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst
> > > > > 
> > > > > I suggest acceptance!
> > > > 
> > > > thanks Iavor, Simon and Richard for refining the proposal (and sorry
> > > > for missing some of the obvious shortcomings). I believe the author
> > > > addressed the concerns, and now the proposal is better.
> > > > 
> > > > I even more suggest acceptance. If there is still disagreement, please
> > > > speak up.
> > > > 
> > > > 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
> > > 
> > > _______________________________________________
> > > 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
-- 
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/20180714/1bf3a6a3/attachment.sig>

From mail at joachim-breitner.de  Sat Jul 14 19:03:41 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 14 Jul 2018 15:03:41 -0400
Subject: [ghc-steering-committee] Request for Nominations to the GHC
	Steering Committee
Message-ID: <4fcd78fed019414a0b90884c4b72f42aa09aa6ea.camel@joachim-breitner.de>

Dear Haskell community,

the GHC Steering committee is seeking nominations for a new member.

The committee scrutinizes, nitpicks, improves, weights and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC.
Our processes are described at
   https://github.com/ghc-proposals/ghc-proposals
which is also the GitHub repository where proposals are proposed.

We are looking for a member who has the ability 
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and 
   specifications,
 * comment constructively and improve the proposals,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

We look for committee members who have some of these properties:
 * have substantial experience in writing Haskell applications or
   libraries, which they can use to inform judgements about the
   utility or otherwise of proposed features,
 * have made active contributions to the Haskell community, for
   some time,
 * have expertise in language design and implementation, in either
   Haskell or related languages, which they can share with us.

The committee’s work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. We
estimate the workload to be around 2 hours per week, and our process
works best if members usually respond to technical emails within 1-2
weeks (within days is even better). Please keep that in mind if your
email inbox is already overflowing.

The GHC developers themselves are already well represented already.  We
seek Haskell _users_ more than GHC hackers.

There is no shortage of people who are very eager to get fancy new
features into the language, both in the committee and the wider
community. But each new feature imposes a cost, to implement, to learn,
(particularly) through its unexpected interaction with other features.
We need to strike a balance, one that encourages innovation (as GHC
always has) while still making Haskell attractive for real-world
production use and for teaching. We therefore explicitly invite
“conservative” members of the community to join the committee.

To make a nomination, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de until July 23th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

We explicitly encourage self-nominations. You can nominate others, but
please obtain their explicit consent to do so. (We don’t want to choose
someone who turns out to be unable to serve.)

On behalf of the committee,
Joachim Breitner

-- 
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/20180714/4725ee86/attachment.sig>

From mail at joachim-breitner.de  Sat Jul 14 19:31:42 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 14 Jul 2018 15:31:42 -0400
Subject: [ghc-steering-committee] Please Review: Allow ScopedTypeVariables
 to refer to types (#128), Shepherd: Iavor
Message-ID: <4b9449d4b5d7cd7f325e09b1ef0bf0ac9f1440c1.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Allow ScopedTypeVariables to refer to types, by myself
https://github.com/ghc-proposals/ghc-proposals/pull/128

I propose Iavor as the shepherd. He is just too efficient an shepherd,
and the only non-chair-member without an open proposal on his plate
right now.

Iavor, 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/20180714/8f85728a/attachment.sig>

From ben at well-typed.com  Sat Jul 14 23:42:09 2018
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 14 Jul 2018 19:42:09 -0400
Subject: [ghc-steering-committee] Remove the * kind syntax (#143);
	Recommendation: accept
Message-ID: <87muuto04z.fsf@smart-cactus.org>

Hi everyone,

We are being asked to consider pull request #143. This proposal removes
the `*` symbol as a synonym for `Type`, finishing the work started by
the new `-XNoStarIsType` extension.

This proposal involves a protracted but warranted transition period. In short:

 1. `-XNoStarIsType` will be introduced in GHC 8.6

 2. Warnings will be introduced in GHC 8.8, increasing in visibility in
    later releases.

 3. `-XStarIsType` will be enabled by default starting 12 releases
    (roughly 7 years from now) after GHC 8.6.

 4. 15 releases (8.5 years from now) after GHC 8.6 `-XNoStarIsType` will
    be removed.

The reason for this breakage is that this change will have wide-spread
consequences: in addition to an estimated 25% of Hackage being affected,
a generation of written documentation and pedagogical material will need
to be revised.

While the costs of the change are high, so are the benefits.
`*` is an awkward special case in GHC's syntax and is quite hard to
search for. Moreover, the `StarIsType` will present a significant hurdle
to the future introduction of `DependentHaskell` since `*` may then
signify either term-level numeric multiplication or `Type`.

For these reasons my recommendation is that we accept the proposal.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180714/725c16ff/attachment.sig>

From mail at joachim-breitner.de  Sun Jul 15 13:06:35 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 15 Jul 2018 09:06:35 -0400
Subject: [ghc-steering-committee] Remove the * kind syntax (#143);
 Recommendation: accept
In-Reply-To: <87muuto04z.fsf@smart-cactus.org>
References: <87muuto04z.fsf@smart-cactus.org>
Message-ID: <98e1333abc25a74fb052d8cd1052c5fcb520c91a.camel@joachim-breitner.de>

Hi,

Am Samstag, den 14.07.2018, 19:42 -0400 schrieb Ben Gamari:
> This proposal involves a protracted but warranted transition period. In short:
> 
>  1. `-XNoStarIsType` will be introduced in GHC 8.6
> 
>  2. Warnings will be introduced in GHC 8.8, increasing in visibility in
>     later releases.
> 
>  3. `-XStarIsType` will be enabled by default starting 12 releases
>     (roughly 7 years from now) after GHC 8.6.

fine with me so far.

>  4. 15 releases (8.5 years from now) after GHC 8.6 `-XNoStarIsType` will
>     be removed.

I would rather reword this to “may be removed”, and leave it to the
future GHC developers to make the call. It may be that they decide that
the cost keeping the StarIsType code around is not that big, and that
the benefit of running old code  with less effort is higher, and I see
no reason to force their hand at this point. Instead of forcing, we
should at most give a mandate.

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/20180715/658e7ddb/attachment.sig>

From rae at cs.brynmawr.edu  Mon Jul 16 02:28:55 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 15 Jul 2018 22:28:55 -0400
Subject: [ghc-steering-committee] Remove the * kind syntax (#143);
 Recommendation: accept
In-Reply-To: <98e1333abc25a74fb052d8cd1052c5fcb520c91a.camel@joachim-breitner.de>
References: <87muuto04z.fsf@smart-cactus.org>
 <98e1333abc25a74fb052d8cd1052c5fcb520c91a.camel@joachim-breitner.de>
Message-ID: <0E969E49-522A-47DF-AEBB-9ECA3A23BA8E@cs.brynmawr.edu>

I think you have the polarity backwards. -XNoStarIsType will be enabled by default in 12 releases, and -XStarIsType will be removed after 15.

The future is always up for debate. The question, to me, is this: At the 15-release mark, would it take another proposal to

A) remove -XStarIsType, or
B) keep -XStarIsType

Accepting this proposal as-is means (B). In that scenario, we're not committed irreversibly to removing -XStarIsType; it just means that's our current plan. Someone from the future might propose changing the plan, and that could be considered in light of the greater information available in the future.

Thus, I think it's all good as is.

Richard

> On Jul 15, 2018, at 9:06 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Samstag, den 14.07.2018, 19:42 -0400 schrieb Ben Gamari:
>> This proposal involves a protracted but warranted transition period. In short:
>> 
>> 1. `-XNoStarIsType` will be introduced in GHC 8.6
>> 
>> 2. Warnings will be introduced in GHC 8.8, increasing in visibility in
>>    later releases.
>> 
>> 3. `-XStarIsType` will be enabled by default starting 12 releases
>>    (roughly 7 years from now) after GHC 8.6.
> 
> fine with me so far.
> 
>> 4. 15 releases (8.5 years from now) after GHC 8.6 `-XNoStarIsType` will
>>    be removed.
> 
> I would rather reword this to “may be removed”, and leave it to the
> future GHC developers to make the call. It may be that they decide that
> the cost keeping the StarIsType code around is not that big, and that
> the benefit of running old code  with less effort is higher, and I see
> no reason to force their hand at this point. Instead of forcing, we
> should at most give a mandate.
> 
> 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


From mail at joachim-breitner.de  Mon Jul 16 15:07:09 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 16 Jul 2018 11:07:09 -0400
Subject: [ghc-steering-committee] Please Review: Type applications in
 patterns (#126), Shepherd: Iavor again
Message-ID: <aac7d7266f07757e7a8915ec43a8d10a54e866c2.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Type applications in patterns, by myself and with help from Richard and
Simon PJ, was proposed
https://github.com/ghc-proposals/ghc-proposals/pull/126

I again propose Iavor as the shepherd. He already has #128 on his
plate, and although orthogonal, both touch the same area, both are
motivated and explained in more detail in the same paper, so maybe
looking at both together is insightful. Iavor, please speak up if you
find this is too much and would rather have this assigned to someone
else.

Iavor, 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/20180716/9ac90905/attachment.sig>

From iavor.diatchki at gmail.com  Mon Jul 16 20:33:34 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 16 Jul 2018 13:33:34 -0700
Subject: [ghc-steering-committee] Please Review: Type applications in
 patterns (#126), Shepherd: Iavor again
In-Reply-To: <aac7d7266f07757e7a8915ec43a8d10a54e866c2.camel@joachim-breitner.de>
References: <aac7d7266f07757e7a8915ec43a8d10a54e866c2.camel@joachim-breitner.de>
Message-ID: <CAGK9nurNhEoVPZyG8hmeebd_BDhmcL010TV2UNEtZkcOPkUxNw@mail.gmail.com>

That's OK---it is fun to be the shepherd for proposals that I am
enthusiastic about, and I think that both of these are a good idea and, as
you say, they are somewhat related.

On Mon, Jul 16, 2018 at 8:07 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Type applications in patterns, by myself and with help from Richard and
> Simon PJ, was proposed
> https://github.com/ghc-proposals/ghc-proposals/pull/126
>
> I again propose Iavor as the shepherd. He already has #128 on his
> plate, and although orthogonal, both touch the same area, both are
> motivated and explained in more detail in the same paper, so maybe
> looking at both together is insightful. Iavor, please speak up if you
> find this is too much and would rather have this assigned to someone
> else.
>
> Iavor, 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/20180716/93896de5/attachment.html>

From ben at well-typed.com  Mon Jul 16 22:24:37 2018
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 16 Jul 2018 18:24:37 -0400
Subject: [ghc-steering-committee] Remove the * kind syntax (#143);
	Recommendation: accept
In-Reply-To: <98e1333abc25a74fb052d8cd1052c5fcb520c91a.camel@joachim-breitner.de>
References: <87muuto04z.fsf@smart-cactus.org>
 <98e1333abc25a74fb052d8cd1052c5fcb520c91a.camel@joachim-breitner.de>
Message-ID: <87in5en7j3.fsf@smart-cactus.org>

Joachim Breitner <mail at joachim-breitner.de> writes:

snip
>
> I would rather reword this to “may be removed”, and leave it to the
> future GHC developers to make the call. It may be that they decide that
> the cost keeping the StarIsType code around is not that big, and that
> the benefit of running old code  with less effort is higher, and I see
> no reason to force their hand at this point. Instead of forcing, we
> should at most give a mandate.
>
That sounds reasonable to me.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180716/1dc28132/attachment.sig>

From mail at joachim-breitner.de  Sun Jul 22 14:14:08 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 22 Jul 2018 10:14:08 -0400
Subject: [ghc-steering-committee] Nominations status and voting procedure
In-Reply-To: <4fcd78fed019414a0b90884c4b72f42aa09aa6ea.camel@joachim-breitner.de>
References: <4fcd78fed019414a0b90884c4b72f42aa09aa6ea.camel@joachim-breitner.de>
Message-ID: <7050f9cfdd8c55d726df1438167c64822f5da367.camel@joachim-breitner.de>

Hi Committe,

just to keep you (and the curious public in the loop):

We have received five nominations so far, and I am very pleased with
them. They also arrived quite swiftly after the call, so these people
all seem to be responsive in a way that we appreciate :-)

What next? I will wait until after Monday, in case there are some more
nominations. Then I will paste all nominations into one email and send
it to the members of the committee (including the leaving Ryan, who
should have a say in his replacement – unless you, Ryan, would rather
not get involved), but _not_ this list (which is public)!

I propose we allow us one week to look at them and voice any opinions,
concerns and endorsements (using Reply-to-all, _not_ on this mailing
list).

After this week, I think we should have a proper vote on this, and not
just do the usual silence-is-consensus trick. I am a bit of a nerd when
it comes to voting systems, so I would like to so something better than
a simple majority vote: I will ask you to vote by making a complete
ranking of your choices. The winner will then be determined by
the Schulze Method (as used by Debian, FSFE and many other
organizations).

I will announce the result of the election on the mailing list, and
privately thanks the other nominations, without revealing who they are.

This voting system has the additional advantage that it gives us a
ranking of candidates, so if we chose to add more than one members at
this point (either to expand the committee, or if someone besides Ryan
wants to get out at this point), we can do that easily.

Cheers,
Joachim

[Schulze Method]: https://en.wikipedia.org/wiki/Schulze_method


-- 
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/20180722/f6c41322/attachment.sig>

From iavor.diatchki at gmail.com  Tue Jul 24 16:23:28 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 24 Jul 2018 19:23:28 +0300
Subject: [ghc-steering-committee] Discussion on "Allow ScopedTypeVariables
	to refer to types" (#128)
Message-ID: <CAGK9nurWovhLheA27xvbiMQH8qem7aAQbKXz_MNHx5m8+5W9vQ@mail.gmail.com>

Hello,

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

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

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

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

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

Thoughts?

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

From simonpj at microsoft.com  Tue Jul 24 16:25:39 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 24 Jul 2018 16:25:39 +0000
Subject: [ghc-steering-committee] Discussion on "Allow
	ScopedTypeVariables	to refer to types" (#128)
In-Reply-To: <CAGK9nurWovhLheA27xvbiMQH8qem7aAQbKXz_MNHx5m8+5W9vQ@mail.gmail.com>
References: <CAGK9nurWovhLheA27xvbiMQH8qem7aAQbKXz_MNHx5m8+5W9vQ@mail.gmail.com>
Message-ID: <AM0PR83MB03084861D2B022C54106D6F2AD550@AM0PR83MB0308.EURPRD83.prod.outlook.com>

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

Simon

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

Hello,

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

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

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

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

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

Thoughts?

-Iavor









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

From rae at cs.brynmawr.edu  Tue Jul 24 19:01:31 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 24 Jul 2018 15:01:31 -0400
Subject: [ghc-steering-committee] Discussion on "Allow
	ScopedTypeVariables	to refer to types" (#128)
In-Reply-To: <AM0PR83MB03084861D2B022C54106D6F2AD550@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <CAGK9nurWovhLheA27xvbiMQH8qem7aAQbKXz_MNHx5m8+5W9vQ@mail.gmail.com>
 <AM0PR83MB03084861D2B022C54106D6F2AD550@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <BF2320F8-4FF9-4A62-B838-99450DB5E529@cs.brynmawr.edu>

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

> On Jul 24, 2018, at 12:25 PM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> I originally thought that it’d be confusing for ‘a’ to mean ‘Bool’; but that was before GADTs!  Now that argument is much less strong, and I’m in favour of this proposal.
> 
> Simon
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
> Sent: 24 July 2018 17:23
> To: ghc-steering-committee at haskell.org
> Subject: [ghc-steering-committee] Discussion on "Allow ScopedTypeVariables to refer to types" (#128)
>  
> Hello,
> 
>  
> 
> let's get the discussion going on proposal #128.
> 
>  
> 
> Summary:  this proposal generalizes the behavior of type variables in patterns, specifically the variables that do not refer to an explicitly quantified type parameter.   The idea is that such type variables simply introduce a name for their matching type, without placing any restriction on the type.   For example, consider the following definition.
> 
>  
> 
> f (x : [a]) (y : a) = and x
> 
>  
> 
> This would be accepted and it would have type `[Bool] -> Bool -> Bool`.  This proposal is about the meaning of the type signature on `x` which states that it must be a list of something, and `a` will be a name for the type of its elements.   In this case, it happens that `a` is actually just an alias for `Bool`. 
> 
>  
> 
> I am strongly in favor of this proposal.   As I mentioned on the github discussion, I thought that the feature already worked as in this proposal, and was quite surprised to find out that currently, GHC has restrictions on what `a` could be, and it also complains about "multiple definitions for `a`" in the above example).
> 
>  
> 
> Thoughts?
> 
>  
> 
> -Iavor
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee 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/20180724/9ef00d03/attachment-0001.html>

From chak at justtesting.org  Tue Jul 24 19:28:15 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 24 Jul 2018 21:28:15 +0200
Subject: [ghc-steering-committee] Discussion on
	"Allow	ScopedTypeVariables	to refer to types" (#128)
In-Reply-To: <BF2320F8-4FF9-4A62-B838-99450DB5E529@cs.brynmawr.edu>
References: <CAGK9nurWovhLheA27xvbiMQH8qem7aAQbKXz_MNHx5m8+5W9vQ@mail.gmail.com>
 <AM0PR83MB03084861D2B022C54106D6F2AD550@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <BF2320F8-4FF9-4A62-B838-99450DB5E529@cs.brynmawr.edu>
Message-ID: <2F936BF6-4218-4816-A085-DBCF35586E69@justtesting.org>

Count me in, too.

Manuel

> Am 24.07.2018 um 21:01 schrieb Richard Eisenberg <rae at cs.brynmawr.edu>:
> 
> Unsurprisingly, I'm in support. The lack of this ability has forced `singletons` to go through hoops to bind type variables in certain situations.
> 
>> On Jul 24, 2018, at 12:25 PM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
>> 
>> I originally thought that it’d be confusing for ‘a’ to mean ‘Bool’; but that was before GADTs!  Now that argument is much less strong, and I’m in favour of this proposal.
>> 
>> Simon
>> 
>> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Iavor Diatchki
>> Sent: 24 July 2018 17:23
>> To: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> Subject: [ghc-steering-committee] Discussion on "Allow ScopedTypeVariables to refer to types" (#128)
>> 
>> Hello,
>> 
>> 
>> 
>> let's get the discussion going on proposal #128.
>> 
>> 
>> 
>> Summary:  this proposal generalizes the behavior of type variables in patterns, specifically the variables that do not refer to an explicitly quantified type parameter.   The idea is that such type variables simply introduce a name for their matching type, without placing any restriction on the type.   For example, consider the following definition.
>> 
>> 
>> 
>> f (x : [a]) (y : a) = and x
>> 
>> 
>> 
>> This would be accepted and it would have type `[Bool] -> Bool -> Bool`.  This proposal is about the meaning of the type signature on `x` which states that it must be a list of something, and `a` will be a name for the type of its elements.   In this case, it happens that `a` is actually just an alias for `Bool`.
>> 
>> 
>> 
>> I am strongly in favor of this proposal.   As I mentioned on the github discussion, I thought that the feature already worked as in this proposal, and was quite surprised to find out that currently, GHC has restrictions on what `a` could be, and it also complains about "multiple definitions for `a`" in the above example).
>> 
>> 
>> 
>> Thoughts?
>> 
>> 
>> 
>> -Iavor
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee 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/20180724/0e5e90b6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180724/0e5e90b6/attachment.sig>

From iavor.diatchki at gmail.com  Thu Jul 26 08:08:57 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 26 Jul 2018 11:08:57 +0300
Subject: [ghc-steering-committee] Discussion about "Type Application in
	Patterns" (#126)
Message-ID: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>

Hello,

let's also start the discussion on feature request 126.   The idea here is
that we allow the @ notation for explicit type applications to also be used
on constructors in patterns.  Using @ with a constructor in a pattern has
the same meaning as it does it an expression:  the provided type is used to
instantiate the corresponding type parameter of the constructor.   If the
type contains variables, those are treated in the same way as in #128,
where "unbound" variables name the matching types.   Here are some examples:

    f1 (Just @Int x) = x    -- This has type `Maybe Int -> Int`

    f2 (Just @[a] x) = x == "c"   -- `a` is an alias for `Char`

    f3 (SomeException @e ex) = ...  -- `e` is a name for the existentially
hidden exception type

Overall I think that is a simple and natural extension to the way @ already
works, and I propose that we accept it.

Thoughts?

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

From simonpj at microsoft.com  Thu Jul 26 10:17:55 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 26 Jul 2018 10:17:55 +0000
Subject: [ghc-steering-committee] Discussion about "Type Application
	in	Patterns" (#126)
In-Reply-To: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
Message-ID: <AM0PR83MB0308247F84ADA89BEE33F5DDAD2B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

I’m a strong supporter.  I think the proposal itself (which will have longevity) could be improved significantly, and have commented to that effect.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 26 July 2018 09:09
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Discussion about "Type Application in Patterns" (#126)

Hello,

let's also start the discussion on feature request 126.   The idea here is that we allow the @ notation for explicit type applications to also be used on constructors in patterns.  Using @ with a constructor in a pattern has the same meaning as it does it an expression:  the provided type is used to instantiate the corresponding type parameter of the constructor.   If the type contains variables, those are treated in the same way as in #128, where "unbound" variables name the matching types.   Here are some examples:

    f1 (Just @Int x) = x    -- This has type `Maybe Int -> Int`

    f2 (Just @[a] x) = x == "c"   -- `a` is an alias for `Char`

    f3 (SomeException @e ex) = ...  -- `e` is a name for the existentially hidden exception type

Overall I think that is a simple and natural extension to the way @ already works, and I propose that we accept it.

Thoughts?

-Iavor


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

From rae at cs.brynmawr.edu  Thu Jul 26 14:48:40 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 26 Jul 2018 10:48:40 -0400
Subject: [ghc-steering-committee] Discussion about "Type Application
	in	Patterns" (#126)
In-Reply-To: <AM0PR83MB0308247F84ADA89BEE33F5DDAD2B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <AM0PR83MB0308247F84ADA89BEE33F5DDAD2B0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CBCB8CD4-68F1-4BAC-966B-18A0881BCAE5@cs.brynmawr.edu>

As a co-author of the paper that came from this: yes, please! :)

> On Jul 26, 2018, at 6:17 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> I’m a strong supporter.  I think the proposal itself (which will have longevity) could be improved significantly, and have commented to that effect.
>  
> Simon
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
> Sent: 26 July 2018 09:09
> To: ghc-steering-committee at haskell.org
> Subject: [ghc-steering-committee] Discussion about "Type Application in Patterns" (#126)
>  
> Hello,
> 
>  
> 
> let's also start the discussion on feature request 126.   The idea here is that we allow the @ notation for explicit type applications to also be used on constructors in patterns.  Using @ with a constructor in a pattern has the same meaning as it does it an expression:  the provided type is used to instantiate the corresponding type parameter of the constructor.   If the type contains variables, those are treated in the same way as in #128, where "unbound" variables name the matching types.   Here are some examples:
> 
>  
> 
>     f1 (Just @Int x) = x    -- This has type `Maybe Int -> Int`
> 
>  
> 
>     f2 (Just @[a] x) = x == "c"   -- `a` is an alias for `Char`
> 
>  
> 
>     f3 (SomeException @e ex) = ...  -- `e` is a name for the existentially hidden exception type
> 
>  
> 
> Overall I think that is a simple and natural extension to the way @ already works, and I propose that we accept it.
> 
>  
> 
> Thoughts?
> 
>  
> 
> -Iavor
> 
>  
> 
>  
> 
> _______________________________________________
> 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/20180726/dc5dca3b/attachment.html>