From mail at joachim-breitner.de  Wed Aug  1 23:57:38 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 01 Aug 2018 19:57:38 -0400
Subject: [ghc-steering-committee] Welcome Eric and Vitaly
Message-ID: <402cbe10d059f9200f2ae2cfd19bfcb64c1daf82.camel@joachim-breitner.de>

Dear Committee, Eric and Vitaly,

I am happy to announce that votes were received, tallied, and we have
now not just one, but two new members on the committee! Welcome Eric
Seidel and Vitaly Brailevsky.

Eric and Vitaly will take the seats of Ryan Newton and Roman
Leschinskiy. Ryan leaves immediately, while Roman will wrap up his
shepherding duties. We would like to thank Ryan and Roman for their
service on the committee.

@Eric, Vitaly: Please subscribe to the ghc-steering-committee mailing
list at
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
if you have not done so yet, and read through the process outlined at
https://github.com/ghc-proposals/ghc-proposals

I will reassign Ryan’s proposals for shepherding in a separate mail
when I get to it.


I’d also like to thank the other 3 candidates. We were very happy with
all of them, and encourage you to try again next round!

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/20180801/62d5779f/attachment.sig>

From chak at justtesting.org  Thu Aug  2 07:10:05 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Thu, 2 Aug 2018 09:10:05 +0200
Subject: [ghc-steering-committee] Welcome Eric and Vitaly
In-Reply-To: <402cbe10d059f9200f2ae2cfd19bfcb64c1daf82.camel@joachim-breitner.de>
References: <402cbe10d059f9200f2ae2cfd19bfcb64c1daf82.camel@joachim-breitner.de>
Message-ID: <7FD0C452-47D3-417B-BE73-D9374502DD91@justtesting.org>

Congratulations Eric & Vitaly!

Manuel

> Am 02.08.2018 um 01:57 schrieb Joachim Breitner <mail at joachim-breitner.de>:
> 
> Signierter PGP-Teil
> Dear Committee, Eric and Vitaly,
> 
> I am happy to announce that votes were received, tallied, and we have
> now not just one, but two new members on the committee! Welcome Eric
> Seidel and Vitaly Brailevsky.
> 
> Eric and Vitaly will take the seats of Ryan Newton and Roman
> Leschinskiy. Ryan leaves immediately, while Roman will wrap up his
> shepherding duties. We would like to thank Ryan and Roman for their
> service on the committee.
> 
> @Eric, Vitaly: Please subscribe to the ghc-steering-committee mailing
> list at
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> if you have not done so yet, and read through the process outlined at
> https://github.com/ghc-proposals/ghc-proposals
> 
> I will reassign Ryan’s proposals for shepherding in a separate mail
> when I get to it.
> 
> 
> I’d also like to thank the other 3 candidates. We were very happy with
> all of them, and encourage you to try again next round!
> 
> 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: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180802/988c128e/attachment.sig>

From rae at cs.brynmawr.edu  Thu Aug  2 22:41:33 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 2 Aug 2018 18:41:33 -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: <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>

Conversation seems to have died down on this trail, both on GitHub and here in committee. As the shepherd, it's my job to kick us back into action.

After much conversation on GitHub, there are still a few dangling loose ends to this proposal:

- The proposal defined *consume exactly once*, but I don't that definition is fully correct and it's not general enough. For example, it doesn't treat abstract types or unboxed ones. Simon has suggested that it's meant purely for intuition (for which it works well) but is not meant to be a technical specification. The other proposal authors seem to disagree with this, but I'm yet to be satisfied by an attempt at defining this.

- The proposal says nothing on the subject of type inference. This is understandable, because it's really hard to know what will work best. However, there has not yet been a commitment that type inference will be backward-compatible. The authors want the presence/absence of -XLinearTypes not to affect type inference, and they also want sometimes to infer linear types. I think these, together, imply that the proposal isn't fully backward compatible. See https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-406723478 <https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-406723478>

- The proposal mentions the idea of unification of multiplicities up to semiring equalities, but then the authors claim that such a procedure is undecidable. It's unclear where this stands.

- There is no design that will stop Haskell learners from seeing linear types in error messages, though it appears they won't appear with :type.

- Simon M has pushed on the motivations of the proposal, trying to understand better exactly what problems this proposal solves. I have not followed this sub-thread terribly closely, and will take advantage of the fact that Simon is on this committee and can speak for himself on these issues.

Despite these dangling pieces, I do think they all can be resolved. (Except perhaps the motivation piece if it's problematic enough.) I thus recommend that we officially encourage this proposal on the road toward acceptance. This recommendation is based on the excitement in the community around linear types and the high degree of effort and commitment the authors have shown.

If you disagree with this recommendation, please speak up. As usual, I will take silence as agreement and make an official pronouncement to the authors in due course.

Thanks,
Richard

> On Jul 8, 2018, at 11:41 PM, 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 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

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

From mail at joachim-breitner.de  Sat Aug  4 15:21:41 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Aug 2018 11:21:41 -0400
Subject: [ghc-steering-committee] Discussion on
	"Allow	ScopedTypeVariables	to refer to types" (#128)
In-Reply-To: <2F936BF6-4218-4816-A085-DBCF35586E69@justtesting.org>
References: <CAGK9nurWovhLheA27xvbiMQH8qem7aAQbKXz_MNHx5m8+5W9vQ@mail.gmail.com>
 <AM0PR83MB03084861D2B022C54106D6F2AD550@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <BF2320F8-4FF9-4A62-B838-99450DB5E529@cs.brynmawr.edu>
 <2F936BF6-4218-4816-A085-DBCF35586E69@justtesting.org>
Message-ID: <7ef5b82200d1d89fc111b105fd5f8e48014786f9.camel@joachim-breitner.de>

Hi,

I hope you don’t mind me doing this despite me being conflicted, but I
observe consensus, and mark this as accepted.

Cheers,
Joachim

Am Dienstag, den 24.07.2018, 21:28 +0200 schrieb Manuel M T
Chakravarty:
> Count me in, too.
> 
> Manuel
> 
> > Am 24.07.2018 um 21:01 schrieb Richard Eisenberg <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> 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
> > 
> > _______________________________________________
> > 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/20180804/375f5785/attachment.sig>

From mail at joachim-breitner.de  Sat Aug  4 15:27:25 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Aug 2018 11:27:25 -0400
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: <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>

Hi,

can we have an additional nod by someone who is not an author of the
corresponding paper?

Also, I updated the proposal to answer the disambiguation with as-
patterns:
https://github.com/ghc-proposals/ghc-proposals/pull/126/commits/12d64105b0979c674502c3768118b424d09a572b
And I would like a second pair of eyes there, as this choice blocks us
from in the future allowing patterns on both sides on @, i.e. something
like

   Just (_ :_) @ (fun -> True) @ x

because 

   Nothing @ a

would be ambiguous.

Cheers,
Joachim

Am Donnerstag, den 26.07.2018, 11:08 +0300 schrieb Iavor Diatchki:
> 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
-- 
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/20180804/fd61c67c/attachment.sig>

From mail at joachim-breitner.de  Sat Aug  4 15:28:31 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Aug 2018 11:28:31 -0400
Subject: [ghc-steering-committee] Remove the * kind syntax (#143);
 Recommendation: accept
In-Reply-To: <87in5en7j3.fsf@smart-cactus.org>
References: <87muuto04z.fsf@smart-cactus.org>
 <98e1333abc25a74fb052d8cd1052c5fcb520c91a.camel@joachim-breitner.de>
 <87in5en7j3.fsf@smart-cactus.org>
Message-ID: <31a3b402cd460f064c2da0d8a8f1047666560b73.camel@joachim-breitner.de>

Hi,

Am Montag, den 16.07.2018, 18:24 -0400 schrieb Ben Gamari:
> 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.

Great, no more complains received, hence accepted (with this slight
wording provision).

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/20180804/7923c22e/attachment.sig>

From mail at joachim-breitner.de  Sat Aug  4 15:35:09 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Aug 2018 11:35:09 -0400
Subject: [ghc-steering-committee] Bundling patterns with type synonyms
 (#28)
In-Reply-To: <61FD037C-4A8F-45F2-A0E1-9010380F8029@cs.brynmawr.edu>
References: <CADnndOrXXr1RDKJQQQT2S3a2Nvvph3oMd40dkOMUqFLtzEiL=Q@mail.gmail.com>
 <a8b2e195fc36020ecbae89022faf370fea8144a5.camel@joachim-breitner.de>
 <61FD037C-4A8F-45F2-A0E1-9010380F8029@cs.brynmawr.edu>
Message-ID: <08573db359ccbefa07080c28884667d56bde207d.camel@joachim-breitner.de>

Hi,

we have disagreement here. Chris, would you steer us towards consensus?

Cheers,
Joachim

Am Samstag, den 23.06.2018, 23:19 -0400 schrieb Richard Eisenberg:
> Agreed. Beyond my posted technical reservations, I believe that a better solution is out there.
> 
> Richard
> 
> > On Jun 23, 2018, at 1:00 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Hi,
> > 
> > Am Mittwoch, den 13.06.2018, 18:18 -0500 schrieb Christopher Allen:
> > > Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski
> > > 
> > > https://github.com/ghc-proposals/ghc-proposals/pull/28
> > > 
> > > 
> > > I think we should accept this proposal. There are a couple of
> > > open questions, ambiguities, and potential downsides but the overall
> > > complexity of the proposal doesn't cause me great concern.
> > 
> > I agree with Simon that might not take the language in the direction we
> > want to take it.
> > 
> > In fact, if we had PatternSynonyms and ExplicitNamespaces back when
> > Haskell was first specified, we might not have the T(K) syntax at all,
> > and just a flat, explicit list of names, possibly requiring explicit
> > namespace qualifier to disambiguate? Things like deprecating exports
> > would have been easier then…
> > 
> > So while I follow the motivation of the proposal, and I don’t have
> > concrete other solution to offer, I am inclined to reject it: The
> > problem it is solving does not seem to be too urgent, and my gut
> > feeling says that there might be something better down the road.
> > 
> > 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/20180804/1cae8a9a/attachment.sig>

From mail at joachim-breitner.de  Sat Aug  4 15:37:03 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Aug 2018 11:37:03 -0400
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <CAGK9nurCsjbM40uPPaTC2jNEcw5QX7V3RA_vk9xWRxQ3-aVxWg@mail.gmail.com>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
 <b67d95b5307e5219b02657247ab3583bbbf83416.camel@joachim-breitner.de>
 <CAGK9nurCsjbM40uPPaTC2jNEcw5QX7V3RA_vk9xWRxQ3-aVxWg@mail.gmail.com>
Message-ID: <59856357feb626f014c8e70f37c42a99eb57fdf9.camel@joachim-breitner.de>

Hi,

Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:
> Well, I think it is a bad idea.  Obviously I don't think it has a
> huge impact on the language, but I think it encourages poor style,
> for very questionable befits.  This is quite subjective, of course,
> but I think that this choice is at odds with Haskell's elegant
> surface syntax.  We don't allow repeated punctuation in written
> prose,,,, why would we want in our programs?,,,

looks like there is some discussion needed here…

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/20180804/7d68819f/attachment.sig>

From mail at joachim-breitner.de  Sat Aug  4 15:39:45 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Aug 2018 11:39:45 -0400
Subject: [ghc-steering-committee] Please Review: Define Kinds Without
 Promotion (#106), New Shepherd: Eric
Message-ID: <a8c00945f7c3e090e7d83a65142c2578d7c1dc7d.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Define Kinds Without Promotion, by Iavor, was shepherded by Ryan, and
needs to be reassigned
https://github.com/ghc-proposals/ghc-proposals/pull/106

I propose Eric Seidel as the shepherd.

Eric, 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/20180804/c0673c7e/attachment-0001.sig>

From mail at joachim-breitner.de  Sat Aug  4 15:41:59 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Aug 2018 11:41:59 -0400
Subject: [ghc-steering-committee] Please Review: Lazy unboxed tuples (#35),
	New Shepherd: Vitaly
Message-ID: <3d6e5f82aa3b6841345a770571f03a408c71b93b.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Lazy unboxed tuples, by Richard, was shepherded by Ryan, and
needs to be reassigned
https://github.com/ghc-proposals/ghc-proposals/pull/35

I propose Vitaly Brailevsky as the shepherd.

Vitaly, 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/20180804/013c032c/attachment.sig>

From mail at joachim-breitner.de  Sat Aug  4 15:53:59 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Aug 2018 11:53:59 -0400
Subject: [ghc-steering-committee] Status
Message-ID: <f0538fa83352666eaf6ebd0a4e065765197e1da6.camel@joachim-breitner.de>

Hi committee,

with the new nominations out of the way, time to stop navel gazing and
doing some work!

Since the last status update, we

 * Got two new members. Yay and welcome!

 * were asked to review these proposals:
   #149 Replace atomicModifyMutVar# (Shepherd: Simon M)
   #143 Remove * syntax (Shepherd: Ben)
   #128 Allow ScopedTypeVariables refer to types (Shepherd: Iavor)
   #126 Type Applications in Patterns (Shepherd: Iavor)

 * two reviews were reassigned:
   #106 Define Kinds Without Promotion (New shepherd: Eric)
   #35  Lazy unboxed tuples (New shepherd: Vitaly)

 * got a recommendation from shepherds about:
   #112 Remove TypeOperators => NoStarIsType "migration" (rec: accept)
   #149 Replace atomicModifyMutVar# (rec: accept)
   #111 Linear Types (rec: acceptish)
   #143 Remove * syntax (rec: accept)
   #128 Allow ScopedTypeVariables refer to types (rec: accept)
   #126 Type Applications in Patterns (rec: accept)


 * decided about the following proposals
   #99  forall {k} (accept)
   #112 Remove TypeOperators => NoStarIsType "migration" (accept)
   #149 Replace atomicModifyMutVar# (accept)
   #134 Deprecating Exports (accept)
   #128 Allow ScopedTypeVariables refer to types (accept)
   #143 Remove * syntax (accept)

We currently have to act on the following 11 proposals, which is
two less than last round. Lets further get the backlog down!

Type applications in patterns
https://github.com/ghc-proposals/ghc-proposals/pull/126
Shepherd: Iavor
Status: Overall positive response, acceptance likely

Type annotated quoters
https://github.com/ghc-proposals/ghc-proposals/pull/125
Shepherd: Manuel
Status: Still waiting for recommendation.

Provenance-Qualified Package Imports
https://github.com/ghc-proposals/ghc-proposals/pull/115
Shepherd: Ben
Status: Still waiting for recommendation. This is pretty old!

Linear types
https://github.com/ghc-proposals/ghc-proposals/pull/111
Shepherd: Richard
Status: acceptance-ish(?)

Define Kinds Without Promotion
https://github.com/ghc-proposals/ghc-proposals/pull/106
Shepherd: Eric
Status: Reassigned to Eric, waiting for recommendation.

ExtraCommas
https://github.com/ghc-proposals/ghc-proposals/pull/87
Shepherd: Chris
Recommendation: accept
Status: Ongoing discussion, met with some reservation.

Visible dependent quantification (TL;DR: forall k -> k -> *)
https://github.com/ghc-proposals/ghc-proposals/pull/81
Shepherd: Roman Leshchinskiy
Status: Discussion needs to happen

Top-level kinds signatures
https://github.com/ghc-proposals/ghc-proposals/pull/54
Shepherd: Roman Leshchinskiy
Status: Waiting for recommendation.

Or-Patterns
https://github.com/ghc-proposals/ghc-proposals/pull/43
Shepherd: Manuel
Recommendation: accept
Status: Round 2 discussion ebbed down

Lazy unboxed tuples
https://github.com/ghc-proposals/ghc-proposals/pull/35
Shepherd: Vitaly
Status: Reassigned to Vitaly, waiting for recommendation.

Bundling patterns with synonyms
https://github.com/ghc-proposals/ghc-proposals/pull/28
Shepherd: Chris
Recommendation: accept
Status: Ongoing discussion, met with some resistance.


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/20180804/32378116/attachment.sig>

From bravit111 at gmail.com  Sat Aug  4 16:01:15 2018
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Sat, 4 Aug 2018 19:01:15 +0300
Subject: [ghc-steering-committee] Please Review: Lazy unboxed tuples
 (#35), New Shepherd: Vitaly
In-Reply-To: <3d6e5f82aa3b6841345a770571f03a408c71b93b.camel@joachim-breitner.de>
References: <3d6e5f82aa3b6841345a770571f03a408c71b93b.camel@joachim-breitner.de>
Message-ID: <CALpVSmNviw6jVa4kBS7HtMnptPE9muNgmUkhJQN+h1sOq6X+ag@mail.gmail.com>

Thank you, Joachim! I'll do that.

By the way, there is 'g' in my surname: Bragilevsky.

Regards,
Vitaly

On Sat, Aug 4, 2018 at 6:42 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Lazy unboxed tuples, by Richard, was shepherded by Ryan, and
> needs to be reassigned
> https://github.com/ghc-proposals/ghc-proposals/pull/35
>
> I propose Vitaly Brailevsky as the shepherd.
>
> Vitaly, 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/20180804/4e4d376b/attachment.html>

From cma at bitemyapp.com  Sat Aug  4 18:16:00 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Sat, 4 Aug 2018 13:16:00 -0500
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
Message-ID: <CADnndOoU23SAzqS8EQ4FgXdSE=EHrnnJ56XXwmeVf_eETN-jgA@mail.gmail.com>

Could someone give me a motivating example for what this enables?

If there is such in the paper, a link to the paper is fine.

On Sat, Aug 4, 2018 at 10:27 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> can we have an additional nod by someone who is not an author of the
> corresponding paper?
>
> Also, I updated the proposal to answer the disambiguation with as-
> patterns:
> https://github.com/ghc-proposals/ghc-proposals/pull/126/commits/12d64105b0979c674502c3768118b424d09a572b
> And I would like a second pair of eyes there, as this choice blocks us
> from in the future allowing patterns on both sides on @, i.e. something
> like
>
>    Just (_ :_) @ (fun -> True) @ x
>
> because
>
>    Nothing @ a
>
> would be ambiguous.
>
> Cheers,
> Joachim
>
> Am Donnerstag, den 26.07.2018, 11:08 +0300 schrieb Iavor Diatchki:
>> 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
> --
> 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
>



-- 
Chris Allen
Currently working on http://haskellbook.com

From cma at bitemyapp.com  Sat Aug  4 18:27:33 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Sat, 4 Aug 2018 13:27:33 -0500
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <59856357feb626f014c8e70f37c42a99eb57fdf9.camel@joachim-breitner.de>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
 <b67d95b5307e5219b02657247ab3583bbbf83416.camel@joachim-breitner.de>
 <CAGK9nurCsjbM40uPPaTC2jNEcw5QX7V3RA_vk9xWRxQ3-aVxWg@mail.gmail.com>
 <59856357feb626f014c8e70f37c42a99eb57fdf9.camel@joachim-breitner.de>
Message-ID: <CADnndOqauBDqsnwXgrX1iGgE6NPD1Qbpfrwm-vHw8RE8ehVsOA@mail.gmail.com>

I've been using Rust which has terminal commas in the syntactic
enumerations and it's, frankly, lovely. Less editing and easier
copy/paste or use of macros when I am munging code. If it seems sloppy
to you, it's probably because you aren't accustomed to it.

We have to remember that we work with code and not sentential English.
In my view, mechanical ease should take priority over apparent
naturalness. There have been many people who've objected that Haskell
function application syntax is unnatural because they are accustomed
to C-style f(arg, arg1) syntax.

Cf. https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multiline-statements-d034c98e36f8

I'd like to see this get in unless there are real technical issues
blocking it. I don't think it's our place to block an optional
extension on aesthetic grounds unless it was beyond the pale of what
the language is or does. I don't see how an extension permitting extra
commas would qualify.


On Sat, Aug 4, 2018 at 10:37 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:
>> Well, I think it is a bad idea.  Obviously I don't think it has a
>> huge impact on the language, but I think it encourages poor style,
>> for very questionable befits.  This is quite subjective, of course,
>> but I think that this choice is at odds with Haskell's elegant
>> surface syntax.  We don't allow repeated punctuation in written
>> prose,,,, why would we want in our programs?,,,
>
> looks like there is some discussion needed here…
>
> 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
>



-- 
Chris Allen
Currently working on http://haskellbook.com

From cma at bitemyapp.com  Sat Aug  4 18:30:45 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Sat, 4 Aug 2018 13:30:45 -0500
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <CADnndOqauBDqsnwXgrX1iGgE6NPD1Qbpfrwm-vHw8RE8ehVsOA@mail.gmail.com>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
 <b67d95b5307e5219b02657247ab3583bbbf83416.camel@joachim-breitner.de>
 <CAGK9nurCsjbM40uPPaTC2jNEcw5QX7V3RA_vk9xWRxQ3-aVxWg@mail.gmail.com>
 <59856357feb626f014c8e70f37c42a99eb57fdf9.camel@joachim-breitner.de>
 <CADnndOqauBDqsnwXgrX1iGgE6NPD1Qbpfrwm-vHw8RE8ehVsOA@mail.gmail.com>
Message-ID: <CADnndOodMwnRvsVUJoTwVnvKPXZTZZXEjYtyFNxtBk09zdKK1w@mail.gmail.com>

Qualifying what I said toward the end, I don't think we should
encourage clutter either. Trailing commas is an ergonomic idea that is
already getting proved out by another language community.

On Sat, Aug 4, 2018 at 1:27 PM, Christopher Allen <cma at bitemyapp.com> wrote:
> I've been using Rust which has terminal commas in the syntactic
> enumerations and it's, frankly, lovely. Less editing and easier
> copy/paste or use of macros when I am munging code. If it seems sloppy
> to you, it's probably because you aren't accustomed to it.
>
> We have to remember that we work with code and not sentential English.
> In my view, mechanical ease should take priority over apparent
> naturalness. There have been many people who've objected that Haskell
> function application syntax is unnatural because they are accustomed
> to C-style f(arg, arg1) syntax.
>
> Cf. https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multiline-statements-d034c98e36f8
>
> I'd like to see this get in unless there are real technical issues
> blocking it. I don't think it's our place to block an optional
> extension on aesthetic grounds unless it was beyond the pale of what
> the language is or does. I don't see how an extension permitting extra
> commas would qualify.
>
>
> On Sat, Aug 4, 2018 at 10:37 AM, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
>> Hi,
>>
>> Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:
>>> Well, I think it is a bad idea.  Obviously I don't think it has a
>>> huge impact on the language, but I think it encourages poor style,
>>> for very questionable befits.  This is quite subjective, of course,
>>> but I think that this choice is at odds with Haskell's elegant
>>> surface syntax.  We don't allow repeated punctuation in written
>>> prose,,,, why would we want in our programs?,,,
>>
>> looks like there is some discussion needed here…
>>
>> 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
>>
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com



-- 
Chris Allen
Currently working on http://haskellbook.com

From mail at joachim-breitner.de  Sat Aug  4 18:33:43 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Aug 2018 14:33:43 -0400
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <CADnndOoU23SAzqS8EQ4FgXdSE=EHrnnJ56XXwmeVf_eETN-jgA@mail.gmail.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <CADnndOoU23SAzqS8EQ4FgXdSE=EHrnnJ56XXwmeVf_eETN-jgA@mail.gmail.com>
Message-ID: <f22550b2886d61f26090ba011c4ba81b97f5dc49.camel@joachim-breitner.de>

Hi,

Am Samstag, den 04.08.2018, 13:16 -0500 schrieb Christopher Allen:
> Could someone give me a motivating example for what this enables?

with “this”, do you refer to type applications in patterns?
The main fundamental motivation is to bind existential type variables.
Currently we often do this using Proxy, but we’d like a more convenient
syntax that mirrors type applications in patterns.


or do you refer to allowing complex patterns on both sides of an as-
pattern? I don’t have an example for this handy, and maybe we actually
never want that, in which case there is no issue.

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/20180804/d21a3ff5/attachment.sig>

From cma at bitemyapp.com  Sat Aug  4 19:04:51 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Sat, 4 Aug 2018 14:04:51 -0500
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <f22550b2886d61f26090ba011c4ba81b97f5dc49.camel@joachim-breitner.de>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <CADnndOoU23SAzqS8EQ4FgXdSE=EHrnnJ56XXwmeVf_eETN-jgA@mail.gmail.com>
 <f22550b2886d61f26090ba011c4ba81b97f5dc49.camel@joachim-breitner.de>
Message-ID: <CADnndOrJuXEPj=FdG3_JsT2AV9UPCzdHxfw=-4Xk3sxU11gq5Q@mail.gmail.com>

Seems reasonable to me. There's been a general push to eliminate cases
for Proxy as well.

On Sat, Aug 4, 2018 at 1:33 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Samstag, den 04.08.2018, 13:16 -0500 schrieb Christopher Allen:
>> Could someone give me a motivating example for what this enables?
>
> with “this”, do you refer to type applications in patterns?
> The main fundamental motivation is to bind existential type variables.
> Currently we often do this using Proxy, but we’d like a more convenient
> syntax that mirrors type applications in patterns.
>
>
> or do you refer to allowing complex patterns on both sides of an as-
> pattern? I don’t have an example for this handy, and maybe we actually
> never want that, in which case there is no issue.
>
> 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
>



-- 
Chris Allen
Currently working on http://haskellbook.com

From iavor.diatchki at gmail.com  Sat Aug  4 20:08:06 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sat, 4 Aug 2018 23:08:06 +0300
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <CADnndOodMwnRvsVUJoTwVnvKPXZTZZXEjYtyFNxtBk09zdKK1w@mail.gmail.com>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
 <b67d95b5307e5219b02657247ab3583bbbf83416.camel@joachim-breitner.de>
 <CAGK9nurCsjbM40uPPaTC2jNEcw5QX7V3RA_vk9xWRxQ3-aVxWg@mail.gmail.com>
 <59856357feb626f014c8e70f37c42a99eb57fdf9.camel@joachim-breitner.de>
 <CADnndOqauBDqsnwXgrX1iGgE6NPD1Qbpfrwm-vHw8RE8ehVsOA@mail.gmail.com>
 <CADnndOodMwnRvsVUJoTwVnvKPXZTZZXEjYtyFNxtBk09zdKK1w@mail.gmail.com>
Message-ID: <CAGK9nup1UkGFA01jaizbY4K_Mo1==EMCBf7fQCsXMTZo-jwuFQ@mail.gmail.com>

I find the "cleaner diffs" or "easier editing" motivations to be very weak,
and I'd rather not have to explain why `[1,2,]` is a list, but `(1,2,)` is
a function.



On Sat, Aug 4, 2018 at 9:31 PM Christopher Allen <cma at bitemyapp.com> wrote:

> Qualifying what I said toward the end, I don't think we should
> encourage clutter either. Trailing commas is an ergonomic idea that is
> already getting proved out by another language community.
>
> On Sat, Aug 4, 2018 at 1:27 PM, Christopher Allen <cma at bitemyapp.com>
> wrote:
> > I've been using Rust which has terminal commas in the syntactic
> > enumerations and it's, frankly, lovely. Less editing and easier
> > copy/paste or use of macros when I am munging code. If it seems sloppy
> > to you, it's probably because you aren't accustomed to it.
> >
> > We have to remember that we work with code and not sentential English.
> > In my view, mechanical ease should take priority over apparent
> > naturalness. There have been many people who've objected that Haskell
> > function application syntax is unnatural because they are accustomed
> > to C-style f(arg, arg1) syntax.
> >
> > Cf.
> https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multiline-statements-d034c98e36f8
> >
> > I'd like to see this get in unless there are real technical issues
> > blocking it. I don't think it's our place to block an optional
> > extension on aesthetic grounds unless it was beyond the pale of what
> > the language is or does. I don't see how an extension permitting extra
> > commas would qualify.
> >
> >
> > On Sat, Aug 4, 2018 at 10:37 AM, Joachim Breitner
> > <mail at joachim-breitner.de> wrote:
> >> Hi,
> >>
> >> Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:
> >>> Well, I think it is a bad idea.  Obviously I don't think it has a
> >>> huge impact on the language, but I think it encourages poor style,
> >>> for very questionable befits.  This is quite subjective, of course,
> >>> but I think that this choice is at odds with Haskell's elegant
> >>> surface syntax.  We don't allow repeated punctuation in written
> >>> prose,,,, why would we want in our programs?,,,
> >>
> >> looks like there is some discussion needed here…
> >>
> >> 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
> >>
> >
> >
> >
> > --
> > Chris Allen
> > Currently working on http://haskellbook.com
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
> _______________________________________________
> 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/20180804/aa7bb6be/attachment.html>

From eric at seidel.io  Sat Aug  4 20:18:48 2018
From: eric at seidel.io (Eric Seidel)
Date: Sat, 04 Aug 2018 16:18:48 -0400
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <CAGK9nup1UkGFA01jaizbY4K_Mo1==EMCBf7fQCsXMTZo-jwuFQ@mail.gmail.com>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
 <b67d95b5307e5219b02657247ab3583bbbf83416.camel@joachim-breitner.de>
 <CAGK9nurCsjbM40uPPaTC2jNEcw5QX7V3RA_vk9xWRxQ3-aVxWg@mail.gmail.com>
 <59856357feb626f014c8e70f37c42a99eb57fdf9.camel@joachim-breitner.de>
 <CADnndOqauBDqsnwXgrX1iGgE6NPD1Qbpfrwm-vHw8RE8ehVsOA@mail.gmail.com>
 <CADnndOodMwnRvsVUJoTwVnvKPXZTZZXEjYtyFNxtBk09zdKK1w@mail.gmail.com>
 <CAGK9nup1UkGFA01jaizbY4K_Mo1==EMCBf7fQCsXMTZo-jwuFQ@mail.gmail.com>
Message-ID: <1533413928.2067547.1463535320.709D89A3@webmail.messagingengine.com>

I agree with Chris, the ergonomic benefits to allowing a leading/trailing comma would be substantial. It would be nice if we had smart, structure-aware editors that made it easy to swap around sequence elements, but they never really caught on. Most people still use line-oriented editors, so I think we should support the more line-oriented editing flow that extra commas enable.

It's unfortunate that the extension would conflict with TupleSections, but I don't think that's sufficient reason to block it.

I'm in favor of accepting the proposal.

On Sat, Aug 4, 2018, at 16:08, Iavor Diatchki wrote:
> I find the "cleaner diffs" or "easier editing" motivations to be very weak,
> and I'd rather not have to explain why `[1,2,]` is a list, but `(1,2,)` is
> a function.
> 
> 
> 
> On Sat, Aug 4, 2018 at 9:31 PM Christopher Allen <cma at bitemyapp.com> wrote:
> 
> > Qualifying what I said toward the end, I don't think we should
> > encourage clutter either. Trailing commas is an ergonomic idea that is
> > already getting proved out by another language community.
> >
> > On Sat, Aug 4, 2018 at 1:27 PM, Christopher Allen <cma at bitemyapp.com>
> > wrote:
> > > I've been using Rust which has terminal commas in the syntactic
> > > enumerations and it's, frankly, lovely. Less editing and easier
> > > copy/paste or use of macros when I am munging code. If it seems sloppy
> > > to you, it's probably because you aren't accustomed to it.
> > >
> > > We have to remember that we work with code and not sentential English.
> > > In my view, mechanical ease should take priority over apparent
> > > naturalness. There have been many people who've objected that Haskell
> > > function application syntax is unnatural because they are accustomed
> > > to C-style f(arg, arg1) syntax.
> > >
> > > Cf.
> > https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multiline-statements-d034c98e36f8
> > >
> > > I'd like to see this get in unless there are real technical issues
> > > blocking it. I don't think it's our place to block an optional
> > > extension on aesthetic grounds unless it was beyond the pale of what
> > > the language is or does. I don't see how an extension permitting extra
> > > commas would qualify.
> > >
> > >
> > > On Sat, Aug 4, 2018 at 10:37 AM, Joachim Breitner
> > > <mail at joachim-breitner.de> wrote:
> > >> Hi,
> > >>
> > >> Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:
> > >>> Well, I think it is a bad idea.  Obviously I don't think it has a
> > >>> huge impact on the language, but I think it encourages poor style,
> > >>> for very questionable befits.  This is quite subjective, of course,
> > >>> but I think that this choice is at odds with Haskell's elegant
> > >>> surface syntax.  We don't allow repeated punctuation in written
> > >>> prose,,,, why would we want in our programs?,,,
> > >>
> > >> looks like there is some discussion needed here…
> > >>
> > >> 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
> > >>
> > >
> > >
> > >
> > > --
> > > Chris Allen
> > > Currently working on http://haskellbook.com
> >
> >
> >
> > --
> > Chris Allen
> > Currently working on http://haskellbook.com
> > _______________________________________________
> > 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 eric at seidel.io  Sat Aug  4 20:19:30 2018
From: eric at seidel.io (Eric Seidel)
Date: Sat, 04 Aug 2018 16:19:30 -0400
Subject: [ghc-steering-committee] Please Review: Define Kinds Without
 Promotion (#106), New Shepherd: Eric
In-Reply-To: <a8c00945f7c3e090e7d83a65142c2578d7c1dc7d.camel@joachim-breitner.de>
References: <a8c00945f7c3e090e7d83a65142c2578d7c1dc7d.camel@joachim-breitner.de>
Message-ID: <1533413970.2067580.1463538088.6F8477B3@webmail.messagingengine.com>

Sounds good!

On Sat, Aug 4, 2018, at 11:39, Joachim Breitner wrote:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Define Kinds Without Promotion, by Iavor, was shepherded by Ryan, and
> needs to be reassigned
> https://github.com/ghc-proposals/ghc-proposals/pull/106
> 
> I propose Eric Seidel as the shepherd.
> 
> Eric, 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
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

From rae at cs.brynmawr.edu  Sun Aug  5 14:47:31 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 5 Aug 2018 10:47:31 -0400
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <1533413928.2067547.1463535320.709D89A3@webmail.messagingengine.com>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
 <b67d95b5307e5219b02657247ab3583bbbf83416.camel@joachim-breitner.de>
 <CAGK9nurCsjbM40uPPaTC2jNEcw5QX7V3RA_vk9xWRxQ3-aVxWg@mail.gmail.com>
 <59856357feb626f014c8e70f37c42a99eb57fdf9.camel@joachim-breitner.de>
 <CADnndOqauBDqsnwXgrX1iGgE6NPD1Qbpfrwm-vHw8RE8ehVsOA@mail.gmail.com>
 <CADnndOodMwnRvsVUJoTwVnvKPXZTZZXEjYtyFNxtBk09zdKK1w@mail.gmail.com>
 <CAGK9nup1UkGFA01jaizbY4K_Mo1==EMCBf7fQCsXMTZo-jwuFQ@mail.gmail.com>
 <1533413928.2067547.1463535320.709D89A3@webmail.messagingengine.com>
Message-ID: <FDC556AF-6F95-43D7-8DD1-19FE7040DA08@cs.brynmawr.edu>

I'm ambivalent on this one, seeing both sides of the argument. If I had to choose, I would lean toward "accept" based on the generally positive response the idea has seen.

Richard

> On Aug 4, 2018, at 4:18 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> I agree with Chris, the ergonomic benefits to allowing a leading/trailing comma would be substantial. It would be nice if we had smart, structure-aware editors that made it easy to swap around sequence elements, but they never really caught on. Most people still use line-oriented editors, so I think we should support the more line-oriented editing flow that extra commas enable.
> 
> It's unfortunate that the extension would conflict with TupleSections, but I don't think that's sufficient reason to block it.
> 
> I'm in favor of accepting the proposal.
> 
> On Sat, Aug 4, 2018, at 16:08, Iavor Diatchki wrote:
>> I find the "cleaner diffs" or "easier editing" motivations to be very weak,
>> and I'd rather not have to explain why `[1,2,]` is a list, but `(1,2,)` is
>> a function.
>> 
>> 
>> 
>> On Sat, Aug 4, 2018 at 9:31 PM Christopher Allen <cma at bitemyapp.com> wrote:
>> 
>>> Qualifying what I said toward the end, I don't think we should
>>> encourage clutter either. Trailing commas is an ergonomic idea that is
>>> already getting proved out by another language community.
>>> 
>>> On Sat, Aug 4, 2018 at 1:27 PM, Christopher Allen <cma at bitemyapp.com>
>>> wrote:
>>>> I've been using Rust which has terminal commas in the syntactic
>>>> enumerations and it's, frankly, lovely. Less editing and easier
>>>> copy/paste or use of macros when I am munging code. If it seems sloppy
>>>> to you, it's probably because you aren't accustomed to it.
>>>> 
>>>> We have to remember that we work with code and not sentential English.
>>>> In my view, mechanical ease should take priority over apparent
>>>> naturalness. There have been many people who've objected that Haskell
>>>> function application syntax is unnatural because they are accustomed
>>>> to C-style f(arg, arg1) syntax.
>>>> 
>>>> Cf.
>>> https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multiline-statements-d034c98e36f8
>>>> 
>>>> I'd like to see this get in unless there are real technical issues
>>>> blocking it. I don't think it's our place to block an optional
>>>> extension on aesthetic grounds unless it was beyond the pale of what
>>>> the language is or does. I don't see how an extension permitting extra
>>>> commas would qualify.
>>>> 
>>>> 
>>>> On Sat, Aug 4, 2018 at 10:37 AM, Joachim Breitner
>>>> <mail at joachim-breitner.de> wrote:
>>>>> Hi,
>>>>> 
>>>>> Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:
>>>>>> Well, I think it is a bad idea.  Obviously I don't think it has a
>>>>>> huge impact on the language, but I think it encourages poor style,
>>>>>> for very questionable befits.  This is quite subjective, of course,
>>>>>> but I think that this choice is at odds with Haskell's elegant
>>>>>> surface syntax.  We don't allow repeated punctuation in written
>>>>>> prose,,,, why would we want in our programs?,,,
>>>>> 
>>>>> looks like there is some discussion needed here…
>>>>> 
>>>>> 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
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Chris Allen
>>>> Currently working on http://haskellbook.com
>>> 
>>> 
>>> 
>>> --
>>> Chris Allen
>>> Currently working on http://haskellbook.com
>>> _______________________________________________
>>> 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


From mail at joachim-breitner.de  Mon Aug  6 00:36:38 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 05 Aug 2018 20:36:38 -0400
Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept
In-Reply-To: <FDC556AF-6F95-43D7-8DD1-19FE7040DA08@cs.brynmawr.edu>
References: <CADnndOpYDrL-BVn69seXAya0cSwm9N=xqLnsDKHTyoD5MGzAVA@mail.gmail.com>
 <b67d95b5307e5219b02657247ab3583bbbf83416.camel@joachim-breitner.de>
 <CAGK9nurCsjbM40uPPaTC2jNEcw5QX7V3RA_vk9xWRxQ3-aVxWg@mail.gmail.com>
 <59856357feb626f014c8e70f37c42a99eb57fdf9.camel@joachim-breitner.de>
 <CADnndOqauBDqsnwXgrX1iGgE6NPD1Qbpfrwm-vHw8RE8ehVsOA@mail.gmail.com>
 <CADnndOodMwnRvsVUJoTwVnvKPXZTZZXEjYtyFNxtBk09zdKK1w@mail.gmail.com>
 <CAGK9nup1UkGFA01jaizbY4K_Mo1==EMCBf7fQCsXMTZo-jwuFQ@mail.gmail.com>
 <1533413928.2067547.1463535320.709D89A3@webmail.messagingengine.com>
 <FDC556AF-6F95-43D7-8DD1-19FE7040DA08@cs.brynmawr.edu>
Message-ID: <d033348d588346f25105666440c15ba608fa1900.camel@joachim-breitner.de>

Hi,

similar ambivalence here. If it were not for TupleSections, I’d be
clearly in favor. But both TupleSections and ExtraCommas would be
clearly marked in in the header of the file¹, and thus be signposted.

The proposal currently says “There is a potential interaction with
TupleSections”. Why potential? Is it, or is it not?

Also, Simon’s request for an explicit listing of all the BNF changes
has not happened yet. Chris, maybe request that first from the authors
(i.e. return this as “Revision needed”)?

I am not sure if the “let’s do this everywhere, but not with tuples” is
a good approach. Note that TupleSections is still only an extension,
and we _could_ decide that it is better to have uniformity in
ExtraCommas, at the expense of making it simply incompatible with
TupleSections. I am not sure about this, but I’d at least want to
discuss the option.

Although even ignoring TupleSections, extending ExtraCommas to tuples
raises the question of how (,) should parse – is it the pair
constructor, or the unit constructor with an extra comma.

So maybe _that_ incompatibility with Haskell98 is the real reason why
ExtraCommas just cannot work for tuples.

Cheers,
Joachim



Am Sonntag, den 05.08.2018, 10:47 -0400 schrieb Richard Eisenberg:
> I'm ambivalent on this one, seeing both sides of the argument. If I had to choose, I would lean toward "accept" based on the generally positive response the idea has seen.
> 
> Richard
> 
> > On Aug 4, 2018, at 4:18 PM, Eric Seidel <eric at seidel.io> wrote:
> > 
> > I agree with Chris, the ergonomic benefits to allowing a leading/trailing comma would be substantial. It would be nice if we had smart, structure-aware editors that made it easy to swap around sequence elements, but they never really caught on. Most people still use line-oriented editors, so I think we should support the more line-oriented editing flow that extra commas enable.
> > 
> > It's unfortunate that the extension would conflict with TupleSections, but I don't think that's sufficient reason to block it.
> > 
> > I'm in favor of accepting the proposal.
> > 
> > On Sat, Aug 4, 2018, at 16:08, Iavor Diatchki wrote:
> > > I find the "cleaner diffs" or "easier editing" motivations to be very weak,
> > > and I'd rather not have to explain why `[1,2,]` is a list, but `(1,2,)` is
> > > a function.
> > > 
> > > 
> > > 
> > > On Sat, Aug 4, 2018 at 9:31 PM Christopher Allen <cma at bitemyapp.com> wrote:
> > > 
> > > > Qualifying what I said toward the end, I don't think we should
> > > > encourage clutter either. Trailing commas is an ergonomic idea that is
> > > > already getting proved out by another language community.
> > > > 
> > > > On Sat, Aug 4, 2018 at 1:27 PM, Christopher Allen <cma at bitemyapp.com>
> > > > wrote:
> > > > > I've been using Rust which has terminal commas in the syntactic
> > > > > enumerations and it's, frankly, lovely. Less editing and easier
> > > > > copy/paste or use of macros when I am munging code. If it seems sloppy
> > > > > to you, it's probably because you aren't accustomed to it.
> > > > > 
> > > > > We have to remember that we work with code and not sentential English.
> > > > > In my view, mechanical ease should take priority over apparent
> > > > > naturalness. There have been many people who've objected that Haskell
> > > > > function application syntax is unnatural because they are accustomed
> > > > > to C-style f(arg, arg1) syntax.
> > > > > 
> > > > > Cf.
> > > > 
> > > > https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multiline-statements-d034c98e36f8
> > > > > 
> > > > > I'd like to see this get in unless there are real technical issues
> > > > > blocking it. I don't think it's our place to block an optional
> > > > > extension on aesthetic grounds unless it was beyond the pale of what
> > > > > the language is or does. I don't see how an extension permitting extra
> > > > > commas would qualify.
> > > > > 
> > > > > 
> > > > > On Sat, Aug 4, 2018 at 10:37 AM, Joachim Breitner
> > > > > <mail at joachim-breitner.de> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Am Samstag, den 02.06.2018, 13:04 -0700 schrieb Iavor Diatchki:
> > > > > > > Well, I think it is a bad idea.  Obviously I don't think it has a
> > > > > > > huge impact on the language, but I think it encourages poor style,
> > > > > > > for very questionable befits.  This is quite subjective, of course,
> > > > > > > but I think that this choice is at odds with Haskell's elegant
> > > > > > > surface syntax.  We don't allow repeated punctuation in written
> > > > > > > prose,,,, why would we want in our programs?,,,
> > > > > > 
> > > > > > looks like there is some discussion needed here…
> > > > > > 
> > > > > > 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
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Chris Allen
> > > > > Currently working on http://haskellbook.com
> > > > 
> > > > 
> > > > 
> > > > --
> > > > Chris Allen
> > > > Currently working on http://haskellbook.com
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > > > 
> > > 
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180805/3e314ceb/attachment.sig>

From iavor.diatchki at gmail.com  Tue Aug  7 05:50:25 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 7 Aug 2018 08:50:25 +0300
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
Message-ID: <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>

Hello,

I am not sure that the amount of effort that went into writing a proposal
should be a deciding factor about if the proposal is accepted.  We don't
want to discourage folks, but also, once things get into GHC they are hard
to get out, so I think caution is warranted.

I find this proposal to be constructed rather poorly.  I read the previous
version, and I also read this one, and I find it to be a rather small
improvement, if at all.  For a relatively complex proposal change, the
proposal had hardly any examples.  To me, it read as a patchwork of
paragraphs, that are an uneasy mix of informal explanations with no
examples, overly formal explanations, potential things one might use this
for (RIO??), and what seem to be answers to questions from the GitHub
discussion, which are just perplexing if you read the proposal before the
discussion.

This makes it quite hard to grasp the main idea.  Having said that I think
I get what is being proposed and I like parts of it.

The main high level concern I have is the overloading of the function space
arrow.  We already have it overloaded in all kinds of ways, and adding one
more dimension without any kind of underlying system seems too much.  I am
not at all convinced that we will be able to "hide" multiplicities when the
extension is not enabled.

Overall, while I like the core ideas, I would prefer a different way of
integrating them into Haskell, one that is more modular, even at the cost
of having to duplicate some code.  My reasoning is that while linearity
might be useful in some cases, most of the time it is not something that
we'd care about much, so we should not add it (at least straight away) to
the core part of the language (functions and data types).

-Iavor


On Fri, Aug 3, 2018, 1:41 AM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:

> Conversation seems to have died down on this trail, both on GitHub and
> here in committee. As the shepherd, it's my job to kick us back into action.
>
> After much conversation on GitHub, there are still a few dangling loose
> ends to this proposal:
>
> - The proposal defined *consume exactly once*, but I don't that definition
> is fully correct and it's not general enough. For example, it doesn't treat
> abstract types or unboxed ones. Simon has suggested that it's meant purely
> for intuition (for which it works well) but is not meant to be a technical
> specification. The other proposal authors seem to disagree with this, but
> I'm yet to be satisfied by an attempt at defining this.
>
> - The proposal says nothing on the subject of type inference. This is
> understandable, because it's really hard to know what will work best.
> However, there has not yet been a commitment that type inference will be
> backward-compatible. The authors want the presence/absence of -XLinearTypes
> not to affect type inference, and they also want sometimes to infer linear
> types. I think these, together, imply that the proposal isn't fully
> backward compatible. See
> https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-406723478
>
> - The proposal mentions the idea of unification of multiplicities up to
> semiring equalities, but then the authors claim that such a procedure is
> undecidable. It's unclear where this stands.
>
> - There is no design that will stop Haskell learners from seeing linear
> types in error messages, though it appears they won't appear with :type.
>
> - Simon M has pushed on the motivations of the proposal, trying to
> understand better exactly what problems this proposal solves. I have not
> followed this sub-thread terribly closely, and will take advantage of the
> fact that Simon is on this committee and can speak for himself on these
> issues.
>
> Despite these dangling pieces, I do think they all can be resolved.
> (Except perhaps the motivation piece if it's problematic enough.) I thus
> recommend that we officially encourage this proposal on the road toward
> acceptance. This recommendation is based on the excitement in the community
> around linear types and the high degree of effort and commitment the
> authors have shown.
>
> If you disagree with this recommendation, please speak up. As usual, I
> will take silence as agreement and make an official pronouncement to the
> authors in due course.
>
> Thanks,
> Richard
>
> On Jul 8, 2018, at 11:41 PM, 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 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/20180807/0c3980e3/attachment.html>

From rleshchinskiy at gmail.com  Thu Aug  9 18:44:00 2018
From: rleshchinskiy at gmail.com (Roman Leshchinskiy)
Date: Thu, 9 Aug 2018 19:44:00 +0100
Subject: [ghc-steering-committee] Proposal: Syntax for visible dependent
 quantification (#81)
In-Reply-To: <52a0e1ee2494f5514ddda0984b31844dcf7b76a2.camel@joachim-breitner.de>
References: <CAADqg9bZktCwGik=4G9DJh0jb5VDPrWdSPE1U4_C4MXZoHmHbw@mail.gmail.com>
 <30B357D6-E03C-4A03-8D6C-F5BF22BF0E13@cs.brynmawr.edu>
 <88AAAB4F-4C45-43EF-B4A4-D095982FCBDF@cs.brynmawr.edu>
 <4704D092-353A-4113-9B2F-482FD3F7D1AF@cs.brynmawr.edu>
 <52a0e1ee2494f5514ddda0984b31844dcf7b76a2.camel@joachim-breitner.de>
Message-ID: <CAADqg9YVMk6PTD71RRc4RXCVK3-vQagE1tHjmBMjnnKM=edXXA@mail.gmail.com>

Sorry for the long delay. Given that the general feedback is positive and
#102 is now available, I recommend that we accept #81.

Thanks,

Roman

On Sat, May 5, 2018 at 10:12 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> indeed, we should make progress here. Roman, with #102 discussed
> (albeit not decided), what is your recommendation about #81?
>
> Cheers,
> Joachim
>
> Am Sonntag, den 15.04.2018, 23:09 -0400 schrieb Richard Eisenberg:
> > Hi committee,
> >
> > I'd like to reboot this discussion, now that #102 has been written,
> debated, and tabled. As a reminder, this proposal is blocking #54, which
> will cure real bugs GHC is plagued by.
> >
> > Thanks!
> > Richard
> >
> > > On Jan 5, 2018, at 8:37 PM, Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
> > >
> > > OK. I've posted proposal #102 (https://github.com/
> goldfirere/ghc-proposals/blob/pi/proposals/0000-pi.rst) which describes
> the full set of quantifiers for Dependent Haskell.
> > >
> > > I continue to think that #81 can stand alone, but those who want a
> larger picture can see #102 for that larger picture.
> > >
> > > Thanks,
> > > Richard
> > >
> > > > On Dec 21, 2017, at 9:15 AM, Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
> > > >
> > > > These are good suggestions. Thanks. While I'm writing all these
> proposals, it's about time I introduce pi proper -- the proposal for pi can
> go further than reserve syntax, because there are already places in the
> language that support real pi-types (the kinds of type families [assuming
> #54 is accepted] and the kinds of datatypes).
> > > >
> > > > I'll put together yet another proposal. :)
> > > >
> > > > Regardless, I don't want to shut down debate on this proposal in
> isolation. In particular, I'd love new syntax suggestions, as I agree that
> the proposed syntax is a little subtle.
> > > >
> > > > Thanks,
> > > > Richard
> > > >
> > > > > On Dec 20, 2017, at 3:35 PM, Roman Leshchinskiy <
> rleshchinskiy at gmail.com> wrote:
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > > The proposal is about adding support for dependent quantification
> to
> > > > > kind signatures:
> > > > >
> > > > > https://github.com/ghc-proposals/ghc-proposals/pull/81
> > > > >
> > > > > Consider the following declaration (example lifted from the
> proposal):
> > > > >
> > > > > data T k (a :: k)
> > > > >
> > > > > GHC accepts this but it can't be given an explicit kind.
> Internally,
> > > > > it is assigned a kind which is rendered as
> > > > >
> > > > > forall k -> k -> *
> > > > >
> > > > > but this isn't accepted in source code. Note that in applications
> of
> > > > > T, k must be specified explicitly (e.g., T Type Int) which is why T
> > > > > does *not* have the kind
> > > > >
> > > > > forall k. k -> *
> > > > >
> > > > > Moreover, k is mentioned later in the kind which is why something
> like
> > > > > Type -> k -> * doesn't work, either.
> > > > >
> > > > > The proposal is to allow forall k -> k -> * and similar kinds to
> > > > > appear in source code.
> > > > >
> > > > > This is actually intended as the first in a series of proposals
> > > > > driving us towards dependent types in Haskell as described in
> > > > > Richard's thesis
> > > > > (https://www.cis.upenn.edu/~sweirich/papers/eisenberg-thesis.pdf).
> > > > > Ultimately, the intention is to have all of the following (cf.
> Chapter
> > > > > 4 of the thesis):
> > > > >
> > > > > forall a. t
> > > > > forall a -> t
> > > > > pi a. t
> > > > > pi a -> t
> > > > >
> > > > > Here, forall and pi express relevance (does it exist at runtime)
> and .
> > > > > and -> express visibility (does it have to be specified
> explicitly).
> > > > >
> > > > > Because of this, my recommendation is to strongly encourage the
> author
> > > > > to submit an extended proposal which reserves (but doesn't specify
> the
> > > > > semantics of) the above syntax wholesale.
> > > > >
> > > > > This would allow us to ensure that various bits of Dependent
> Haskell
> > > > > use consistent syntax and language extensions once implemented. I
> find
> > > > > it quite difficult to discuss just this specific bit of syntax in
> > > > > isolation. Indeed, the public discussion was rather confused
> without
> > > > > an explanation of the roadmap
> > > > > (https://github.com/ghc-proposals/ghc-proposals/pull/
> 81#issuecomment-336892922).
> > > > >
> > > > > Alternatively, we could just agree on the roadmap ourselves,
> without
> > > > > public discussion. This would somewhat circumvent the process,
> though.
> > > > >
> > > > > If we decide to discuss just the proposal as is, though, then I'd
> be
> > > > > weakly against the proposed syntax as it is too subtle for my taste
> > > > > and abuses familiar mathematical notation somewhat. I'd probably
> > > > > prefer something like:
> > > > >
> > > > > type a -> t
> > > > >
> > > > > The proposal also doesn't specify what language extension would
> turn
> > > > > on support for the syntax so this would have to be rectified.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Roman
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > ghc-steering-committee at haskell.org
> > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-
> steering-committee
> > > >
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-
> steering-committee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180809/b86b9248/attachment.html>

From rleshchinskiy at gmail.com  Thu Aug  9 19:45:52 2018
From: rleshchinskiy at gmail.com (Roman Leshchinskiy)
Date: Thu, 9 Aug 2018 20:45:52 +0100
Subject: [ghc-steering-committee] Proposal: Top-level kind signatures (#54)
Message-ID: <CAADqg9b=o2A_NQSMrb2GdcfWAHcSAAbeSrmt-+N+s--1UQMwEA@mail.gmail.com>

Hi everyone,

The proposal is about adding stand-alone kind signatures for type
declarations:

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

The basic idea is to add support for kind signatures like this:

type T :: Type -> Type -> Type
data T a b = ...

Signatures would be introduced by the keyword 'type' and could be provided
for data types, type synonyms, type families and classes. The extension
would be enable via -XTopLevelKinds.

Additionally, complete user-supplied kind signatures (CUSKs, see
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#complete-user-supplied-kind-signatures-and-polymorphic-recursion)
would be given a separate language extension, -XCUSKs which would be on by
default for now but turned off in GHC 8.8 and then deprecated and removed.

The proposal depends on #81.

Feedback has been positive and this is rather cleaner than the current
story so I'm in favour of accepting this.

Like Richard, I'm not really happy with the name "TopLevelKinds",
especially since signatures for associated types aren't even on the top
level. Would something like StandAloneKinds or ExplicitKindSignatures be
better?

One minor point that isn't clear to me: the proposal says that "Associated
types may be given kind signatures within their classes". Are type
variables mentioned in the class head visible in the kind signature for the
associated type?

Thanks,

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

From iavor.diatchki at gmail.com  Mon Aug 13 08:52:00 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 13 Aug 2018 11:52:00 +0300
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <CADnndOrJuXEPj=FdG3_JsT2AV9UPCzdHxfw=-4Xk3sxU11gq5Q@mail.gmail.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <CADnndOoU23SAzqS8EQ4FgXdSE=EHrnnJ56XXwmeVf_eETN-jgA@mail.gmail.com>
 <f22550b2886d61f26090ba011c4ba81b97f5dc49.camel@joachim-breitner.de>
 <CADnndOrJuXEPj=FdG3_JsT2AV9UPCzdHxfw=-4Xk3sxU11gq5Q@mail.gmail.com>
Message-ID: <CAGK9nuo1Vf+icSS-4BcC_gcN30B0issVP8H2Ew6tu7QwfRbHUg@mail.gmail.com>

We've had this under discussion for just about 2 weeks, and there does not
appear to be any objections, so I think we should accept it.

On Sat, Aug 4, 2018 at 10:05 PM Christopher Allen <cma at bitemyapp.com> wrote:

> Seems reasonable to me. There's been a general push to eliminate cases
> for Proxy as well.
>
> On Sat, Aug 4, 2018 at 1:33 PM, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
> > Hi,
> >
> > Am Samstag, den 04.08.2018, 13:16 -0500 schrieb Christopher Allen:
> >> Could someone give me a motivating example for what this enables?
> >
> > with “this”, do you refer to type applications in patterns?
> > The main fundamental motivation is to bind existential type variables.
> > Currently we often do this using Proxy, but we’d like a more convenient
> > syntax that mirrors type applications in patterns.
> >
> >
> > or do you refer to allowing complex patterns on both sides of an as-
> > pattern? I don’t have an example for this handy, and maybe we actually
> > never want that, in which case there is no issue.
> >
> > 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
> >
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
> _______________________________________________
> 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/20180813/6ed31efe/attachment.html>

From eric at seidel.io  Wed Aug 15 00:31:59 2018
From: eric at seidel.io (Eric Seidel)
Date: Tue, 14 Aug 2018 20:31:59 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without Promotion
	(#106)
Message-ID: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>

Hi everyone!

This proposal would allow the declaration of new kinds and type constructors, without the associated data constructors that would have been generated by -XDataKinds.

https://github.com/yav/ghc-proposals/blob/data-kind-only/proposals/0000-type-data.rst

It introduces a new language extension, -XTypeData, which allows declarations like the following:

  type data Universe = Character | Number | Boolean

This introduces a new kind, Universe, with three associated type constructors

  Character :: Universe
  Number :: Universe
  Boolean :: Universe

Notably, no data constructors are introduced.

The proposal aims to solve several usability issues with -XDataKinds:

1. We often don't want the data constructors, which simply pollute the value namespace.
2. We cannot easily control the export behavior of promoted types (instead we resort to tricks like the alias `type Character = 'Character`).
3. The name resolution rules involving promoted types can be confusing.

I find these issues (particularly #2) compelling, and the community response seems to be mostly positive, so I recommend accepting the proposal. 

I'm not particularly fond of the proposed syntax (`type data` makes it sound like we're doing something with data constructors, which is precisely what we're NOT doing), but the proposal has already had a good bit of bikeshedding, and people seem mostly happy with the current syntax, so I think we should probably stick with `type data`.

Eric

From eric at seidel.io  Wed Aug 15 00:38:29 2018
From: eric at seidel.io (Eric Seidel)
Date: Tue, 14 Aug 2018 20:38:29 -0400
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <CAGK9nuo1Vf+icSS-4BcC_gcN30B0issVP8H2Ew6tu7QwfRbHUg@mail.gmail.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <CADnndOoU23SAzqS8EQ4FgXdSE=EHrnnJ56XXwmeVf_eETN-jgA@mail.gmail.com>
 <f22550b2886d61f26090ba011c4ba81b97f5dc49.camel@joachim-breitner.de>
 <CADnndOrJuXEPj=FdG3_JsT2AV9UPCzdHxfw=-4Xk3sxU11gq5Q@mail.gmail.com>
 <CAGK9nuo1Vf+icSS-4BcC_gcN30B0issVP8H2Ew6tu7QwfRbHUg@mail.gmail.com>
Message-ID: <1534293509.3993821.1474417352.3555694B@webmail.messagingengine.com>

I'm in favor of accepting as well.

On Mon, Aug 13, 2018, at 04:52, Iavor Diatchki wrote:
> We've had this under discussion for just about 2 weeks, and there does not
> appear to be any objections, so I think we should accept it.
> 
> On Sat, Aug 4, 2018 at 10:05 PM Christopher Allen <cma at bitemyapp.com> wrote:
> 
> > Seems reasonable to me. There's been a general push to eliminate cases
> > for Proxy as well.
> >
> > On Sat, Aug 4, 2018 at 1:33 PM, Joachim Breitner
> > <mail at joachim-breitner.de> wrote:
> > > Hi,
> > >
> > > Am Samstag, den 04.08.2018, 13:16 -0500 schrieb Christopher Allen:
> > >> Could someone give me a motivating example for what this enables?
> > >
> > > with “this”, do you refer to type applications in patterns?
> > > The main fundamental motivation is to bind existential type variables.
> > > Currently we often do this using Proxy, but we’d like a more convenient
> > > syntax that mirrors type applications in patterns.
> > >
> > >
> > > or do you refer to allowing complex patterns on both sides of an as-
> > > pattern? I don’t have an example for this handy, and maybe we actually
> > > never want that, in which case there is no issue.
> > >
> > > 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
> > >
> >
> >
> >
> > --
> > Chris Allen
> > Currently working on http://haskellbook.com
> > _______________________________________________
> > 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 eric at seidel.io  Wed Aug 15 02:16:33 2018
From: eric at seidel.io (Eric Seidel)
Date: Tue, 14 Aug 2018 22:16:33 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
Message-ID: <1534299393.4019762.1474430160.1C2499EB@webmail.messagingengine.com>

I also have a few concerns about the proposal.

1. The proposal suggests making all data constructors linear when -XLinearTypes is disabled. Can we guarantee that this will not cause multiplicities to leak into type errors where -XLinearTypes is disabled? The proposal doesn't say, and Richard seems to think not based on his email above. I can understand having to deal with linearity if I've imported modules that use -XLinearTypes, but not if I just use types that were silently inferred to be linear. -XLinearTypes ought to be opt-in.

2. Am I correct in understanding that the only way to guarantee resource safety in this proposal is to write all allocation functions in CPS with a linear continuation? If so, this seems to be a substantial divergence from the intuitive notion of type safety. I don't have to worry about my API design to ensure my program won't segfault, GHC guarantees that for me (and we give the inevitable escape hatches scary names). Similarly, I think users will expect GHC to prevent them from writing programs that misuse resources, but this guarantee is only provided if the API is designed correctly, ie with CPS'd allocators. We don't generally think of type safety as being conditional on API design. The linearity-in-the-kind and uniqueness alternatives (I don't quite understand the difference) seem better in this respect; I want ALL sockets/handles/MArrays/etc to be linear.

I wonder if we could somehow take advantage of the fact that allocators are already implicitly CPS'd (as monadic functions) to allow users to write code in the natural style while retaining the linear guarantees?

On Tue, Aug 7, 2018, at 01:50, Iavor Diatchki wrote:
> Hello,
> 
> I am not sure that the amount of effort that went into writing a proposal
> should be a deciding factor about if the proposal is accepted.  We don't
> want to discourage folks, but also, once things get into GHC they are hard
> to get out, so I think caution is warranted.
> 
> I find this proposal to be constructed rather poorly.  I read the previous
> version, and I also read this one, and I find it to be a rather small
> improvement, if at all.  For a relatively complex proposal change, the
> proposal had hardly any examples.  To me, it read as a patchwork of
> paragraphs, that are an uneasy mix of informal explanations with no
> examples, overly formal explanations, potential things one might use this
> for (RIO??), and what seem to be answers to questions from the GitHub
> discussion, which are just perplexing if you read the proposal before the
> discussion.
> 
> This makes it quite hard to grasp the main idea.  Having said that I think
> I get what is being proposed and I like parts of it.
> 
> The main high level concern I have is the overloading of the function space
> arrow.  We already have it overloaded in all kinds of ways, and adding one
> more dimension without any kind of underlying system seems too much.  I am
> not at all convinced that we will be able to "hide" multiplicities when the
> extension is not enabled.
> 
> Overall, while I like the core ideas, I would prefer a different way of
> integrating them into Haskell, one that is more modular, even at the cost
> of having to duplicate some code.  My reasoning is that while linearity
> might be useful in some cases, most of the time it is not something that
> we'd care about much, so we should not add it (at least straight away) to
> the core part of the language (functions and data types).
> 
> -Iavor
> 
> 
> On Fri, Aug 3, 2018, 1:41 AM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> 
> > Conversation seems to have died down on this trail, both on GitHub and
> > here in committee. As the shepherd, it's my job to kick us back into action.
> >
> > After much conversation on GitHub, there are still a few dangling loose
> > ends to this proposal:
> >
> > - The proposal defined *consume exactly once*, but I don't that definition
> > is fully correct and it's not general enough. For example, it doesn't treat
> > abstract types or unboxed ones. Simon has suggested that it's meant purely
> > for intuition (for which it works well) but is not meant to be a technical
> > specification. The other proposal authors seem to disagree with this, but
> > I'm yet to be satisfied by an attempt at defining this.
> >
> > - The proposal says nothing on the subject of type inference. This is
> > understandable, because it's really hard to know what will work best.
> > However, there has not yet been a commitment that type inference will be
> > backward-compatible. The authors want the presence/absence of -XLinearTypes
> > not to affect type inference, and they also want sometimes to infer linear
> > types. I think these, together, imply that the proposal isn't fully
> > backward compatible. See
> > https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-406723478
> >
> > - The proposal mentions the idea of unification of multiplicities up to
> > semiring equalities, but then the authors claim that such a procedure is
> > undecidable. It's unclear where this stands.
> >
> > - There is no design that will stop Haskell learners from seeing linear
> > types in error messages, though it appears they won't appear with :type.
> >
> > - Simon M has pushed on the motivations of the proposal, trying to
> > understand better exactly what problems this proposal solves. I have not
> > followed this sub-thread terribly closely, and will take advantage of the
> > fact that Simon is on this committee and can speak for himself on these
> > issues.
> >
> > Despite these dangling pieces, I do think they all can be resolved.
> > (Except perhaps the motivation piece if it's problematic enough.) I thus
> > recommend that we officially encourage this proposal on the road toward
> > acceptance. This recommendation is based on the excitement in the community
> > around linear types and the high degree of effort and commitment the
> > authors have shown.
> >
> > If you disagree with this recommendation, please speak up. As usual, I
> > will take silence as agreement and make an official pronouncement to the
> > authors in due course.
> >
> > Thanks,
> > Richard
> >
> > On Jul 8, 2018, at 11:41 PM, 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 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
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From rae at cs.brynmawr.edu  Wed Aug 15 03:09:52 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 14 Aug 2018 23:09:52 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
Message-ID: <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>

I'm neutral on this proposal, but I know there are others who are quite keen on it, so that favors acceptance. However, I would request changes to the proposal text: this proposal has nothing at all to do with promotion. Instead, this is all to do with namespaces. I think a lot of clever people misunderstand this point, and so I would want the proposal to be carefully worded around this.

Under this proposal, a the constructors of a datatype introduced with `type data` are added to the type-level namespace instead of the data-level namespace. And that's it!

Specifically:

- Types and kinds are simply the same now. There really is no difference. So the first sentence of this proposal, "This proposal introduces a language construct for defining kinds without having to promote types." is, in my opinion, quite misleading. All `data` declarations introduce kinds (because they introduce types, and types = kinds). And data constructors aren't really promoted either -- they can simply be used in types.

- The proposal talks about referring to types in export lists. But we can already do this, via the normal syntax for listing data constructors with type constructors. So I'm not sure what that point of motivation really means.

- The "normal types win" is true, but it's all about namespace lookup. In a type, when GHC sees a capitalized identifier, it looks in the type namespace for that identifier. If the identifier is bound in the type namespace, that identifier is found. If not, GHC looks in the data-level namespace. According to this algorithm, "normal types win", indeed. But the "normal"cy of the type is that it lives in the type namespace, not because it isn't promoted.

- If something introduced with `type data` can be used without -XDataKinds, then what does -XDataKinds really mean? It would seem to enable solely the extra data-level namespace check. That's fine with me, but we should document it that way. Alternatively, -XDataKinds could mean that some types have kinds that don't end in Type or Constraint, in which case it would need to be enabled to use a `type data` data constructor.

- The RHS of a `type data` does not introduce type constructors. A type constructor constructs a type -- that is, if T is a type constructor, then T applied to appropriate arguments has kind Type (or Constraint). But the data constructors of `type data` really are data constructors. It just so happens that their names live only in the type-level namespace. If we want, we can call these "type-level data constructors", but I think "type constructors" is misleading.

Rereading the GitHub trail, I see that I've voiced support in the recent past. This is still true, but before this proposal text gets locked into perpetuity, I think clarifying the points above would be very helpful.

Thanks,
Richard

> On Aug 14, 2018, at 8:31 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> Hi everyone!
> 
> This proposal would allow the declaration of new kinds and type constructors, without the associated data constructors that would have been generated by -XDataKinds.
> 
> https://github.com/yav/ghc-proposals/blob/data-kind-only/proposals/0000-type-data.rst
> 
> It introduces a new language extension, -XTypeData, which allows declarations like the following:
> 
>  type data Universe = Character | Number | Boolean
> 
> This introduces a new kind, Universe, with three associated type constructors
> 
>  Character :: Universe
>  Number :: Universe
>  Boolean :: Universe
> 
> Notably, no data constructors are introduced.
> 
> The proposal aims to solve several usability issues with -XDataKinds:
> 
> 1. We often don't want the data constructors, which simply pollute the value namespace.
> 2. We cannot easily control the export behavior of promoted types (instead we resort to tricks like the alias `type Character = 'Character`).
> 3. The name resolution rules involving promoted types can be confusing.
> 
> I find these issues (particularly #2) compelling, and the community response seems to be mostly positive, so I recommend accepting the proposal. 
> 
> I'm not particularly fond of the proposed syntax (`type data` makes it sound like we're doing something with data constructors, which is precisely what we're NOT doing), but the proposal has already had a good bit of bikeshedding, and people seem mostly happy with the current syntax, so I think we should probably stick with `type data`.
> 
> Eric
> _______________________________________________
> 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  Wed Aug 15 08:21:44 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 15 Aug 2018 10:21:44 +0200
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
Message-ID: <87BC6D5B-60FD-49D4-A6DC-660692CE1739@justtesting.org>

Richard makes good points here.

Cheers,
Manuel

> Am 15.08.2018 um 05:09 schrieb Richard Eisenberg <rae at cs.brynmawr.edu>:
> 
> I'm neutral on this proposal, but I know there are others who are quite keen on it, so that favors acceptance. However, I would request changes to the proposal text: this proposal has nothing at all to do with promotion. Instead, this is all to do with namespaces. I think a lot of clever people misunderstand this point, and so I would want the proposal to be carefully worded around this.
> 
> Under this proposal, a the constructors of a datatype introduced with `type data` are added to the type-level namespace instead of the data-level namespace. And that's it!
> 
> Specifically:
> 
> - Types and kinds are simply the same now. There really is no difference. So the first sentence of this proposal, "This proposal introduces a language construct for defining kinds without having to promote types." is, in my opinion, quite misleading. All `data` declarations introduce kinds (because they introduce types, and types = kinds). And data constructors aren't really promoted either -- they can simply be used in types.
> 
> - The proposal talks about referring to types in export lists. But we can already do this, via the normal syntax for listing data constructors with type constructors. So I'm not sure what that point of motivation really means.
> 
> - The "normal types win" is true, but it's all about namespace lookup. In a type, when GHC sees a capitalized identifier, it looks in the type namespace for that identifier. If the identifier is bound in the type namespace, that identifier is found. If not, GHC looks in the data-level namespace. According to this algorithm, "normal types win", indeed. But the "normal"cy of the type is that it lives in the type namespace, not because it isn't promoted.
> 
> - If something introduced with `type data` can be used without -XDataKinds, then what does -XDataKinds really mean? It would seem to enable solely the extra data-level namespace check. That's fine with me, but we should document it that way. Alternatively, -XDataKinds could mean that some types have kinds that don't end in Type or Constraint, in which case it would need to be enabled to use a `type data` data constructor.
> 
> - The RHS of a `type data` does not introduce type constructors. A type constructor constructs a type -- that is, if T is a type constructor, then T applied to appropriate arguments has kind Type (or Constraint). But the data constructors of `type data` really are data constructors. It just so happens that their names live only in the type-level namespace. If we want, we can call these "type-level data constructors", but I think "type constructors" is misleading.
> 
> Rereading the GitHub trail, I see that I've voiced support in the recent past. This is still true, but before this proposal text gets locked into perpetuity, I think clarifying the points above would be very helpful.
> 
> Thanks,
> Richard
> 
>> On Aug 14, 2018, at 8:31 PM, Eric Seidel <eric at seidel.io> wrote:
>> 
>> Hi everyone!
>> 
>> This proposal would allow the declaration of new kinds and type constructors, without the associated data constructors that would have been generated by -XDataKinds.
>> 
>> https://github.com/yav/ghc-proposals/blob/data-kind-only/proposals/0000-type-data.rst
>> 
>> It introduces a new language extension, -XTypeData, which allows declarations like the following:
>> 
>> type data Universe = Character | Number | Boolean
>> 
>> This introduces a new kind, Universe, with three associated type constructors
>> 
>> Character :: Universe
>> Number :: Universe
>> Boolean :: Universe
>> 
>> Notably, no data constructors are introduced.
>> 
>> The proposal aims to solve several usability issues with -XDataKinds:
>> 
>> 1. We often don't want the data constructors, which simply pollute the value namespace.
>> 2. We cannot easily control the export behavior of promoted types (instead we resort to tricks like the alias `type Character = 'Character`).
>> 3. The name resolution rules involving promoted types can be confusing.
>> 
>> I find these issues (particularly #2) compelling, and the community response seems to be mostly positive, so I recommend accepting the proposal.
>> 
>> I'm not particularly fond of the proposed syntax (`type data` makes it sound like we're doing something with data constructors, which is precisely what we're NOT doing), but the proposal has already had a good bit of bikeshedding, and people seem mostly happy with the current syntax, so I think we should probably stick with `type data`.
>> 
>> Eric
>> _______________________________________________
>> 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 --------------
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/20180815/16bee858/attachment.sig>

From eric at seidel.io  Wed Aug 15 13:41:53 2018
From: eric at seidel.io (Eric Seidel)
Date: Wed, 15 Aug 2018 09:41:53 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
Message-ID: <1534340513.3798069.1474942024.0C489761@webmail.messagingengine.com>

I'm happy to request clarification, but first I'd like to clarify a few things for myself :)

On Tue, Aug 14, 2018, at 23:09, Richard Eisenberg wrote:
> - The proposal talks about referring to types in export lists. But we 
> can already do this, via the normal syntax for listing data constructors 
> with type constructors. So I'm not sure what that point of motivation 
> really means.

The normal syntax for exporting data constructors would export the constructor in both the value namespace AND the type namespace. But we didn't want the constructor in the value namespace to begin with. I think this is the issue, we have no way to export ONLY the constructor in the type namespace.

> - The "normal types win" is true, but it's all about namespace lookup. 
> In a type, when GHC sees a capitalized identifier, it looks in the type 
> namespace for that identifier. If the identifier is bound in the type 
> namespace, that identifier is found. If not, GHC looks in the data-level 
> namespace. According to this algorithm, "normal types win", indeed. But 
> the "normal"cy of the type is that it lives in the type namespace, not 
> because it isn't promoted.
> 
> - If something introduced with `type data` can be used without -XDataKinds,
> then what does -XDataKinds really mean? It would seem to 
> enable solely the extra data-level namespace check. That's fine with me, 
> but we should document it that way. Alternatively, -XDataKinds could 
> mean that some types have kinds that don't end in Type or Constraint, in 
> which case it would need to be enabled to use a `type data` data 
> constructor.

I think I agree with both of these points.

> - Types and kinds are simply the same now. There really is no 
> difference. So the first sentence of this proposal, "This proposal 
> introduces a language construct for defining kinds without having to 
> promote types." is, in my opinion, quite misleading. All `data` 
> declarations introduce kinds (because they introduce types, and types = 
> kinds). And data constructors aren't really promoted either -- they can 
> simply be used in types.

True, it's misleading to say that types are promoted to kinds (though, as you've mentioned elsewhere, the distinction is still quite useful for us humans), but I don't think it's misleading to say that data constructors are promoted to type constructors. See below.

> - The RHS of a `type data` does not introduce type constructors. A type 
> constructor constructs a type -- that is, if T is a type constructor, 
> then T applied to appropriate arguments has kind Type (or Constraint). 
> But the data constructors of `type data` really are data constructors. 
> It just so happens that their names live only in the type-level 
> namespace. If we want, we can call these "type-level data constructors", 
> but I think "type constructors" is misleading.

I think "type-level data constructors" just makes things more confusing. The way I think about it (and I could certainly be wrong!), data constructors produce objects that can be used at the value level, and type constructors produce objects that can be used at the type level. We still have a value/type level distinction in Haskell, so the term "type-level data constructor" reads like an oxymoron to me. Another way of saying this could just be that "data" constructors live in the value namespace, while "type" constructors live in the type namespace. (I realize that these "type-level data" constructors are probably still represented in GHC with `DataCon`s, but I think my classification is probably more useful from an end-user perspective.)

If you think of type constructors in my sense, then I think it also makes sense to call the constructors introduced by `type data` type constructors. 

I look forward to being corrected!

From iavor.diatchki at gmail.com  Wed Aug 15 17:36:09 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 15 Aug 2018 20:36:09 +0300
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <1534293509.3993821.1474417352.3555694B@webmail.messagingengine.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <CADnndOoU23SAzqS8EQ4FgXdSE=EHrnnJ56XXwmeVf_eETN-jgA@mail.gmail.com>
 <f22550b2886d61f26090ba011c4ba81b97f5dc49.camel@joachim-breitner.de>
 <CADnndOrJuXEPj=FdG3_JsT2AV9UPCzdHxfw=-4Xk3sxU11gq5Q@mail.gmail.com>
 <CAGK9nuo1Vf+icSS-4BcC_gcN30B0issVP8H2Ew6tu7QwfRbHUg@mail.gmail.com>
 <1534293509.3993821.1474417352.3555694B@webmail.messagingengine.com>
Message-ID: <CAGK9nurhijpEop5qduSw4gkxDZ51TuY=5Rqxtz7tSaobUhgsrw@mail.gmail.com>

Ok, I'll mark it as accepted.

On Wed, Aug 15, 2018 at 3:38 AM Eric Seidel <eric at seidel.io> wrote:

> I'm in favor of accepting as well.
>
> On Mon, Aug 13, 2018, at 04:52, Iavor Diatchki wrote:
> > We've had this under discussion for just about 2 weeks, and there does
> not
> > appear to be any objections, so I think we should accept it.
> >
> > On Sat, Aug 4, 2018 at 10:05 PM Christopher Allen <cma at bitemyapp.com>
> wrote:
> >
> > > Seems reasonable to me. There's been a general push to eliminate cases
> > > for Proxy as well.
> > >
> > > On Sat, Aug 4, 2018 at 1:33 PM, Joachim Breitner
> > > <mail at joachim-breitner.de> wrote:
> > > > Hi,
> > > >
> > > > Am Samstag, den 04.08.2018, 13:16 -0500 schrieb Christopher Allen:
> > > >> Could someone give me a motivating example for what this enables?
> > > >
> > > > with “this”, do you refer to type applications in patterns?
> > > > The main fundamental motivation is to bind existential type
> variables.
> > > > Currently we often do this using Proxy, but we’d like a more
> convenient
> > > > syntax that mirrors type applications in patterns.
> > > >
> > > >
> > > > or do you refer to allowing complex patterns on both sides of an as-
> > > > pattern? I don’t have an example for this handy, and maybe we
> actually
> > > > never want that, in which case there is no issue.
> > > >
> > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > Chris Allen
> > > Currently working on http://haskellbook.com
> > > _______________________________________________
> > > 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/20180815/e7290fbd/attachment.html>

From bravit111 at gmail.com  Thu Aug 16 00:37:08 2018
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Wed, 15 Aug 2018 17:37:08 -0700
Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn on
 unbanged strict patterns (#35); Recommendation: Reject
Message-ID: <CALpVSmOrzO=EAa=aYxHqwZyj-QFzXKg_8HcF42GJFu1c03iT7w@mail.gmail.com>

Hi,

the lazy unboxed tuples proposal  (
https://github.com/ghc-proposals/ghc-proposals/pull/35) was under
discussion for a long period of time (more than a year and a half since
submission).

As a shepherd to this proposal I recommend rejection based on the following:

* there is no clearly articulated motivation in favor of this proposal
despite complying with the Manual;
* implementing this would lead to hard-to-trace performance issues in the
users code (due to move from strictness in current GHC behaviour to
laziness);
* it looks like the change (B) of the proposal (warn an unbanged strict
patterns) meets no complains, so it is better to be resubmitted as a
separate proposal;
* if resubmitted separately the change (A) should elaborate on desugaring
to make potential performance drawbacks clear;
* it seems (maybe mistakenly) that the author has lost his interest in this
proposal.

Although silence is undestood as agreement, I'd be glad to receive a
feedback on this recommendation.

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

From eric at seidel.io  Thu Aug 16 01:26:41 2018
From: eric at seidel.io (Eric Seidel)
Date: Wed, 15 Aug 2018 21:26:41 -0400
Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn
 on unbanged strict patterns (#35); Recommendation: Reject
In-Reply-To: <CALpVSmOrzO=EAa=aYxHqwZyj-QFzXKg_8HcF42GJFu1c03iT7w@mail.gmail.com>
References: <CALpVSmOrzO=EAa=aYxHqwZyj-QFzXKg_8HcF42GJFu1c03iT7w@mail.gmail.com>
Message-ID: <1534382801.1930743.1475669512.7751AA0B@webmail.messagingengine.com>

I'm inclined to agree that change (A) should be rejected, specifically that we should view this as a bug in the Manual rather than the implementation.

Change (B) seems quite reasonable though. We could suggest resubmitting it separately, or suggest revising the proposal to only propose (B). If we reject (A), it might also make sense to issue a warning for an unbanged unboxed tuple patterns, to make it abundantly clear that the pattern will be matched strictly. I used unboxed tuples for the first time last week, and to be honest the question of whether my unboxed tuple pattern would be matched strictly or lazily didn't even occur to me! I think I would have been very happy had GHC yelled at me about that.

On Wed, Aug 15, 2018, at 20:37, Vitaly Bragilevsky wrote:
> Hi,
> 
> the lazy unboxed tuples proposal  (
> https://github.com/ghc-proposals/ghc-proposals/pull/35) was under
> discussion for a long period of time (more than a year and a half since
> submission).
> 
> As a shepherd to this proposal I recommend rejection based on the following:
> 
> * there is no clearly articulated motivation in favor of this proposal
> despite complying with the Manual;
> * implementing this would lead to hard-to-trace performance issues in the
> users code (due to move from strictness in current GHC behaviour to
> laziness);
> * it looks like the change (B) of the proposal (warn an unbanged strict
> patterns) meets no complains, so it is better to be resubmitted as a
> separate proposal;
> * if resubmitted separately the change (A) should elaborate on desugaring
> to make potential performance drawbacks clear;
> * it seems (maybe mistakenly) that the author has lost his interest in this
> proposal.
> 
> Although silence is undestood as agreement, I'd be glad to receive a
> feedback on this recommendation.
> 
> Regards,
> Vitaly
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From rae at cs.brynmawr.edu  Thu Aug 16 04:15:16 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 16 Aug 2018 00:15:16 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <1534340513.3798069.1474942024.0C489761@webmail.messagingengine.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <1534340513.3798069.1474942024.0C489761@webmail.messagingengine.com>
Message-ID: <3DF05FA3-B2D8-4118-8A44-39FBD0B9CCF7@cs.brynmawr.edu>



> On Aug 15, 2018, at 9:41 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> The normal syntax for exporting data constructors would export the constructor in both the value namespace AND the type namespace. But we didn't want the constructor in the value namespace to begin with. I think this is the issue, we have no way to export ONLY the constructor in the type namespace.

I disagree here. The normal syntax exports data constructors only in the data-level namespace, because those constructors don't live at all in the type-level namespace. (The ' syntax doesn't promote anything: it's just a signal to the renamer to look only in the data-level namespace, bypassing the normal type-level lookup.) Right now, the only way to get a data constructor in the type-level namespace is to use a type synonym, and (presumably) the author of this proposal finds that fact annoying (understandably).

> 
> I think "type-level data constructors" just makes things more confusing. The way I think about it (and I could certainly be wrong!), data constructors produce objects that can be used at the value level, and type constructors produce objects that can be used at the type level.

This is a common usage of these terms, so you're not alone. But I don't think it's a helpful vocabulary. The dependent types literature diverges from this usage considerably, not distinguishing between runtime data and compile-time data. As GHC inches toward dependent types (even if we get no further in this direction, the "promotion" feature is directly inspired by dependent types), I think updating our usage of these vocabulary words will be helpful.

> We still have a value/type level distinction in Haskell, so the term "type-level data constructor" reads like an oxymoron to me.

Is it perhaps more comfortable to think of compile-time data vs. runtime data?

> Another way of saying this could just be that "data" constructors live in the value namespace, while "type" constructors live in the type namespace.

I think it all boils down to vocabulary here. We could define the terms this way. But then we need to talk about promoting data constructors to type constructors. We also have the awkwardness of explaining that, say, `'True` is a type (it is used on the type level) but no values have type `'True`. I think it's much clearer to say that `'True` is type-level data. No promotion anymore, just namespaces, and we reserve type to mean things like `Int`.
> 
> If you think of type constructors in my sense, then I think it also makes sense to call the constructors introduced by `type data` type constructors. 

Agreed about this implication. But since I don't satisfy your premise, I'm not bound to agree with your conclusion.

To be clear, I don't think there's a "right" vocabulary and a "wrong" vocabulary here. (And perhaps my email from yesterday is too strongly worded in places around this -- apologies.) I do think the vocabulary I'm advocating for will lead to a simpler formulation of this all and will help Haskellers get a better intuition around these features than the other vocabulary. This change has been slow to formulate in my own head, and is the result of thinking about these issues a lot over the past years -- I, too, have wanted to call data constructors used in types "type constructors". I no longer think it's the best way to describe it, though.

I hope this helps!
Richard

From simonpj at microsoft.com  Thu Aug 16 07:38:14 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 16 Aug 2018 07:38:14 +0000
Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn
 on unbanged strict patterns (#35); Recommendation: Reject
In-Reply-To: <CALpVSmOrzO=EAa=aYxHqwZyj-QFzXKg_8HcF42GJFu1c03iT7w@mail.gmail.com>
References: <CALpVSmOrzO=EAa=aYxHqwZyj-QFzXKg_8HcF42GJFu1c03iT7w@mail.gmail.com>
Message-ID: <AM0PR83MB030892D4A17DA41D292C4CF3AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

I’m actually mildly in favour of the proposed design.

The main reason for rejection is really

* It’s a change

Change is always a bit disruptive; and no one is arguing strongly that they really really want this.

So maybe we should just “park” it as OK in principle, but without sufficient support to justify the (hard to quantify) changeover costs.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Vitaly Bragilevsky
Sent: 16 August 2018 01:37
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn on unbanged strict patterns (#35); Recommendation: Reject

Hi,

the lazy unboxed tuples proposal  (https://github.com/ghc-proposals/ghc-proposals/pull/35<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F35&data=02%7C01%7Csimonpj%40microsoft.com%7C983115e9eee64eb4b03c08d603107655%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636699766583676606&sdata=PXTsCrM4otm8ZCEFZvNfkydSBo6J77zh5qb9CVNmZX8%3D&reserved=0>) was under discussion for a long period of time (more than a year and a half since submission).

As a shepherd to this proposal I recommend rejection based on the following:

* there is no clearly articulated motivation in favor of this proposal despite complying with the Manual;
* implementing this would lead to hard-to-trace performance issues in the users code (due to move from strictness in current GHC behaviour to laziness);
* it looks like the change (B) of the proposal (warn an unbanged strict patterns) meets no complains, so it is better to be resubmitted as a separate proposal;
* if resubmitted separately the change (A) should elaborate on desugaring to make potential performance drawbacks clear;
* it seems (maybe mistakenly) that the author has lost his interest in this proposal.

Although silence is undestood as agreement, I'd be glad to receive a feedback on this recommendation.

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

From simonpj at microsoft.com  Thu Aug 16 08:46:20 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 16 Aug 2018 08:46:20 +0000
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
Message-ID: <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  And I would like a second pair of eyes there, as this choice blocks us from
|  in the future allowing patterns on both sides on @, i.e. something like
|  
|     Just (_ :_) @ (fun -> True) @ x

Yes, this is a bit annoying.  See the "Alternatives" section of the accepted proposal "As patterns in pattern synonyms", here:

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

The proposal points out that "@" makes sense as an "and-pattern", dual to "or-patterns" (which are, I hope, close to acceptance).

However, if I read it aright, the proposed new syntax does NOT include
	Just (_ : _) @ (fun -> True)
because in the proposal the thing to the left of the "@" must be a gcon, or another type application.  So even if we added and-patterns, there's no ambiguity here.

What would be ambiguous is this and-pattern:
	Nothing @ pat
(i.e. with a nullary contructor as the first of p1 at p2).  But that's a pretty silly and-pattern so I think we could let this ambiguous case resolve as a pattern type application. You could I suppose write (Nothing)@pat to get the and-pattern.

TL;DR: I don't think the current proposal blocks future more compositional use of "@".

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
|  Behalf Of Joachim Breitner
|  Sent: 04 August 2018 16:27
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Discussion about "Type Application in
|  Patterns" (#126)
|  
|  Hi,
|  
|  can we have an additional nod by someone who is not an author of the
|  corresponding paper?
|  
|  Also, I updated the proposal to answer the disambiguation with as-
|  patterns:
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F126%2Fcommits%2F12d64105b0979c674502c3768118b424d09a572b&
|  amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cc38b4c2cc1b441aceca108d5fa1ed3b
|  2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636689932664304509&amp;sdata=
|  l2sjKwC3Lq16kzmfKB2dCEHktaDVVjj6IeGFrlCMhXQ%3D&amp;reserved=0
|  And I would like a second pair of eyes there, as this choice blocks us from
|  in the future allowing patterns on both sides on @, i.e. something like
|  
|     Just (_ :_) @ (fun -> True) @ x
|  
|  because
|  
|     Nothing @ a
|  
|  would be ambiguous.
|  
|  Cheers,
|  Joachim
|  
|  Am Donnerstag, den 26.07.2018, 11:08 +0300 schrieb Iavor Diatchki:
|  > 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-committ
|  > ee
|  --
|  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%7Cc38b4c2cc1b441ac
|  eca108d5fa1ed3b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63668993266430
|  4509&amp;sdata=n9ZojGAGBrwWi0CYzr8RVCjlKNFByoEZxvWahxTlAvc%3D&amp;reserved=0

From iavor.diatchki at gmail.com  Thu Aug 16 10:02:01 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 16 Aug 2018 13:02:01 +0300
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
	Promotion (#106)
In-Reply-To: <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
Message-ID: <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>

Hello,

I'd be happy to make changes to the text of the proposal, but I would like
to understand the underlying concerns so that I can address them
appropriately.   At the moment, I am pretty sure that I am missing
something, as might be evident from my comments below.   Either way, my
comments below are intended to shed some light on my thinking, and
emphasize the parts of Richard's comments I don't understand.

On Wed, Aug 15, 2018 at 6:10 AM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

>
> - Types and kinds are simply the same now. There really is no difference.
> So the first sentence of this proposal, "This proposal introduces a
> language construct for defining kinds without having to promote types." is,
> in my opinion, quite misleading.


The proposal uses the same terminology that is used in GHC's manual, and
also by the majority of the Haskell community.  For example, Section 10.1
of the manual is about "Datatype Promotion", and the summary is "Allow
promotion of data types to kind level.".  Section 10.10.2 says "With
DataKinds, GHC automatically promotes every datatype to be a kind and its
(value) constructors to be type constructors.".  This proposal introduces a
language construct that allows us to declare non-empty kinds without having
to promote a datatype in the sense of 10.1.  I am talking about the
language specification, not the actual implementation, which we can discuss
once we agree we'd like to have this new feature.

All `data` declarations introduce kinds (because they introduce types, and
> types = kinds). And data constructors aren't really promoted either -- they
> can simply be used in types.
>

Of course this is technically correct, but without data type promotion
these are empty kinds that are a side-effect of mixing up types and kinds.
I say empty "kinds" rather than empty "types" to emphasize the fact that I
am referring to the kinding relation, not the typing one.



> - The proposal talks about referring to types in export lists. But we can
> already do this, via the normal syntax for listing data constructors with
> type constructors. So I'm not sure what that point of motivation really
> means.
>

Here is a datatype declaration:

data T = A | B

In current GHC how would you export the type `A` of kind `T` without
exporting the value `A` of type `T`?

Here is my attempt:

{-# Language DataKinds, ExplicitNamespaces #-}

module M (type A) where

data T = A | B

This results in:

error: Not in scope: type constructor or class ‘A’
  |
3 | module M (type A) where
  |           ^^^^^^


- The "normal types win" is true, but it's all about namespace lookup. In a
> type, when GHC sees a capitalized identifier, it looks in the type
> namespace for that identifier. If the identifier is bound in the type
> namespace, that identifier is found. If not, GHC looks in the data-level
> namespace. According to this algorithm, "normal types win", indeed. But the
> "normal"cy of the type is that it lives in the type namespace, not because
> it isn't promoted.
>

I think that with this proposal we have a much easier way to explain how
things work, without having to refer to the algorithm used by GHC's renamer:

data T = A | B    -- T is a type, and A and B are values of this type
type data S = X | Y -- S is a kind, and X and Y are types of this kind

Simple.


> - If something introduced with `type data` can be used without
> -XDataKinds, then what does -XDataKinds really mean? It would seem to
> enable solely the extra data-level namespace check. That's fine with me,
> but we should document it that way. Alternatively, -XDataKinds could mean
> that some types have kinds that don't end in Type or Constraint, in which
> case it would need to be enabled to use a `type data` data constructor.
>

This proposal is orthogonal to `DataKinds` and does not change anything
about how it works.

Personally, if I had `TypeData`, I think I would very rarely use
`DataKinds`, except for type-level nats and symbols, which should probably
get a separate extension anyway.  The reason is that I rarely need the same
constructors at the value and the type level without any link between the
two.


> - The RHS of a `type data` does not introduce type constructors. A type
> constructor constructs a type -- that is, if T is a type constructor, then
> T applied to appropriate arguments has kind Type (or Constraint). But the
> data constructors of `type data` really are data constructors. It just so
> happens that their names live only in the type-level namespace. If we want,
> we can call these "type-level data constructors", but I think "type
> constructors" is misleading.
>

I am sorry but I don't understand this at all---it is going contrary to the
terminology used by the Haskell community for decades.  I really don't see
why we need to invent new terms, and arbitrarily limit the term
"type-constructor" to only types of kind `Type` or `Constraint`, especially
if we are willing to refer to all "kinds" as "types".  The notion of
classifying types by kinds and having a rich kind language is completely
orthogonal to dependent types, and I think the current terminology works
just fine.

If I am reading Richard's comments correctly (and I apologize if I am
misunderstanding) his main concern is about terminology, based on his
vision and plans about Dependent Haskell.  I am supportive of work in this
area, but I don't think that this proposal is the right place to start
changing the terminology.   I would suggest that we stick with the
established language, which is widely used by the community, GHC's manual,
and GHC's source code.  Once there is a design document for Dependent
Haskell, we could discuss that and settle on appropriate terminology.

-Iavor







> Thanks,
> Richard
>
> > On Aug 14, 2018, at 8:31 PM, Eric Seidel <eric at seidel.io> wrote:
> >
> > Hi everyone!
> >
> > This proposal would allow the declaration of new kinds and type
> constructors, without the associated data constructors that would have been
> generated by -XDataKinds.
> >
> >
> https://github.com/yav/ghc-proposals/blob/data-kind-only/proposals/0000-type-data.rst
> >
> > It introduces a new language extension, -XTypeData, which allows
> declarations like the following:
> >
> >  type data Universe = Character | Number | Boolean
> >
> > This introduces a new kind, Universe, with three associated type
> constructors
> >
> >  Character :: Universe
> >  Number :: Universe
> >  Boolean :: Universe
> >
> > Notably, no data constructors are introduced.
> >
> > The proposal aims to solve several usability issues with -XDataKinds:
> >
> > 1. We often don't want the data constructors, which simply pollute the
> value namespace.
> > 2. We cannot easily control the export behavior of promoted types
> (instead we resort to tricks like the alias `type Character = 'Character`).
> > 3. The name resolution rules involving promoted types can be confusing.
> >
> > I find these issues (particularly #2) compelling, and the community
> response seems to be mostly positive, so I recommend accepting the
> proposal.
> >
> > I'm not particularly fond of the proposed syntax (`type data` makes it
> sound like we're doing something with data constructors, which is precisely
> what we're NOT doing), but the proposal has already had a good bit of
> bikeshedding, and people seem mostly happy with the current syntax, so I
> think we should probably stick with `type data`.
> >
> > Eric
> > _______________________________________________
> > 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/20180816/27769d14/attachment.html>

From mail at joachim-breitner.de  Thu Aug 16 22:01:42 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 16 Aug 2018 15:01:42 -0700
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 16.08.2018, 08:46 +0000 schrieb Simon Peyton Jones
via ghc-steering-committee:
> What would be ambiguous is this and-pattern:
>         Nothing @ pat
> (i.e. with a nullary contructor as the first of p1 at p2).  But that's a
> pretty silly and-pattern so I think we could let this ambiguous case
> resolve as a pattern type application. 

nullary constructors can be synonyms!

   pattern Ascii :: String
   pattern Ascii <- (all isAscii -> True)

and now

   foo (Ascii @ ('X':rest)) = 

is now longer as silly…

>  You could I suppose write
> (Nothing)@pat to get the and-pattern.

Significant parenthesis? Ugh.

But yeah, maybe it is good enough™ to deal with this particular corner.

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/20180816/8acdc3c4/attachment.sig>

From simonpj at microsoft.com  Thu Aug 16 23:22:46 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 16 Aug 2018 23:22:46 +0000
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
Message-ID: <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|    pattern Ascii :: String
|    pattern Ascii <- (all isAscii -> True)
| 
| and now
| 
|    foo (Ascii @ ('X':rest)) =
| 
| is now longer as silly…

That’s a good example.  It's easy to work around:

	pattern And p q = p at q

	foo (Ascii `And` ('X' : rest)) = ..

The proposal draw attention to whether ( (K) @type ) is or is not a legal pattern type application.   I think currently it is not.   So using "significant" parentheses would be another workaround.

Neither workaround is truly satisfactory, but I think the goodness of type applications in patterns (which we know we want) is more important than truly uniform and-patterns (which no one is asking for, yet).

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Joachim Breitner
| Sent: 16 August 2018 23:02
| To: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] Discussion about "Type Application
| in Patterns" (#126)
| 
| Hi,
| 
| Am Donnerstag, den 16.08.2018, 08:46 +0000 schrieb Simon Peyton Jones
| via ghc-steering-committee:
| > What would be ambiguous is this and-pattern:
| >         Nothing @ pat
| > (i.e. with a nullary contructor as the first of p1 at p2).  But that's a
| > pretty silly and-pattern so I think we could let this ambiguous case
| > resolve as a pattern type application.
| 
| nullary constructors can be synonyms!
| 
|    pattern Ascii :: String
|    pattern Ascii <- (all isAscii -> True)
| 
| and now
| 
|    foo (Ascii @ ('X':rest)) =
| 
| is now longer as silly…
| 
| >  You could I suppose write
| > (Nothing)@pat to get the and-pattern.
| 
| Significant parenthesis? Ugh.
| 
| But yeah, maybe it is good enough™ to deal with this particular corner.
| 
| Cheers,
| Joachim
| 
| 
| 
| --
| Joachim Breitner
|   mail at joachim-breitner.de
| 
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
| im-
| breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C36168190ebda4
| 2b8bf1408d603c3e1bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63670053
| 7181819165&amp;sdata=xoZDGIrlYH6AS3Lq7VFSCWu311UV5RMCS0ZsrhhzvwA%3D&amp;r
| eserved=0

From mail at joachim-breitner.de  Thu Aug 16 23:27:55 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 16 Aug 2018 16:27:55 -0700
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 16.08.2018, 23:22 +0000 schrieb Simon Peyton Jones:
> >    pattern Ascii :: String
> >    pattern Ascii <- (all isAscii -> True)
> > 
> > and now
> > 
> >    foo (Ascii @ ('X':rest)) =
> > 
> > is now longer as silly…
> 
> That’s a good example.  It's easy to work around:
> 
> 	pattern And p q = p at q
> 
> 	foo (Ascii `And` ('X' : rest)) = ..

nice. I included this in the proposal under “Costs and Drawbacks”, for
future reference.

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/20180816/d3100094/attachment.sig>

From eric at seidel.io  Thu Aug 16 23:47:29 2018
From: eric at seidel.io (Eric Seidel)
Date: Thu, 16 Aug 2018 19:47:29 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
Message-ID: <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>

It sounds like we all agree that the disagreement is mostly over terminology, specifically, over the definition of a type constructor. Richard prefers a definition that limits type constructors to producing objects of type Type (or Constraint), whereas I (and Iavor, I think) prefer a broader definition that encompasses any constructor that produces an object that can be used at the type-level. Richard points out, correctly, that when Dependent Haskell arrives, the value/type level distinction will disappear, and our definition will become (mostly) untenable. (I say mostly because, at least in my limited experience with dependent types, you often still have objects that are used primarily in a type context, and so an informal value/type distinction could still be useful.)

The question then is what to do in the meantime. Do we stick with the established terminology and incur a larger change when Dependent Haskell arrives, or do we start making preparations now? I think Richard's perspective makes sense for a dependently-typed language, but Haskell is not dependently-typed, yet. So I'm inclined to say the change of terminology should be deferred to the Dependent Haskell proposal. 

I know we generally operate on the silence-means-agreement principle, but this disagreement is over a pretty crucial definition, so I'd like to solicit feedback from the rest of the committee.

On Thu, Aug 16, 2018, at 06:02, Iavor Diatchki wrote:
> Hello,
> 
> I'd be happy to make changes to the text of the proposal, but I would like
> to understand the underlying concerns so that I can address them
> appropriately.   At the moment, I am pretty sure that I am missing
> something, as might be evident from my comments below.   Either way, my
> comments below are intended to shed some light on my thinking, and
> emphasize the parts of Richard's comments I don't understand.
> 
> On Wed, Aug 15, 2018 at 6:10 AM Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
> 
> >
> > - Types and kinds are simply the same now. There really is no difference.
> > So the first sentence of this proposal, "This proposal introduces a
> > language construct for defining kinds without having to promote types." is,
> > in my opinion, quite misleading.
> 
> 
> The proposal uses the same terminology that is used in GHC's manual, and
> also by the majority of the Haskell community.  For example, Section 10.1
> of the manual is about "Datatype Promotion", and the summary is "Allow
> promotion of data types to kind level.".  Section 10.10.2 says "With
> DataKinds, GHC automatically promotes every datatype to be a kind and its
> (value) constructors to be type constructors.".  This proposal introduces a
> language construct that allows us to declare non-empty kinds without having
> to promote a datatype in the sense of 10.1.  I am talking about the
> language specification, not the actual implementation, which we can discuss
> once we agree we'd like to have this new feature.
> 
> All `data` declarations introduce kinds (because they introduce types, and
> > types = kinds). And data constructors aren't really promoted either -- they
> > can simply be used in types.
> >
> 
> Of course this is technically correct, but without data type promotion
> these are empty kinds that are a side-effect of mixing up types and kinds.
> I say empty "kinds" rather than empty "types" to emphasize the fact that I
> am referring to the kinding relation, not the typing one.
> 
> 
> 
> > - The proposal talks about referring to types in export lists. But we can
> > already do this, via the normal syntax for listing data constructors with
> > type constructors. So I'm not sure what that point of motivation really
> > means.
> >
> 
> Here is a datatype declaration:
> 
> data T = A | B
> 
> In current GHC how would you export the type `A` of kind `T` without
> exporting the value `A` of type `T`?
> 
> Here is my attempt:
> 
> {-# Language DataKinds, ExplicitNamespaces #-}
> 
> module M (type A) where
> 
> data T = A | B
> 
> This results in:
> 
> error: Not in scope: type constructor or class ‘A’
>   |
> 3 | module M (type A) where
>   |           ^^^^^^
> 
> 
> - The "normal types win" is true, but it's all about namespace lookup. In a
> > type, when GHC sees a capitalized identifier, it looks in the type
> > namespace for that identifier. If the identifier is bound in the type
> > namespace, that identifier is found. If not, GHC looks in the data-level
> > namespace. According to this algorithm, "normal types win", indeed. But the
> > "normal"cy of the type is that it lives in the type namespace, not because
> > it isn't promoted.
> >
> 
> I think that with this proposal we have a much easier way to explain how
> things work, without having to refer to the algorithm used by GHC's renamer:
> 
> data T = A | B    -- T is a type, and A and B are values of this type
> type data S = X | Y -- S is a kind, and X and Y are types of this kind
> 
> Simple.
> 
> 
> > - If something introduced with `type data` can be used without
> > -XDataKinds, then what does -XDataKinds really mean? It would seem to
> > enable solely the extra data-level namespace check. That's fine with me,
> > but we should document it that way. Alternatively, -XDataKinds could mean
> > that some types have kinds that don't end in Type or Constraint, in which
> > case it would need to be enabled to use a `type data` data constructor.
> >
> 
> This proposal is orthogonal to `DataKinds` and does not change anything
> about how it works.
> 
> Personally, if I had `TypeData`, I think I would very rarely use
> `DataKinds`, except for type-level nats and symbols, which should probably
> get a separate extension anyway.  The reason is that I rarely need the same
> constructors at the value and the type level without any link between the
> two.
> 
> 
> > - The RHS of a `type data` does not introduce type constructors. A type
> > constructor constructs a type -- that is, if T is a type constructor, then
> > T applied to appropriate arguments has kind Type (or Constraint). But the
> > data constructors of `type data` really are data constructors. It just so
> > happens that their names live only in the type-level namespace. If we want,
> > we can call these "type-level data constructors", but I think "type
> > constructors" is misleading.
> >
> 
> I am sorry but I don't understand this at all---it is going contrary to the
> terminology used by the Haskell community for decades.  I really don't see
> why we need to invent new terms, and arbitrarily limit the term
> "type-constructor" to only types of kind `Type` or `Constraint`, especially
> if we are willing to refer to all "kinds" as "types".  The notion of
> classifying types by kinds and having a rich kind language is completely
> orthogonal to dependent types, and I think the current terminology works
> just fine.
> 
> If I am reading Richard's comments correctly (and I apologize if I am
> misunderstanding) his main concern is about terminology, based on his
> vision and plans about Dependent Haskell.  I am supportive of work in this
> area, but I don't think that this proposal is the right place to start
> changing the terminology.   I would suggest that we stick with the
> established language, which is widely used by the community, GHC's manual,
> and GHC's source code.  Once there is a design document for Dependent
> Haskell, we could discuss that and settle on appropriate terminology.
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> 
> > Thanks,
> > Richard
> >
> > > On Aug 14, 2018, at 8:31 PM, Eric Seidel <eric at seidel.io> wrote:
> > >
> > > Hi everyone!
> > >
> > > This proposal would allow the declaration of new kinds and type
> > constructors, without the associated data constructors that would have been
> > generated by -XDataKinds.
> > >
> > >
> > https://github.com/yav/ghc-proposals/blob/data-kind-only/proposals/0000-type-data.rst
> > >
> > > It introduces a new language extension, -XTypeData, which allows
> > declarations like the following:
> > >
> > >  type data Universe = Character | Number | Boolean
> > >
> > > This introduces a new kind, Universe, with three associated type
> > constructors
> > >
> > >  Character :: Universe
> > >  Number :: Universe
> > >  Boolean :: Universe
> > >
> > > Notably, no data constructors are introduced.
> > >
> > > The proposal aims to solve several usability issues with -XDataKinds:
> > >
> > > 1. We often don't want the data constructors, which simply pollute the
> > value namespace.
> > > 2. We cannot easily control the export behavior of promoted types
> > (instead we resort to tricks like the alias `type Character = 'Character`).
> > > 3. The name resolution rules involving promoted types can be confusing.
> > >
> > > I find these issues (particularly #2) compelling, and the community
> > response seems to be mostly positive, so I recommend accepting the
> > proposal.
> > >
> > > I'm not particularly fond of the proposed syntax (`type data` makes it
> > sound like we're doing something with data constructors, which is precisely
> > what we're NOT doing), but the proposal has already had a good bit of
> > bikeshedding, and people seem mostly happy with the current syntax, so I
> > think we should probably stick with `type data`.
> > >
> > > Eric
> > > _______________________________________________
> > > 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

From rae at cs.brynmawr.edu  Fri Aug 17 02:19:04 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 16 Aug 2018 22:19:04 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
Message-ID: <0E05C3D9-BA4C-4728-A441-22CE2D9472B0@cs.brynmawr.edu>

Iavor brings up some really good points here. He's right that I'm (mostly) arguing about terminology. At their core, I might summarize Iavor's points as follows:

* Should we change this terminology at all?
* If so, should we do so now?

Unsurprisingly, I wish to argue "yes" to both points.

First off, I recognize that I'm arguing against the Haskell grain right now, in that the terminology is well established. I had not considered the use of, say, "type constructor" in the manual. (In all this, I'm thinking solely of user-facing features, not at all the GHC implementation.) I did not acknowledge this in my first email in this thread.

Why change the terminology?

- The current terminology puts us out of step with the dependent types community. The features we're discussing (i.e., the ability to use `'True' as a type argument) exist only in Haskell and in dependently typed languages. It thus seems sensible to be in line with dependently typed languages in our terminology.

- Calling `'True` a type leads to confusion, because some people want to find some term whose type is `'True`, but such a thing cannot exist.

- Currently, we say that * is the "kind of types with values". But someone could reasonably ask whether Void has kind * -- after all, Void is inhabited by no values. (It is inhabited by `undefined`, but that's not a value.) So "kind of types with values" is a bit wrong. Perhaps better would be "kind of types inhabited by terms", but that's an even wordier mouthful. With the proposed change in terminology, we could just say that * is the kind of types. Simple! (Naturally, this works beautifully with *'s new name, Type.)

- It's conceptually simpler (to me), to think of `'True` and `True` as the same thing. In the new terminology, both are data constructors. Indeed, we can refer to them as being the same -- the ' is there because the two appear in different contexts and therefore must be spelled slightly differently (like we understand M.lookup and Map.lookup to be the same thing but with different import statements in scope). By describing the two as the same, we have better intuition around, e.g., export/import lists, where there would no longer be a desire to export/import the "type constructor" independently of the "data constructor".

- Right now, datatypes and data families have a restriction that their kinds end in `... -> *`. With the new terminology, we can just say these must be type constructors.

- GHC uses this terminology in a limited way in error messages. If you say `x :: 'True`, GHC says that True is expected to be a type. According to the "old" terminology, `'True` *is* a type, so this error message is misleading. Under the new terminology, it works just fine.

Reasons to keep the existing terminology:

- It's existing. This means that it's familiar to many and has been enshrined in written materials.

- Many find the type-leve/term-level distinction to be a convenient proxy for the compile-time/runtime distinction. In today's Haskell, this is accurate, though it would change with dependent types. However, my suggested change in terminology does not change this -- it just means that data constructors can be used at the type level.

We should also consider the timing of this change. Why do this now instead of waiting?

- The new terminology makes as good sense today as it will in a dependently typed future. Even if the development toward dependent types stops, this change is worthwhile for the reasons above, none of which appeal to any features that do not already exist.

- The right time for any change of this sort is "yesterday". But seeing as we can't do that, let's do "today", the next best thing.

Essentially, my argument here is that we got this all slightly wrong when -XDataKinds came into being -- not the feature, but the way we describe it. Perhaps this is all just much ado about little, but I do think this small change in how we speak of these features will help Haskellers learn how they work with the right set of intuitions.

(I would like to note that my arguments here are borne of experience. I was not part of the initial wave of design of -XDataKinds, but if I had been, I'm sure I would have gone with what I'm calling the "old" terminology.)

Thanks,
Richard

> On Aug 16, 2018, at 6:02 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello,
> 
> I'd be happy to make changes to the text of the proposal, but I would like to understand the underlying concerns so that I can address them appropriately.   At the moment, I am pretty sure that I am missing something, as might be evident from my comments below.   Either way, my comments below are intended to shed some light on my thinking, and emphasize the parts of Richard's comments I don't understand.
> 
> On Wed, Aug 15, 2018 at 6:10 AM Richard Eisenberg <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> wrote:
> 
> - Types and kinds are simply the same now. There really is no difference. So the first sentence of this proposal, "This proposal introduces a language construct for defining kinds without having to promote types." is, in my opinion, quite misleading.
>  
> The proposal uses the same terminology that is used in GHC's manual, and also by the majority of the Haskell community.  For example, Section 10.1 of the manual is about "Datatype Promotion", and the summary is "Allow promotion of data types to kind level.".  Section 10.10.2 says "With DataKinds, GHC automatically promotes every datatype to be a kind and its (value) constructors to be type constructors.".  This proposal introduces a language construct that allows us to declare non-empty kinds without having to promote a datatype in the sense of 10.1.  I am talking about the language specification, not the actual implementation, which we can discuss once we agree we'd like to have this new feature.
> 
> All `data` declarations introduce kinds (because they introduce types, and types = kinds). And data constructors aren't really promoted either -- they can simply be used in types.
> 
> Of course this is technically correct, but without data type promotion these are empty kinds that are a side-effect of mixing up types and kinds.  I say empty "kinds" rather than empty "types" to emphasize the fact that I am referring to the kinding relation, not the typing one.
> 
>  
> - The proposal talks about referring to types in export lists. But we can already do this, via the normal syntax for listing data constructors with type constructors. So I'm not sure what that point of motivation really means.
> 
> Here is a datatype declaration:
> 
> data T = A | B
> 
> In current GHC how would you export the type `A` of kind `T` without exporting the value `A` of type `T`?
> 
> Here is my attempt:
> 
> {-# Language DataKinds, ExplicitNamespaces #-}
>   
> module M (type A) where
> 
> data T = A | B
> 
> This results in:
> 
> error: Not in scope: type constructor or class ‘A’
>   |
> 3 | module M (type A) where
>   |           ^^^^^^
> 
> 
> - The "normal types win" is true, but it's all about namespace lookup. In a type, when GHC sees a capitalized identifier, it looks in the type namespace for that identifier. If the identifier is bound in the type namespace, that identifier is found. If not, GHC looks in the data-level namespace. According to this algorithm, "normal types win", indeed. But the "normal"cy of the type is that it lives in the type namespace, not because it isn't promoted.
> 
> I think that with this proposal we have a much easier way to explain how things work, without having to refer to the algorithm used by GHC's renamer:
> 
> data T = A | B    -- T is a type, and A and B are values of this type
> type data S = X | Y -- S is a kind, and X and Y are types of this kind
> 
> Simple.
>  
> - If something introduced with `type data` can be used without -XDataKinds, then what does -XDataKinds really mean? It would seem to enable solely the extra data-level namespace check. That's fine with me, but we should document it that way. Alternatively, -XDataKinds could mean that some types have kinds that don't end in Type or Constraint, in which case it would need to be enabled to use a `type data` data constructor.
> 
> This proposal is orthogonal to `DataKinds` and does not change anything about how it works.  
> 
> Personally, if I had `TypeData`, I think I would very rarely use `DataKinds`, except for type-level nats and symbols, which should probably get a separate extension anyway.  The reason is that I rarely need the same constructors at the value and the type level without any link between the two.
>  
> - The RHS of a `type data` does not introduce type constructors. A type constructor constructs a type -- that is, if T is a type constructor, then T applied to appropriate arguments has kind Type (or Constraint). But the data constructors of `type data` really are data constructors. It just so happens that their names live only in the type-level namespace. If we want, we can call these "type-level data constructors", but I think "type constructors" is misleading.
> 
> I am sorry but I don't understand this at all---it is going contrary to the terminology used by the Haskell community for decades.  I really don't see why we need to invent new terms, and arbitrarily limit the term "type-constructor" to only types of kind `Type` or `Constraint`, especially if we are willing to refer to all "kinds" as "types".  The notion of classifying types by kinds and having a rich kind language is completely orthogonal to dependent types, and I think the current terminology works just fine.
> 
> If I am reading Richard's comments correctly (and I apologize if I am misunderstanding) his main concern is about terminology, based on his vision and plans about Dependent Haskell.  I am supportive of work in this area, but I don't think that this proposal is the right place to start changing the terminology.   I would suggest that we stick with the established language, which is widely used by the community, GHC's manual, and GHC's source code.  Once there is a design document for Dependent Haskell, we could discuss that and settle on appropriate terminology.
> 
> -Iavor
> 
> 
> 
> 
> 
>  
> Thanks,
> Richard
> 
> > On Aug 14, 2018, at 8:31 PM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> > 
> > Hi everyone!
> > 
> > This proposal would allow the declaration of new kinds and type constructors, without the associated data constructors that would have been generated by -XDataKinds.
> > 
> > https://github.com/yav/ghc-proposals/blob/data-kind-only/proposals/0000-type-data.rst <https://github.com/yav/ghc-proposals/blob/data-kind-only/proposals/0000-type-data.rst>
> > 
> > It introduces a new language extension, -XTypeData, which allows declarations like the following:
> > 
> >  type data Universe = Character | Number | Boolean
> > 
> > This introduces a new kind, Universe, with three associated type constructors
> > 
> >  Character :: Universe
> >  Number :: Universe
> >  Boolean :: Universe
> > 
> > Notably, no data constructors are introduced.
> > 
> > The proposal aims to solve several usability issues with -XDataKinds:
> > 
> > 1. We often don't want the data constructors, which simply pollute the value namespace.
> > 2. We cannot easily control the export behavior of promoted types (instead we resort to tricks like the alias `type Character = 'Character`).
> > 3. The name resolution rules involving promoted types can be confusing.
> > 
> > I find these issues (particularly #2) compelling, and the community response seems to be mostly positive, so I recommend accepting the proposal. 
> > 
> > I'm not particularly fond of the proposed syntax (`type data` makes it sound like we're doing something with data constructors, which is precisely what we're NOT doing), but the proposal has already had a good bit of bikeshedding, and people seem mostly happy with the current syntax, so I think we should probably stick with `type data`.
> > 
> > Eric
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180816/5491b8c8/attachment-0001.html>

From rae at cs.brynmawr.edu  Fri Aug 17 02:28:43 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 16 Aug 2018 22:28:43 -0400
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
Message-ID: <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>

I hate to throw a wrinkle in, but much of this discussion assumes that type arguments come before other arguments after a constructor. This is true today, and there are no immediate plans to change it, but this assumption won't be valid if we have full dependent types. For example, we might want something like

> data T where
>   MkT :: forall k -> Int -> forall (a :: k). TypeRep a -> T

Now, we might get patterns like

> foo (MkT k n @a r) = ...

Without whitespace-sensitivity, I don't think we'll be able to disambiguate between type pattern and as-pattern. (I thought for a moment that we could use the constructor arity as a guide, but this fails if we have two @-signs, where only one is meant to be a type pattern. We won't be able to tell which one!)

Whitespace-sensitivity is bad, but it's not unprecedented in Haskell. Ignoring the layout rule (which is quite different), this is much more like the treatment of `.` and `$`. Specifically, `T . f` is T composed with f, while `T.f` is the name `f` from the module `T`. And `f $ (g x)` is f applied to (g x) while `f $(g x)` is f applied to a splice.

Considering this future of relaxed ordering requirements on data constructors isn't compulsory, but I do think it's better if we don't paint ourselves into a corner around this.

Thanks,
Richard

> On Aug 16, 2018, at 7:27 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Donnerstag, den 16.08.2018, 23:22 +0000 schrieb Simon Peyton Jones:
>>>   pattern Ascii :: String
>>>   pattern Ascii <- (all isAscii -> True)
>>> 
>>> and now
>>> 
>>>   foo (Ascii @ ('X':rest)) =
>>> 
>>> is now longer as silly…
>> 
>> That’s a good example.  It's easy to work around:
>> 
>> 	pattern And p q = p at q
>> 
>> 	foo (Ascii `And` ('X' : rest)) = ..
> 
> nice. I included this in the proposal under “Costs and Drawbacks”, for
> future reference.
> 
> 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  Fri Aug 17 05:37:54 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 16 Aug 2018 22:37:54 -0700
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
 <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>
Message-ID: <e35a1d78c27cb0a74c4a5603c3f674583939c41e.camel@joachim-breitner.de>

Hi Richard,

Am Donnerstag, den 16.08.2018, 22:28 -0400 schrieb Richard Eisenberg:
> Considering this future of relaxed ordering requirements on data
> constructors isn't compulsory, but I do think it's better if we don't
> paint ourselves into a corner around this.

I agree.

But so what do we do? Already now require that there is no space
between @ and the following token when the user wants to use type
applications in the pattern?

And would we also require the user to add a space after an at-pattern?
In which case we should probably start a deprecation cycle for the
currently legal

   foo (a @b) = …


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/20180816/ce8cd1f9/attachment.sig>

From eric at seidel.io  Fri Aug 17 06:37:19 2018
From: eric at seidel.io (Eric Seidel)
Date: Fri, 17 Aug 2018 02:37:19 -0400
Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn
 on unbanged strict patterns (#35); Recommendation: Reject
In-Reply-To: <AM0PR83MB030892D4A17DA41D292C4CF3AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <CALpVSmOrzO=EAa=aYxHqwZyj-QFzXKg_8HcF42GJFu1c03iT7w@mail.gmail.com>
 <AM0PR83MB030892D4A17DA41D292C4CF3AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <1534487839.3486.1477078640.2EB260DD@webmail.messagingengine.com>

I think the reason is more that it's a change that doesn't seem to be well-motivated, i.e. neither the proposal nor the discussion offer a compelling example where you would want an unboxed tuple to be matched lazily.

That being said, I overlooked the implicit-bang alternative when I first read the proposal. That seems quite reasonable. The default behavior remains what people seem to expect, but enables the explicit use of lazy patterns should you want them.

On Thu, Aug 16, 2018, at 03:38, Simon Peyton Jones via ghc-steering-committee wrote:
> I’m actually mildly in favour of the proposed design.
> 
> The main reason for rejection is really
> 
> * It’s a change
> 
> Change is always a bit disruptive; and no one is arguing strongly that 
> they really really want this.
> 
> So maybe we should just “park” it as OK in principle, but without 
> sufficient support to justify the (hard to quantify) changeover costs.
> 
> Simon
> 
> From: ghc-steering-committee <ghc-steering-committee-
> bounces at haskell.org> On Behalf Of Vitaly Bragilevsky
> Sent: 16 August 2018 01:37
> To: ghc-steering-committee at haskell.org
> Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn 
> on unbanged strict patterns (#35); Recommendation: Reject
> 
> Hi,
> 
> the lazy unboxed tuples proposal  
> (https://github.com/ghc-proposals/ghc-proposals/pull/35<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F35&data=02%7C01%7Csimonpj%40microsoft.com%7C983115e9eee64eb4b03c08d603107655%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636699766583676606&sdata=PXTsCrM4otm8ZCEFZvNfkydSBo6J77zh5qb9CVNmZX8%3D&reserved=0>) 
> was under discussion for a long period of time (more than a year and a 
> half since submission).
> 
> As a shepherd to this proposal I recommend rejection based on the following:
> 
> * there is no clearly articulated motivation in favor of this proposal 
> despite complying with the Manual;
> * implementing this would lead to hard-to-trace performance issues in 
> the users code (due to move from strictness in current GHC behaviour to 
> laziness);
> * it looks like the change (B) of the proposal (warn an unbanged strict 
> patterns) meets no complains, so it is better to be resubmitted as a 
> separate proposal;
> * if resubmitted separately the change (A) should elaborate on 
> desugaring to make potential performance drawbacks clear;
> * it seems (maybe mistakenly) that the author has lost his interest in 
> this proposal.
> 
> Although silence is undestood as agreement, I'd be glad to receive a 
> feedback on this recommendation.
> 
> Regards,
> Vitaly
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From simonpj at microsoft.com  Fri Aug 17 07:22:45 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 17 Aug 2018 07:22:45 +0000
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
Message-ID: <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

|  I know we generally operate on the silence-means-agreement principle, but
|  this disagreement is over a pretty crucial definition, so I'd like to
|  solicit feedback from the rest of the committee.

Can you restate the terminological choice(s) as explicitly as possible, with examples?

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
|  Behalf Of Eric Seidel
|  Sent: 17 August 2018 00:47
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Proposal: Define Kinds Without
|  Promotion (#106)
|  
|  It sounds like we all agree that the disagreement is mostly over
|  terminology, specifically, over the definition of a type constructor.
|  Richard prefers a definition that limits type constructors to producing
|  objects of type Type (or Constraint), whereas I (and Iavor, I think) prefer
|  a broader definition that encompasses any constructor that produces an
|  object that can be used at the type-level. Richard points out, correctly,
|  that when Dependent Haskell arrives, the value/type level distinction will
|  disappear, and our definition will become (mostly) untenable. (I say mostly
|  because, at least in my limited experience with dependent types, you often
|  still have objects that are used primarily in a type context, and so an
|  informal value/type distinction could still be useful.)
|  
|  The question then is what to do in the meantime. Do we stick with the
|  established terminology and incur a larger change when Dependent Haskell
|  arrives, or do we start making preparations now? I think Richard's
|  perspective makes sense for a dependently-typed language, but Haskell is not
|  dependently-typed, yet. So I'm inclined to say the change of terminology
|  should be deferred to the Dependent Haskell proposal.
|  
|  I know we generally operate on the silence-means-agreement principle, but
|  this disagreement is over a pretty crucial definition, so I'd like to
|  solicit feedback from the rest of the committee.
|  
|  On Thu, Aug 16, 2018, at 06:02, Iavor Diatchki wrote:
|  > Hello,
|  >
|  > I'd be happy to make changes to the text of the proposal, but I would
|  > like to understand the underlying concerns so that I can address them
|  > appropriately.   At the moment, I am pretty sure that I am missing
|  > something, as might be evident from my comments below.   Either way, my
|  > comments below are intended to shed some light on my thinking, and
|  > emphasize the parts of Richard's comments I don't understand.
|  >
|  > On Wed, Aug 15, 2018 at 6:10 AM Richard Eisenberg
|  > <rae at cs.brynmawr.edu>
|  > wrote:
|  >
|  > >
|  > > - Types and kinds are simply the same now. There really is no
|  difference.
|  > > So the first sentence of this proposal, "This proposal introduces a
|  > > language construct for defining kinds without having to promote
|  > > types." is, in my opinion, quite misleading.
|  >
|  >
|  > The proposal uses the same terminology that is used in GHC's manual,
|  > and also by the majority of the Haskell community.  For example,
|  > Section 10.1 of the manual is about "Datatype Promotion", and the
|  > summary is "Allow promotion of data types to kind level.".  Section
|  > 10.10.2 says "With DataKinds, GHC automatically promotes every
|  > datatype to be a kind and its
|  > (value) constructors to be type constructors.".  This proposal
|  > introduces a language construct that allows us to declare non-empty
|  > kinds without having to promote a datatype in the sense of 10.1.  I am
|  > talking about the language specification, not the actual
|  > implementation, which we can discuss once we agree we'd like to have this
|  new feature.
|  >
|  > All `data` declarations introduce kinds (because they introduce types,
|  > and
|  > > types = kinds). And data constructors aren't really promoted either
|  > > -- they can simply be used in types.
|  > >
|  >
|  > Of course this is technically correct, but without data type promotion
|  > these are empty kinds that are a side-effect of mixing up types and kinds.
|  > I say empty "kinds" rather than empty "types" to emphasize the fact
|  > that I am referring to the kinding relation, not the typing one.
|  >
|  >
|  >
|  > > - The proposal talks about referring to types in export lists. But
|  > > we can already do this, via the normal syntax for listing data
|  > > constructors with type constructors. So I'm not sure what that point
|  > > of motivation really means.
|  > >
|  >
|  > Here is a datatype declaration:
|  >
|  > data T = A | B
|  >
|  > In current GHC how would you export the type `A` of kind `T` without
|  > exporting the value `A` of type `T`?
|  >
|  > Here is my attempt:
|  >
|  > {-# Language DataKinds, ExplicitNamespaces #-}
|  >
|  > module M (type A) where
|  >
|  > data T = A | B
|  >
|  > This results in:
|  >
|  > error: Not in scope: type constructor or class ‘A’
|  >   |
|  > 3 | module M (type A) where
|  >   |           ^^^^^^
|  >
|  >
|  > - The "normal types win" is true, but it's all about namespace lookup.
|  > In a
|  > > type, when GHC sees a capitalized identifier, it looks in the type
|  > > namespace for that identifier. If the identifier is bound in the
|  > > type namespace, that identifier is found. If not, GHC looks in the
|  > > data-level namespace. According to this algorithm, "normal types
|  > > win", indeed. But the "normal"cy of the type is that it lives in the
|  > > type namespace, not because it isn't promoted.
|  > >
|  >
|  > I think that with this proposal we have a much easier way to explain
|  > how things work, without having to refer to the algorithm used by GHC's
|  renamer:
|  >
|  > data T = A | B    -- T is a type, and A and B are values of this type
|  > type data S = X | Y -- S is a kind, and X and Y are types of this kind
|  >
|  > Simple.
|  >
|  >
|  > > - If something introduced with `type data` can be used without
|  > > -XDataKinds, then what does -XDataKinds really mean? It would seem
|  > > to enable solely the extra data-level namespace check. That's fine
|  > > with me, but we should document it that way. Alternatively,
|  > > -XDataKinds could mean that some types have kinds that don't end in
|  > > Type or Constraint, in which case it would need to be enabled to use a
|  `type data` data constructor.
|  > >
|  >
|  > This proposal is orthogonal to `DataKinds` and does not change
|  > anything about how it works.
|  >
|  > Personally, if I had `TypeData`, I think I would very rarely use
|  > `DataKinds`, except for type-level nats and symbols, which should
|  > probably get a separate extension anyway.  The reason is that I rarely
|  > need the same constructors at the value and the type level without any
|  > link between the two.
|  >
|  >
|  > > - The RHS of a `type data` does not introduce type constructors. A
|  > > type constructor constructs a type -- that is, if T is a type
|  > > constructor, then T applied to appropriate arguments has kind Type
|  > > (or Constraint). But the data constructors of `type data` really are
|  > > data constructors. It just so happens that their names live only in
|  > > the type-level namespace. If we want, we can call these "type-level
|  > > data constructors", but I think "type constructors" is misleading.
|  > >
|  >
|  > I am sorry but I don't understand this at all---it is going contrary
|  > to the terminology used by the Haskell community for decades.  I
|  > really don't see why we need to invent new terms, and arbitrarily
|  > limit the term "type-constructor" to only types of kind `Type` or
|  > `Constraint`, especially if we are willing to refer to all "kinds" as
|  > "types".  The notion of classifying types by kinds and having a rich
|  > kind language is completely orthogonal to dependent types, and I think
|  > the current terminology works just fine.
|  >
|  > If I am reading Richard's comments correctly (and I apologize if I am
|  > misunderstanding) his main concern is about terminology, based on his
|  > vision and plans about Dependent Haskell.  I am supportive of work in
|  > this area, but I don't think that this proposal is the right place to
|  start
|  > changing the terminology.   I would suggest that we stick with the
|  > established language, which is widely used by the community, GHC's
|  > manual, and GHC's source code.  Once there is a design document for
|  > Dependent Haskell, we could discuss that and settle on appropriate
|  terminology.
|  >
|  > -Iavor
|  >
|  >
|  >
|  >
|  >
|  >
|  >
|  > > Thanks,
|  > > Richard
|  > >
|  > > > On Aug 14, 2018, at 8:31 PM, Eric Seidel <eric at seidel.io> wrote:
|  > > >
|  > > > Hi everyone!
|  > > >
|  > > > This proposal would allow the declaration of new kinds and type
|  > > constructors, without the associated data constructors that would
|  > > have been generated by -XDataKinds.
|  > > >
|  > > >
|  > > https://github.com/yav/ghc-proposals/blob/data-kind-only/proposals/0
|  > > 000-type-data.rst
|  > > >
|  > > > It introduces a new language extension, -XTypeData, which allows
|  > > declarations like the following:
|  > > >
|  > > >  type data Universe = Character | Number | Boolean
|  > > >
|  > > > This introduces a new kind, Universe, with three associated type
|  > > constructors
|  > > >
|  > > >  Character :: Universe
|  > > >  Number :: Universe
|  > > >  Boolean :: Universe
|  > > >
|  > > > Notably, no data constructors are introduced.
|  > > >
|  > > > The proposal aims to solve several usability issues with -XDataKinds:
|  > > >
|  > > > 1. We often don't want the data constructors, which simply pollute
|  > > > the
|  > > value namespace.
|  > > > 2. We cannot easily control the export behavior of promoted types
|  > > (instead we resort to tricks like the alias `type Character =
|  'Character`).
|  > > > 3. The name resolution rules involving promoted types can be
|  confusing.
|  > > >
|  > > > I find these issues (particularly #2) compelling, and the
|  > > > community
|  > > response seems to be mostly positive, so I recommend accepting the
|  > > proposal.
|  > > >
|  > > > I'm not particularly fond of the proposed syntax (`type data`
|  > > > makes it
|  > > sound like we're doing something with data constructors, which is
|  > > precisely what we're NOT doing), but the proposal has already had a
|  > > good bit of bikeshedding, and people seem mostly happy with the
|  > > current syntax, so I think we should probably stick with `type data`.
|  > > >
|  > > > Eric
|  > > > _______________________________________________
|  > > > ghc-steering-committee mailing list
|  > > > ghc-steering-committee at haskell.org
|  > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-com
|  > > > mittee
|  > >
|  > > _______________________________________________
|  > > ghc-steering-committee mailing list
|  > > ghc-steering-committee at haskell.org
|  > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commi
|  > > ttee
|  > >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ
|  > ee
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From simonpj at microsoft.com  Fri Aug 17 10:06:11 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 17 Aug 2018 10:06:11 +0000
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <1534299393.4019762.1474430160.1C2499EB@webmail.messagingengine.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
 <1534299393.4019762.1474430160.1C2499EB@webmail.messagingengine.com>
Message-ID: <AM0PR83MB03080C92E78672259DCA10B3AD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Reasonable questions -- maybe put them on the GitHub thread so that Arnaud can respond.

|  2. Am I correct in understanding that the only way to guarantee resource
|  safety in this proposal is to write all allocation functions in CPS with a
|  linear continuation? If so, this seems to be a substantial divergence from
|  the intuitive notion of type safety.

It's more modular than that.  In the paper we give the API for mutable arrays.  Yes, the ability to do in-place update on those arrays depends on that API; the type system along does not guarantee it.  It's the type system plus the API.   But its guarantees do not depend on *other* allocators.

|  The linearity-in-the-kind and uniqueness
|  alternatives (I don't quite understand the difference) seem better in this
|  respect; I want ALL sockets/handles/MArrays/etc to be linear.

These all have big problems too.  It's a big fork in the road; our paper takes one fork.  Maybe there are better paths.  But none that I have seen.

The challenge is that we don't know a Best Way with certainty (yet anyway).  But it's worth trying out at least One Way.  If someone else has a well-worked out alternative design, let's discuss that too.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
|  Behalf Of Eric Seidel
|  Sent: 15 August 2018 03:17
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types
|  
|  I also have a few concerns about the proposal.
|  
|  1. The proposal suggests making all data constructors linear when -
|  XLinearTypes is disabled. Can we guarantee that this will not cause
|  multiplicities to leak into type errors where -XLinearTypes is disabled? The
|  proposal doesn't say, and Richard seems to think not based on his email
|  above. I can understand having to deal with linearity if I've imported
|  modules that use -XLinearTypes, but not if I just use types that were
|  silently inferred to be linear. -XLinearTypes ought to be opt-in.
|  
|  2. Am I correct in understanding that the only way to guarantee resource
|  safety in this proposal is to write all allocation functions in CPS with a
|  linear continuation? If so, this seems to be a substantial divergence from
|  the intuitive notion of type safety. I don't have to worry about my API
|  design to ensure my program won't segfault, GHC guarantees that for me (and
|  we give the inevitable escape hatches scary names). Similarly, I think users
|  will expect GHC to prevent them from writing programs that misuse resources,
|  but this guarantee is only provided if the API is designed correctly, ie
|  with CPS'd allocators. We don't generally think of type safety as being
|  conditional on API design. The linearity-in-the-kind and uniqueness
|  alternatives (I don't quite understand the difference) seem better in this
|  respect; I want ALL sockets/handles/MArrays/etc to be linear.
|  
|  I wonder if we could somehow take advantage of the fact that allocators are
|  already implicitly CPS'd (as monadic functions) to allow users to write code
|  in the natural style while retaining the linear guarantees?
|  
|  On Tue, Aug 7, 2018, at 01:50, Iavor Diatchki wrote:
|  > Hello,
|  >
|  > I am not sure that the amount of effort that went into writing a
|  > proposal should be a deciding factor about if the proposal is
|  > accepted.  We don't want to discourage folks, but also, once things
|  > get into GHC they are hard to get out, so I think caution is warranted.
|  >
|  > I find this proposal to be constructed rather poorly.  I read the
|  > previous version, and I also read this one, and I find it to be a
|  > rather small improvement, if at all.  For a relatively complex
|  > proposal change, the proposal had hardly any examples.  To me, it read
|  > as a patchwork of paragraphs, that are an uneasy mix of informal
|  > explanations with no examples, overly formal explanations, potential
|  > things one might use this for (RIO??), and what seem to be answers to
|  > questions from the GitHub discussion, which are just perplexing if you
|  > read the proposal before the discussion.
|  >
|  > This makes it quite hard to grasp the main idea.  Having said that I
|  > think I get what is being proposed and I like parts of it.
|  >
|  > The main high level concern I have is the overloading of the function
|  > space arrow.  We already have it overloaded in all kinds of ways, and
|  > adding one more dimension without any kind of underlying system seems
|  > too much.  I am not at all convinced that we will be able to "hide"
|  > multiplicities when the extension is not enabled.
|  >
|  > Overall, while I like the core ideas, I would prefer a different way
|  > of integrating them into Haskell, one that is more modular, even at
|  > the cost of having to duplicate some code.  My reasoning is that while
|  > linearity might be useful in some cases, most of the time it is not
|  > something that we'd care about much, so we should not add it (at least
|  > straight away) to the core part of the language (functions and data
|  types).
|  >
|  > -Iavor
|  >
|  >
|  > On Fri, Aug 3, 2018, 1:41 AM Richard Eisenberg <rae at cs.brynmawr.edu>
|  wrote:
|  >
|  > > Conversation seems to have died down on this trail, both on GitHub
|  > > and here in committee. As the shepherd, it's my job to kick us back into
|  action.
|  > >
|  > > After much conversation on GitHub, there are still a few dangling
|  > > loose ends to this proposal:
|  > >
|  > > - The proposal defined *consume exactly once*, but I don't that
|  > > definition is fully correct and it's not general enough. For
|  > > example, it doesn't treat abstract types or unboxed ones. Simon has
|  > > suggested that it's meant purely for intuition (for which it works
|  > > well) but is not meant to be a technical specification. The other
|  > > proposal authors seem to disagree with this, but I'm yet to be satisfied
|  by an attempt at defining this.
|  > >
|  > > - The proposal says nothing on the subject of type inference. This
|  > > is understandable, because it's really hard to know what will work best.
|  > > However, there has not yet been a commitment that type inference
|  > > will be backward-compatible. The authors want the presence/absence
|  > > of -XLinearTypes not to affect type inference, and they also want
|  > > sometimes to infer linear types. I think these, together, imply that
|  > > the proposal isn't fully backward compatible. See
|  > > https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment
|  > > -406723478
|  > >
|  > > - The proposal mentions the idea of unification of multiplicities up
|  > > to semiring equalities, but then the authors claim that such a
|  > > procedure is undecidable. It's unclear where this stands.
|  > >
|  > > - There is no design that will stop Haskell learners from seeing
|  > > linear types in error messages, though it appears they won't appear with
|  :type.
|  > >
|  > > - Simon M has pushed on the motivations of the proposal, trying to
|  > > understand better exactly what problems this proposal solves. I have
|  > > not followed this sub-thread terribly closely, and will take
|  > > advantage of the fact that Simon is on this committee and can speak
|  > > for himself on these issues.
|  > >
|  > > Despite these dangling pieces, I do think they all can be resolved.
|  > > (Except perhaps the motivation piece if it's problematic enough.) I
|  > > thus recommend that we officially encourage this proposal on the
|  > > road toward acceptance. This recommendation is based on the
|  > > excitement in the community around linear types and the high degree
|  > > of effort and commitment the authors have shown.
|  > >
|  > > If you disagree with this recommendation, please speak up. As usual,
|  > > I will take silence as agreement and make an official pronouncement
|  > > to the authors in due course.
|  > >
|  > > Thanks,
|  > > Richard
|  > >
|  > > On Jul 8, 2018, at 11:41 PM, 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 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-commi
|  > > ttee
|  > >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ
|  > ee
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From simonpj at microsoft.com  Fri Aug 17 11:19:40 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 17 Aug 2018 11:19:40 +0000
Subject: [ghc-steering-committee] Proposal: Syntax for visible dependent
 quantification (#81)
In-Reply-To: <CAADqg9YVMk6PTD71RRc4RXCVK3-vQagE1tHjmBMjnnKM=edXXA@mail.gmail.com>
References: <CAADqg9bZktCwGik=4G9DJh0jb5VDPrWdSPE1U4_C4MXZoHmHbw@mail.gmail.com>
 <30B357D6-E03C-4A03-8D6C-F5BF22BF0E13@cs.brynmawr.edu>
 <88AAAB4F-4C45-43EF-B4A4-D095982FCBDF@cs.brynmawr.edu>
 <4704D092-353A-4113-9B2F-482FD3F7D1AF@cs.brynmawr.edu>
 <52a0e1ee2494f5514ddda0984b31844dcf7b76a2.camel@joachim-breitner.de>
 <CAADqg9YVMk6PTD71RRc4RXCVK3-vQagE1tHjmBMjnnKM=edXXA@mail.gmail.com>
Message-ID: <AM6PR83MB03091F9BCDE148C251DB6303AD3D0@AM6PR83MB0309.EURPRD83.prod.outlook.com>

I support this #81.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Roman Leshchinskiy
Sent: 09 August 2018 19:44
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Proposal: Syntax for visible dependent quantification (#81)

Sorry for the long delay. Given that the general feedback is positive and #102 is now available, I recommend that we accept #81.

Thanks,

Roman

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

indeed, we should make progress here. Roman, with #102 discussed
(albeit not decided), what is your recommendation about #81?

Cheers,
Joachim

Am Sonntag, den 15.04.2018, 23:09 -0400 schrieb Richard Eisenberg:
> Hi committee,
>
> I'd like to reboot this discussion, now that #102 has been written, debated, and tabled. As a reminder, this proposal is blocking #54, which will cure real bugs GHC is plagued by.
>
> Thanks!
> Richard
>
> > On Jan 5, 2018, at 8:37 PM, Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
> >
> > OK. I've posted proposal #102 (https://github.com/goldfirere/ghc-proposals/blob/pi/proposals/0000-pi.rst<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fpi%2Fproposals%2F0000-pi.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C3ccaf4dae6074e10d27808d5fe281cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636694370599807360&sdata=lieSdDGUo7Pts%2F%2FIaWKAHPXnMF8OseDu5GGyy0iMYo8%3D&reserved=0>) which describes the full set of quantifiers for Dependent Haskell.
> >
> > I continue to think that #81 can stand alone, but those who want a larger picture can see #102 for that larger picture.
> >
> > Thanks,
> > Richard
> >
> > > On Dec 21, 2017, at 9:15 AM, Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
> > >
> > > These are good suggestions. Thanks. While I'm writing all these proposals, it's about time I introduce pi proper -- the proposal for pi can go further than reserve syntax, because there are already places in the language that support real pi-types (the kinds of type families [assuming #54 is accepted] and the kinds of datatypes).
> > >
> > > I'll put together yet another proposal. :)
> > >
> > > Regardless, I don't want to shut down debate on this proposal in isolation. In particular, I'd love new syntax suggestions, as I agree that the proposed syntax is a little subtle.
> > >
> > > Thanks,
> > > Richard
> > >
> > > > On Dec 20, 2017, at 3:35 PM, Roman Leshchinskiy <rleshchinskiy at gmail.com<mailto:rleshchinskiy at gmail.com>> wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > The proposal is about adding support for dependent quantification to
> > > > kind signatures:
> > > >
> > > > https://github.com/ghc-proposals/ghc-proposals/pull/81<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F81&data=02%7C01%7Csimonpj%40microsoft.com%7C3ccaf4dae6074e10d27808d5fe281cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636694370599807360&sdata=VAlKyMTnw%2BywQ46AEhOgAhEsRLU7TagmS9Winqjwnlw%3D&reserved=0>
> > > >
> > > > Consider the following declaration (example lifted from the proposal):
> > > >
> > > > data T k (a :: k)
> > > >
> > > > GHC accepts this but it can't be given an explicit kind. Internally,
> > > > it is assigned a kind which is rendered as
> > > >
> > > > forall k -> k -> *
> > > >
> > > > but this isn't accepted in source code. Note that in applications of
> > > > T, k must be specified explicitly (e.g., T Type Int) which is why T
> > > > does *not* have the kind
> > > >
> > > > forall k. k -> *
> > > >
> > > > Moreover, k is mentioned later in the kind which is why something like
> > > > Type -> k -> * doesn't work, either.
> > > >
> > > > The proposal is to allow forall k -> k -> * and similar kinds to
> > > > appear in source code.
> > > >
> > > > This is actually intended as the first in a series of proposals
> > > > driving us towards dependent types in Haskell as described in
> > > > Richard's thesis
> > > > (https://www.cis.upenn.edu/~sweirich/papers/eisenberg-thesis.pdf<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.cis.upenn.edu%2F~sweirich%2Fpapers%2Feisenberg-thesis.pdf&data=02%7C01%7Csimonpj%40microsoft.com%7C3ccaf4dae6074e10d27808d5fe281cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636694370599817364&sdata=b3y9GWTM8Q0DbYxtx4XspKx%2BrR1qbCYbdtRj%2BSjONdY%3D&reserved=0>).
> > > > Ultimately, the intention is to have all of the following (cf. Chapter
> > > > 4 of the thesis):
> > > >
> > > > forall a. t
> > > > forall a -> t
> > > > pi a. t
> > > > pi a -> t
> > > >
> > > > Here, forall and pi express relevance (does it exist at runtime) and .
> > > > and -> express visibility (does it have to be specified explicitly).
> > > >
> > > > Because of this, my recommendation is to strongly encourage the author
> > > > to submit an extended proposal which reserves (but doesn't specify the
> > > > semantics of) the above syntax wholesale.
> > > >
> > > > This would allow us to ensure that various bits of Dependent Haskell
> > > > use consistent syntax and language extensions once implemented. I find
> > > > it quite difficult to discuss just this specific bit of syntax in
> > > > isolation. Indeed, the public discussion was rather confused without
> > > > an explanation of the roadmap
> > > > (https://github.com/ghc-proposals/ghc-proposals/pull/81#issuecomment-336892922<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F81%23issuecomment-336892922&data=02%7C01%7Csimonpj%40microsoft.com%7C3ccaf4dae6074e10d27808d5fe281cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636694370599817364&sdata=%2Ft0UNHhKAyPJRDifK1q31Fpc2LNWfuTyl3PCUIHourI%3D&reserved=0>).
> > > >
> > > > Alternatively, we could just agree on the roadmap ourselves, without
> > > > public discussion. This would somewhat circumvent the process, though.
> > > >
> > > > If we decide to discuss just the proposal as is, though, then I'd be
> > > > weakly against the proposed syntax as it is too subtle for my taste
> > > > and abuses familiar mathematical notation somewhat. I'd probably
> > > > prefer something like:
> > > >
> > > > type a -> t
> > > >
> > > > The proposal also doesn't specify what language extension would turn
> > > > on support for the syntax so this would have to be rectified.
> > > >
> > > > Thanks,
> > > >
> > > > Roman
> > > > _______________________________________________
> > > > 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
>
> _______________________________________________
> 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
--
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%7C3ccaf4dae6074e10d27808d5fe281cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636694370599827378&sdata=mE%2FLHhl4iswq84Ol1QPDJ5DITtya6jahvEiWpE%2BbZwE%3D&reserved=0>

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

From simonpj at microsoft.com  Fri Aug 17 11:24:21 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 17 Aug 2018 11:24:21 +0000
Subject: [ghc-steering-committee] Proposal: Top-level kind signatures
 (#54)
In-Reply-To: <CAADqg9b=o2A_NQSMrb2GdcfWAHcSAAbeSrmt-+N+s--1UQMwEA@mail.gmail.com>
References: <CAADqg9b=o2A_NQSMrb2GdcfWAHcSAAbeSrmt-+N+s--1UQMwEA@mail.gmail.com>
Message-ID: <AM6PR83MB030967F3EE3832394490C808AD3D0@AM6PR83MB0309.EURPRD83.prod.outlook.com>

I’m strongly in favour of #54.   The current CUSK stuff is a huge mess.  The inability to write a kind signature for a type constructor is terrible.

One minor point that isn't clear to me: the proposal says that "Associated types may be given kind signatures within their classes". Are type variables mentioned in the class head visible in the kind signature for the associated type?

Good point.  I was going to say “behave like GADTs” where the variables in the header do not scope over the signatures; but unfortunately in class decls the variables in the header *do* scope over the (term-level) signatures.

Richard, what do you think?  Maybe associated types should only be given kind signatures at the top level (alongside the kind signature for the class).  That would at least be clear.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Roman Leshchinskiy
Sent: 09 August 2018 20:46
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Proposal: Top-level kind signatures (#54)

Hi everyone,

The proposal is about adding stand-alone kind signatures for type declarations:

  https://github.com/ghc-proposals/ghc-proposals/pull/54<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F54&data=02%7C01%7Csimonpj%40microsoft.com%7Cb58b9c99576e4727d9b808d5fe30c0a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636694407703047991&sdata=%2Fw6%2F%2B57ofExBMZUoAU%2FfFOpfzIDoRGpsxoUScDx6xyw%3D&reserved=0>

The basic idea is to add support for kind signatures like this:

type T :: Type -> Type -> Type
data T a b = ...

Signatures would be introduced by the keyword 'type' and could be provided for data types, type synonyms, type families and classes. The extension would be enable via -XTopLevelKinds.

Additionally, complete user-supplied kind signatures (CUSKs, see https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#complete-user-supplied-kind-signatures-and-polymorphic-recursion<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fglasgow_exts.html%23complete-user-supplied-kind-signatures-and-polymorphic-recursion&data=02%7C01%7Csimonpj%40microsoft.com%7Cb58b9c99576e4727d9b808d5fe30c0a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636694407703047991&sdata=lLCdw6ejJEa7iUVKRxh14yuQBjHkLjGDOHb9LtzfXQc%3D&reserved=0>) would be given a separate language extension, -XCUSKs which would be on by default for now but turned off in GHC 8.8 and then deprecated and removed.

The proposal depends on #81.

Feedback has been positive and this is rather cleaner than the current story so I'm in favour of accepting this.

Like Richard, I'm not really happy with the name "TopLevelKinds", especially since signatures for associated types aren't even on the top level. Would something like StandAloneKinds or ExplicitKindSignatures be better?

One minor point that isn't clear to me: the proposal says that "Associated types may be given kind signatures within their classes". Are type variables mentioned in the class head visible in the kind signature for the associated type?

Thanks,

Roman

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

From simonpj at microsoft.com  Fri Aug 17 13:00:07 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 17 Aug 2018 13:00:07 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <f0538fa83352666eaf6ebd0a4e065765197e1da6.camel@joachim-breitner.de>
References: <f0538fa83352666eaf6ebd0a4e065765197e1da6.camel@joachim-breitner.de>
Message-ID: <AM6PR83MB03096722A9287BCDFFA0D85BAD3D0@AM6PR83MB0309.EURPRD83.prod.outlook.com>

Joachim

You are doing a really great job as our secretary.  Thank you!

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
|  Behalf Of Joachim Breitner
|  Sent: 04 August 2018 16:54
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Status
|  
|  Hi committee,
|  
|  with the new nominations out of the way, time to stop navel gazing and doing
|  some work!
|  
|  Since the last status update, we
|  
|   * Got two new members. Yay and welcome!
|  
|   * were asked to review these proposals:
|     #149 Replace atomicModifyMutVar# (Shepherd: Simon M)
|     #143 Remove * syntax (Shepherd: Ben)
|     #128 Allow ScopedTypeVariables refer to types (Shepherd: Iavor)
|     #126 Type Applications in Patterns (Shepherd: Iavor)
|  
|   * two reviews were reassigned:
|     #106 Define Kinds Without Promotion (New shepherd: Eric)
|     #35  Lazy unboxed tuples (New shepherd: Vitaly)
|  
|   * got a recommendation from shepherds about:
|     #112 Remove TypeOperators => NoStarIsType "migration" (rec: accept)
|     #149 Replace atomicModifyMutVar# (rec: accept)
|     #111 Linear Types (rec: acceptish)
|     #143 Remove * syntax (rec: accept)
|     #128 Allow ScopedTypeVariables refer to types (rec: accept)
|     #126 Type Applications in Patterns (rec: accept)
|  
|  
|   * decided about the following proposals
|     #99  forall {k} (accept)
|     #112 Remove TypeOperators => NoStarIsType "migration" (accept)
|     #149 Replace atomicModifyMutVar# (accept)
|     #134 Deprecating Exports (accept)
|     #128 Allow ScopedTypeVariables refer to types (accept)
|     #143 Remove * syntax (accept)
|  
|  We currently have to act on the following 11 proposals, which is two less
|  than last round. Lets further get the backlog down!
|  
|  Type applications in patterns
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F126&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9ba9f627
|  e78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636689
|  948604137734&amp;sdata=m%2FvWs%2F8l5DzoMoSwRsDqNHLJrQl0uP%2BxYeZilx6Webo%3D&
|  amp;reserved=0
|  Shepherd: Iavor
|  Status: Overall positive response, acceptance likely
|  
|  Type annotated quoters
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F125&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9ba9f627
|  e78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636689
|  948604147743&amp;sdata=QmFW%2BaJsMeOvDE6w7Si5PneyxwPoiwYlWEC7IHDwduQ%3D&amp;
|  reserved=0
|  Shepherd: Manuel
|  Status: Still waiting for recommendation.
|  
|  Provenance-Qualified Package Imports
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F115&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9ba9f627
|  e78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636689
|  948604147743&amp;sdata=TBFGoXuLalWGsg7bl%2FlMtJHrTzagw24Tnf5SVTyDkss%3D&amp;
|  reserved=0
|  Shepherd: Ben
|  Status: Still waiting for recommendation. This is pretty old!
|  
|  Linear types
|  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%7C9ba9f627
|  e78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636689
|  948604147743&amp;sdata=Gc6NTApCmVOTJBSDVZJx9J7Yh2l3Lcz4cwZ0861wGXg%3D&amp;re
|  served=0
|  Shepherd: Richard
|  Status: acceptance-ish(?)
|  
|  Define Kinds Without Promotion
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F106&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9ba9f627
|  e78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636689
|  948604147743&amp;sdata=7Z%2FhS%2Bn%2By9R3TxneVbEj7bbuHoWmM0%2F7bozwmKr6BtU%3
|  D&amp;reserved=0
|  Shepherd: Eric
|  Status: Reassigned to Eric, waiting for recommendation.
|  
|  ExtraCommas
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F87&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9ba9f627e
|  78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366899
|  48604147743&amp;sdata=UwCvi1lOWGYKdQl60mT5zWXJSrE1k9WgnqEMS75XADI%3D&amp;res
|  erved=0
|  Shepherd: Chris
|  Recommendation: accept
|  Status: Ongoing discussion, met with some reservation.
|  
|  Visible dependent quantification (TL;DR: forall k -> k -> *)
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F81&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9ba9f627e
|  78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366899
|  48604147743&amp;sdata=SdFvaE1O9MR0fYPSbe%2FCgMTKqS4WGytFiAoEpRfK%2FjU%3D&amp
|  ;reserved=0
|  Shepherd: Roman Leshchinskiy
|  Status: Discussion needs to happen
|  
|  Top-level kinds signatures
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F54&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9ba9f627e
|  78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366899
|  48604147743&amp;sdata=S%2FiFnn80cGt0GJvpLVJaCzF0TekQ7KiYAB%2B3fmG75NI%3D&amp
|  ;reserved=0
|  Shepherd: Roman Leshchinskiy
|  Status: Waiting for recommendation.
|  
|  Or-Patterns
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F43&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9ba9f627e
|  78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366899
|  48604147743&amp;sdata=6SS05YDsYFFvV91Va%2FsgXD9jhsWzYAEDyY8d5AuJU08%3D&amp;r
|  eserved=0
|  Shepherd: Manuel
|  Recommendation: accept
|  Status: Round 2 discussion ebbed down
|  
|  Lazy unboxed tuples
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F35&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9ba9f627e
|  78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366899
|  48604147743&amp;sdata=PC0T4sXCUdvMhejZa5HKpmMZ%2B%2BKaZoPEHnh2F7qLPFw%3D&amp
|  ;reserved=0
|  Shepherd: Vitaly
|  Status: Reassigned to Vitaly, waiting for recommendation.
|  
|  Bundling patterns with synonyms
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
|  2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F28&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C9ba9f627e
|  78b493484ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366899
|  48604147743&amp;sdata=eFWKfjBVRnxx%2FvPOCGJCQRlpBnBb1MyT9LxhEYjIL5w%3D&amp;r
|  eserved=0
|  Shepherd: Chris
|  Recommendation: accept
|  Status: Ongoing discussion, met with some resistance.
|  
|  
|  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%7C9ba9f627e78b4934
|  84ea08d5fa2289ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63668994860414
|  7743&amp;sdata=jpvM%2FWoyzFv3uBDbGhpsA%2BFI%2FehhqLW8vgnnODl9aPI%3D&amp;rese
|  rved=0

From rae at cs.brynmawr.edu  Fri Aug 17 15:33:28 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 17 Aug 2018 11:33:28 -0400
Subject: [ghc-steering-committee] Proposal: Top-level kind signatures
 (#54)
In-Reply-To: <AM6PR83MB030967F3EE3832394490C808AD3D0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
References: <CAADqg9b=o2A_NQSMrb2GdcfWAHcSAAbeSrmt-+N+s--1UQMwEA@mail.gmail.com>
 <AM6PR83MB030967F3EE3832394490C808AD3D0@AM6PR83MB0309.EURPRD83.prod.outlook.com>
Message-ID: <B6D6DFAA-81E4-4945-90BE-25D960A9D99B@cs.brynmawr.edu>



> On Aug 17, 2018, at 7:24 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> Good point.  I was going to say “behave like GADTs” where the variables in the header do not scope over the signatures; but unfortunately in class decls the variables in the header *do* scope over the (term-level) signatures.

It's even worse than this. Not only do they scope over term-level signatures, but they scope over associated type declarations. (Confusingly, they do not scope over associated type family default equations.)

>  
> Richard, what do you think?  Maybe associated types should only be given kind signatures at the top level (alongside the kind signature for the class).  That would at least be clear.

That would be clear and unambiguous, but quite awkward:

class C a where
  type F a b
type F :: ...

Why does one `type` appear in within the class but the other does not? We have some long-winded arguments here to answer that question, but it's all unsatisfying. I don't have a better idea, though.

Separately, we could just tack this new feature into -XKindSignatures instead of inventing a new extension.... but making a change to an extension as stable and as old as -XKindSignatures is unfortunate.

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

From rae at cs.brynmawr.edu  Fri Aug 17 15:46:43 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 17 Aug 2018 11:46:43 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>



> On Aug 17, 2018, at 3:22 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> Can you restate the terminological choice(s) as explicitly as possible, with examples?

Old:

type: Something used at the type level. In contrast to "type constructor", generally doesn't take any arguments. Examples: Int, Bool, 4, 'True, '[Int, Bool], '[]
type constructor: Something used in a function position in a type. Examples: Maybe, Either, 'Just
data constructor: A symbol used to construct a data element of some type at runtime. Examples: True, Nothing, Left. Non-examples: 'True, 'Nothing, 'Left.
promotion: 'True is a type that is the promoted form of the data constructor True; 'Just is a type constructor that is the promoted form of the data constructor Just.


New:

type: Something that can reasonably go to the right of a ::. In other words, an element of the kind * (or Type). Examples: Int, Bool, Maybe Double. Non-examples: 4, 'True, '[Int, Bool], '[]
type constructor: Something that, when applied to the right number of well-kinded arguments, becomes a type. Examples: Maybe, Either. Non-example: 'Just
data constructor: A symbol used to construct a data element of some type, at either runtime or compile-time. Examples: True, Nothing, Left, 'True, 'Nothing, 'Left.
promotion: No longer used. 'True and True are now the same thing: both data constructors, just used in different contexts.


NB: This is all about user-facing documentation. I am not proposing any change to GHC datatypes.

I hope this helps!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180817/01338b42/attachment.html>

From rae at cs.brynmawr.edu  Fri Aug 17 16:10:40 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 17 Aug 2018 12:10:40 -0400
Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn
 on unbanged strict patterns (#35); Recommendation: Reject
In-Reply-To: <1534487839.3486.1477078640.2EB260DD@webmail.messagingengine.com>
References: <CALpVSmOrzO=EAa=aYxHqwZyj-QFzXKg_8HcF42GJFu1c03iT7w@mail.gmail.com>
 <AM0PR83MB030892D4A17DA41D292C4CF3AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <1534487839.3486.1477078640.2EB260DD@webmail.messagingengine.com>
Message-ID: <A491A206-CD77-49C0-A5EC-25BF3318F129@cs.brynmawr.edu>

I worry that everyone has missed the final sentence of the proposal:

> This is already implemented, but it is easy enough to tweak the design.

This proposal is fully implemented in 8.4, and I believe it is, too, in 8.2. At the time the proposal was written, the new features had not been released, and it was hoped that the discussion would influence the design. But due to the fact that this was parked for so long, the implementation has since been released.

(Why the weird temporal ordering? Improvements around levity polymorphism that absolutely needed to get into 8.2 walked over this code. It was tangled and so I cleaned it up. It was only later that we recognized a proposal was in order.)

The big motivation for (A) is that it removes unboxed tuples (resp. sums) from being a special case. Now, we're uniform.

The big motivation for (B) is that it allows more (correct) programs to compile. The previous behavior was throwing out programs because GHC was worried that the author was being silly -- but that's precisely what warnings are good for.

Have I lost interest? Possibly. I've never cared all that deeply about this, other than that the code was quite hard to understand (and incorrect w.r.t. the manual) when I came across it. My lack of prodding on this issue was simply because the lack of an answer wasn't holding me up.

Richard

> On Aug 17, 2018, at 2:37 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> I think the reason is more that it's a change that doesn't seem to be well-motivated, i.e. neither the proposal nor the discussion offer a compelling example where you would want an unboxed tuple to be matched lazily.
> 
> That being said, I overlooked the implicit-bang alternative when I first read the proposal. That seems quite reasonable. The default behavior remains what people seem to expect, but enables the explicit use of lazy patterns should you want them.
> 
> On Thu, Aug 16, 2018, at 03:38, Simon Peyton Jones via ghc-steering-committee wrote:
>> I’m actually mildly in favour of the proposed design.
>> 
>> The main reason for rejection is really
>> 
>> * It’s a change
>> 
>> Change is always a bit disruptive; and no one is arguing strongly that 
>> they really really want this.
>> 
>> So maybe we should just “park” it as OK in principle, but without 
>> sufficient support to justify the (hard to quantify) changeover costs.
>> 
>> Simon
>> 
>> From: ghc-steering-committee <ghc-steering-committee-
>> bounces at haskell.org> On Behalf Of Vitaly Bragilevsky
>> Sent: 16 August 2018 01:37
>> To: ghc-steering-committee at haskell.org
>> Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn 
>> on unbanged strict patterns (#35); Recommendation: Reject
>> 
>> Hi,
>> 
>> the lazy unboxed tuples proposal  
>> (https://github.com/ghc-proposals/ghc-proposals/pull/35<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F35&data=02%7C01%7Csimonpj%40microsoft.com%7C983115e9eee64eb4b03c08d603107655%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636699766583676606&sdata=PXTsCrM4otm8ZCEFZvNfkydSBo6J77zh5qb9CVNmZX8%3D&reserved=0> <https://github.com/ghc-proposals/ghc-proposals/pull/35%3Chttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F35&data=02%7C01%7Csimonpj%40microsoft.com%7C983115e9eee64eb4b03c08d603107655%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636699766583676606&sdata=PXTsCrM4otm8ZCEFZvNfkydSBo6J77zh5qb9CVNmZX8%3D&reserved=0%3E>) 
>> was under discussion for a long period of time (more than a year and a 
>> half since submission).
>> 
>> As a shepherd to this proposal I recommend rejection based on the following:
>> 
>> * there is no clearly articulated motivation in favor of this proposal 
>> despite complying with the Manual;
>> * implementing this would lead to hard-to-trace performance issues in 
>> the users code (due to move from strictness in current GHC behaviour to 
>> laziness);
>> * it looks like the change (B) of the proposal (warn an unbanged strict 
>> patterns) meets no complains, so it is better to be resubmitted as a 
>> separate proposal;
>> * if resubmitted separately the change (A) should elaborate on 
>> desugaring to make potential performance drawbacks clear;
>> * it seems (maybe mistakenly) that the author has lost his interest in 
>> this proposal.
>> 
>> Although silence is undestood as agreement, I'd be glad to receive a 
>> feedback on this recommendation.
>> 
>> Regards,
>> Vitaly
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180817/9eb92980/attachment-0001.html>

From rae at cs.brynmawr.edu  Fri Aug 17 16:16:38 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 17 Aug 2018 12:16:38 -0400
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <e35a1d78c27cb0a74c4a5603c3f674583939c41e.camel@joachim-breitner.de>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
 <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>
 <e35a1d78c27cb0a74c4a5603c3f674583939c41e.camel@joachim-breitner.de>
Message-ID: <2113C5F7-177B-4B87-B065-8035A2F8B268@cs.brynmawr.edu>

The rule is this, implemented in the lexer:

With -XTypeApplications on, the character immediately before an @ determines how it is lexed.
1. If the character is a legal end-of-identifier character (respecting the state of the -XMagicHash flag), then the @ is an as-pattern.
2. Otherwise, then the @ is the beginning of a type application.

I abbreviate the rule as talking about whitespace sensitivity, because if the character preceding the @ is, say, a +, then we lex +@ as a user-defined operator.

This rule has been implemented since GHC 8.0 and applies in patterns as well as expressions. I don't think anyone noticed. :) So it works reasonably well. It's a silly rule and I'd be happy to do better, but I don't think it's strictly necessary to aim for better here.

It would be reasonable to warn when a user writes an as-pattern that doesn't conform to this rule (with -XNoTypeApplications).

Richard

> On Aug 17, 2018, at 1:37 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi Richard,
> 
> Am Donnerstag, den 16.08.2018, 22:28 -0400 schrieb Richard Eisenberg:
>> Considering this future of relaxed ordering requirements on data
>> constructors isn't compulsory, but I do think it's better if we don't
>> paint ourselves into a corner around this.
> 
> I agree.
> 
> But so what do we do? Already now require that there is no space
> between @ and the following token when the user wants to use type
> applications in the pattern?
> 
> And would we also require the user to add a space after an at-pattern?
> In which case we should probably start a deprecation cycle for the
> currently legal
> 
>   foo (a @b) = …
> 
> 
> 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 rae at cs.brynmawr.edu  Fri Aug 17 16:17:36 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 17 Aug 2018 12:17:36 -0400
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <2113C5F7-177B-4B87-B065-8035A2F8B268@cs.brynmawr.edu>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
 <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>
 <e35a1d78c27cb0a74c4a5603c3f674583939c41e.camel@joachim-breitner.de>
 <2113C5F7-177B-4B87-B065-8035A2F8B268@cs.brynmawr.edu>
Message-ID: <4962FFB7-E7F5-4E57-8CF9-EB52A99A9D10@cs.brynmawr.edu>

Note that this rule is documented, in brief, in the manual:

> A visible type application is preceded with an @ sign. (To disambiguate the syntax, the @ must be preceded with a non-identifier letter, usually a space. For example, read at Int 5 would not parse.)

> On Aug 17, 2018, at 12:16 PM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> 
> The rule is this, implemented in the lexer:
> 
> With -XTypeApplications on, the character immediately before an @ determines how it is lexed.
> 1. If the character is a legal end-of-identifier character (respecting the state of the -XMagicHash flag), then the @ is an as-pattern.
> 2. Otherwise, then the @ is the beginning of a type application.
> 
> I abbreviate the rule as talking about whitespace sensitivity, because if the character preceding the @ is, say, a +, then we lex +@ as a user-defined operator.
> 
> This rule has been implemented since GHC 8.0 and applies in patterns as well as expressions. I don't think anyone noticed. :) So it works reasonably well. It's a silly rule and I'd be happy to do better, but I don't think it's strictly necessary to aim for better here.
> 
> It would be reasonable to warn when a user writes an as-pattern that doesn't conform to this rule (with -XNoTypeApplications).
> 
> Richard
> 
>> On Aug 17, 2018, at 1:37 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> Hi Richard,
>> 
>> Am Donnerstag, den 16.08.2018, 22:28 -0400 schrieb Richard Eisenberg:
>>> Considering this future of relaxed ordering requirements on data
>>> constructors isn't compulsory, but I do think it's better if we don't
>>> paint ourselves into a corner around this.
>> 
>> I agree.
>> 
>> But so what do we do? Already now require that there is no space
>> between @ and the following token when the user wants to use type
>> applications in the pattern?
>> 
>> And would we also require the user to add a space after an at-pattern?
>> In which case we should probably start a deprecation cycle for the
>> currently legal
>> 
>>  foo (a @b) = …
>> 
>> 
>> 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

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

From simonpj at microsoft.com  Fri Aug 17 16:21:01 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 17 Aug 2018 16:21:01 +0000
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <4962FFB7-E7F5-4E57-8CF9-EB52A99A9D10@cs.brynmawr.edu>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
 <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>
 <e35a1d78c27cb0a74c4a5603c3f674583939c41e.camel@joachim-breitner.de>
 <2113C5F7-177B-4B87-B065-8035A2F8B268@cs.brynmawr.edu>
 <4962FFB7-E7F5-4E57-8CF9-EB52A99A9D10@cs.brynmawr.edu>
Message-ID: <AM0PR83MB0308A2FEA0E755963B924563AD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Ha. We could tighten this up further to require a non-blank immediately after the @ for a type application.  Thus
            f @Int  or    g @(Tree Int)
but not
            f @ Int         g @ (Tree Int)

That would leave (p1 at p2) and (p1 @ p2) free for patterns.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 17 August 2018 17:18
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Discussion about "Type Application in Patterns" (#126)

Note that this rule is documented, in brief, in the manual:

> A visible type application is preceded with an @ sign. (To disambiguate the syntax, the @ must be preceded with a non-identifier letter, usually a space. For example, read at Int 5 would not parse.)


On Aug 17, 2018, at 12:16 PM, Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:

The rule is this, implemented in the lexer:

With -XTypeApplications on, the character immediately before an @ determines how it is lexed.
1. If the character is a legal end-of-identifier character (respecting the state of the -XMagicHash flag), then the @ is an as-pattern.
2. Otherwise, then the @ is the beginning of a type application.

I abbreviate the rule as talking about whitespace sensitivity, because if the character preceding the @ is, say, a +, then we lex +@ as a user-defined operator.

This rule has been implemented since GHC 8.0 and applies in patterns as well as expressions. I don't think anyone noticed. :) So it works reasonably well. It's a silly rule and I'd be happy to do better, but I don't think it's strictly necessary to aim for better here.

It would be reasonable to warn when a user writes an as-pattern that doesn't conform to this rule (with -XNoTypeApplications).

Richard


On Aug 17, 2018, at 1:37 AM, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:

Hi Richard,

Am Donnerstag, den 16.08.2018, 22:28 -0400 schrieb Richard Eisenberg:

Considering this future of relaxed ordering requirements on data
constructors isn't compulsory, but I do think it's better if we don't
paint ourselves into a corner around this.

I agree.

But so what do we do? Already now require that there is no space
between @ and the following token when the user wants to use type
applications in the pattern?

And would we also require the user to add a space after an at-pattern?
In which case we should probably start a deprecation cycle for the
currently legal

 foo (a @b) = …


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%7C549984ffda524c614d6008d6045cf7bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636701194744752293&sdata=i4KtV3B%2B2YUluqn3Rx7th3sm6%2BDYkinoMQE6n%2FNqdZQ%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/20180817/34e0c9bf/attachment-0001.html>

From eric at seidel.io  Fri Aug 17 16:34:40 2018
From: eric at seidel.io (Eric Seidel)
Date: Fri, 17 Aug 2018 12:34:40 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
Message-ID: <1534523680.869922.1477592816.05C77093@webmail.messagingengine.com>

Thanks Richard, you beat me to it :)

I agree with your definitions and examples with one clarification:

On Fri, Aug 17, 2018, at 11:46, Richard Eisenberg wrote:
> New:
> 
> type: Something that can reasonably go to the right of a ::. In other 
> words, an element of the kind * (or Type). Examples: Int, Bool, Maybe 
> Double. Non-examples: 4, 'True, '[Int, Bool], '[]

I think we should be a bit more pedantic here and say something like "something that can be the `t` in the judgment `x :: t`."

Going to the right of a :: could also be understood to mean appearing somewhere in the type-level, which is the old definition!

From eric at seidel.io  Fri Aug 17 16:56:24 2018
From: eric at seidel.io (Eric Seidel)
Date: Fri, 17 Aug 2018 12:56:24 -0400
Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn
 on unbanged strict patterns (#35); Recommendation: Reject
In-Reply-To: <A491A206-CD77-49C0-A5EC-25BF3318F129@cs.brynmawr.edu>
References: <CALpVSmOrzO=EAa=aYxHqwZyj-QFzXKg_8HcF42GJFu1c03iT7w@mail.gmail.com>
 <AM0PR83MB030892D4A17DA41D292C4CF3AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <1534487839.3486.1477078640.2EB260DD@webmail.messagingengine.com>
 <A491A206-CD77-49C0-A5EC-25BF3318F129@cs.brynmawr.edu>
Message-ID: <1534524984.877284.1477607664.6168B4D7@webmail.messagingengine.com>

On Fri, Aug 17, 2018, at 12:10, Richard Eisenberg wrote:
> I worry that everyone has missed the final sentence of the proposal:
> 
> > This is already implemented, but it is easy enough to tweak the design.
> 
> This proposal is fully implemented in 8.4, and I believe it is, too, in 
> 8.2. At the time the proposal was written, the new features had not been 
> released, and it was hoped that the discussion would influence the 
> design. But due to the fact that this was parked for so long, the 
> implementation has since been released.

Oh? I understood "already implemented" to mean on a branch somewhere waiting to be merged.
 
> The big motivation for (A) is that it removes unboxed tuples (resp. 
> sums) from being a special case. Now, we're uniform.

Uniformity is a valuable principle. Another valuable principle is the Principle of Least Surprise, which I fear (A) runs afoul of, especially given the public discussion. That's my primary concern wrt. (A). The Manual states that the purpose of unboxed tuples is to return multiple values in registers or on the stack. Boxing the tuples for a lazy pattern match violates this purpose.

Here's another alternative: keep the uniform behavior that is now implemented, and add a warning for lazy matches on unboxed tuples. I think I'd be happy with this warning. Yes, it adds a bit of syntactic overhead, but it also forces the programmer to clarify what's clearly a subtle issue!

On the other hand, perhaps the fact that the change is actually in 8.4 and GHC is (presumably) not getting tickets about unexpectedly boxing unboxed-tuples means that this fuss is much ado about nothing, and GHC is clever enough to avoid the boxing.

> The big motivation for (B) is that it allows more (correct) programs to 
> compile. The previous behavior was throwing out programs because GHC was 
> worried that the author was being silly -- but that's precisely what 
> warnings are good for.

Indeed, and I fully support (B) regardless of the outcome for (A).

From eric at seidel.io  Fri Aug 17 17:00:10 2018
From: eric at seidel.io (Eric Seidel)
Date: Fri, 17 Aug 2018 13:00:10 -0400
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <AM0PR83MB0308A2FEA0E755963B924563AD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
 <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>
 <e35a1d78c27cb0a74c4a5603c3f674583939c41e.camel@joachim-breitner.de>
 <2113C5F7-177B-4B87-B065-8035A2F8B268@cs.brynmawr.edu>
 <4962FFB7-E7F5-4E57-8CF9-EB52A99A9D10@cs.brynmawr.edu>
 <AM0PR83MB0308A2FEA0E755963B924563AD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <1534525210.877731.1477631272.364A71D0@webmail.messagingengine.com>

I've always thought of "@Int" as a single syntactic unit, so I'd be happy to disallow spaces between the @ and the type.

On Fri, Aug 17, 2018, at 12:21, Simon Peyton Jones via ghc-steering-committee wrote:
> Ha. We could tighten this up further to require a non-blank immediately 
> after the @ for a type application.  Thus
>             f @Int  or    g @(Tree Int)
> but not
>             f @ Int         g @ (Tree Int)
> 
> That would leave (p1 at p2) and (p1 @ p2) free for patterns.
> 
> Simon
> 
> From: ghc-steering-committee <ghc-steering-committee-
> bounces at haskell.org> On Behalf Of Richard Eisenberg
> Sent: 17 August 2018 17:18
> To: Joachim Breitner <mail at joachim-breitner.de>
> Cc: ghc-steering-committee at haskell.org
> Subject: Re: [ghc-steering-committee] Discussion about "Type Application 
> in Patterns" (#126)
> 
> Note that this rule is documented, in brief, in the manual:
> 
> > A visible type application is preceded with an @ sign. (To disambiguate the syntax, the @ must be preceded with a non-identifier letter, usually a space. For example, read at Int 5 would not parse.)
> 
> 
> On Aug 17, 2018, at 12:16 PM, Richard Eisenberg 
> <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
> 
> The rule is this, implemented in the lexer:
> 
> With -XTypeApplications on, the character immediately before an @ 
> determines how it is lexed.
> 1. If the character is a legal end-of-identifier character (respecting 
> the state of the -XMagicHash flag), then the @ is an as-pattern.
> 2. Otherwise, then the @ is the beginning of a type application.
> 
> I abbreviate the rule as talking about whitespace sensitivity, because 
> if the character preceding the @ is, say, a +, then we lex +@ as a user-
> defined operator.
> 
> This rule has been implemented since GHC 8.0 and applies in patterns as 
> well as expressions. I don't think anyone noticed. :) So it works 
> reasonably well. It's a silly rule and I'd be happy to do better, but I 
> don't think it's strictly necessary to aim for better here.
> 
> It would be reasonable to warn when a user writes an as-pattern that 
> doesn't conform to this rule (with -XNoTypeApplications).
> 
> Richard
> 
> 
> On Aug 17, 2018, at 1:37 AM, Joachim Breitner <mail at joachim-
> breitner.de<mailto:mail at joachim-breitner.de>> wrote:
> 
> Hi Richard,
> 
> Am Donnerstag, den 16.08.2018, 22:28 -0400 schrieb Richard Eisenberg:
> 
> Considering this future of relaxed ordering requirements on data
> constructors isn't compulsory, but I do think it's better if we don't
> paint ourselves into a corner around this.
> 
> I agree.
> 
> But so what do we do? Already now require that there is no space
> between @ and the following token when the user wants to use type
> applications in the pattern?
> 
> And would we also require the user to add a space after an at-pattern?
> In which case we should probably start a deprecation cycle for the
> currently legal
> 
>  foo (a @b) = …
> 
> 
> 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%7C549984ffda524c614d6008d6045cf7bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636701194744752293&sdata=i4KtV3B%2B2YUluqn3Rx7th3sm6%2BDYkinoMQE6n%2FNqdZQ%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
> 
> _______________________________________________
> 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  Fri Aug 17 17:27:30 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 17 Aug 2018 10:27:30 -0700
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <1534525210.877731.1477631272.364A71D0@webmail.messagingengine.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
 <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>
 <e35a1d78c27cb0a74c4a5603c3f674583939c41e.camel@joachim-breitner.de>
 <2113C5F7-177B-4B87-B065-8035A2F8B268@cs.brynmawr.edu>
 <4962FFB7-E7F5-4E57-8CF9-EB52A99A9D10@cs.brynmawr.edu>
 <AM0PR83MB0308A2FEA0E755963B924563AD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <1534525210.877731.1477631272.364A71D0@webmail.messagingengine.com>
Message-ID: <67b2b9f616afa8316fd9fec1a0f52578773a0c20.camel@joachim-breitner.de>

Hi,

Am Freitag, den 17.08.2018, 13:00 -0400 schrieb Eric Seidel:
> I've always thought of "@Int" as a single syntactic unit, so I'd be happy to disallow spaces between the @ and the type.

not opposed in principle, but if we go that route, it should also apply
to type applications in expressions, for consistency. Are we willing to
potentially break code out there?  (Well, it’s an extension, the fix is
simple and fully backward-compatible, and most people probably got it
right in the first place, so maybe breaking is not too bad.)

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/20180817/f2b9b54e/attachment.sig>

From rae at cs.brynmawr.edu  Sun Aug 19 01:32:10 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sat, 18 Aug 2018 21:32:10 -0400
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <67b2b9f616afa8316fd9fec1a0f52578773a0c20.camel@joachim-breitner.de>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
 <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>
 <e35a1d78c27cb0a74c4a5603c3f674583939c41e.camel@joachim-breitner.de>
 <2113C5F7-177B-4B87-B065-8035A2F8B268@cs.brynmawr.edu>
 <4962FFB7-E7F5-4E57-8CF9-EB52A99A9D10@cs.brynmawr.edu>
 <AM0PR83MB0308A2FEA0E755963B924563AD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <1534525210.877731.1477631272.364A71D0@webmail.messagingengine.com>
 <67b2b9f616afa8316fd9fec1a0f52578773a0c20.camel@joachim-breitner.de>
Message-ID: <3FAA3ED0-B1AC-4C10-983D-95211D747075@cs.brynmawr.edu>

So what's the new rule? Is it:

- @ denotes a type application if it is preceded by a non-identifier character and succeeded by a non-whitespace character
- @ denotes an as-pattern if is preceded by an identifier character or succeeded by a whitespace character

This means that `f@ Int` is an as-pattern.

I think the new rule just adds another twist to an already too-complicated plot.

I'm not worried about backward-compat issues here (echoing Joachim's sentiments) but I don't see the advantage to this new spec.

Richard

> On Aug 17, 2018, at 1:27 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Freitag, den 17.08.2018, 13:00 -0400 schrieb Eric Seidel:
>> I've always thought of "@Int" as a single syntactic unit, so I'd be happy to disallow spaces between the @ and the type.
> 
> not opposed in principle, but if we go that route, it should also apply
> to type applications in expressions, for consistency. Are we willing to
> potentially break code out there?  (Well, it’s an extension, the fix is
> simple and fully backward-compatible, and most people probably got it
> right in the first place, so maybe breaking is not too bad.)
> 
> 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 iavor.diatchki at gmail.com  Mon Aug 20 07:00:04 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 20 Aug 2018 10:00:04 +0300
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
	Promotion (#106)
In-Reply-To: <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
Message-ID: <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>

Hello,

These are significant changes to the current terminology and I really don't
think that this is the right place to discuss them---I think that they are
significant enough that they deserve their own proposal, with motivation,
and discussion by the community.

Here are some things to think about, if such a proposal is ever written:
  * in this new terminology `4` is not a type, but it also does not fall in
any of the other categories, so what is it?
  * how about `Eq`?
  * how about a type variable `f`?
  * are type functions really type constructors?
  * are we really suggesting that we should start supporting things like
`'True` at the value level?

Anyway, it seems to me that we have gone a little off-course, and these
changes are not really about making #106 easier to understand.

-Iavor


On Fri, Aug 17, 2018 at 6:46 PM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

>
>
> On Aug 17, 2018, at 3:22 AM, Simon Peyton Jones via ghc-steering-committee
> <ghc-steering-committee at haskell.org> wrote:
>
> Can you restate the terminological choice(s) as explicitly as possible,
> with examples?
>
>
> Old:
>
> type: Something used at the type level. In contrast to "type constructor",
> generally doesn't take any arguments. Examples: Int, Bool, 4, 'True, '[Int,
> Bool], '[]
> type constructor: Something used in a function position in a type.
> Examples: Maybe, Either, 'Just
> data constructor: A symbol used to construct a data element of some type
> at runtime. Examples: True, Nothing, Left. Non-examples: 'True, 'Nothing,
> 'Left.
> promotion: 'True is a type that is the promoted form of the data
> constructor True; 'Just is a type constructor that is the promoted form of
> the data constructor Just.
>
>
> New:
>
> type: Something that can reasonably go to the right of a ::. In other
> words, an element of the kind * (or Type). Examples: Int, Bool, Maybe
> Double. Non-examples: 4, 'True, '[Int, Bool], '[]
> type constructor: Something that, when applied to the right number of
> well-kinded arguments, becomes a type. Examples: Maybe, Either.
> Non-example: 'Just
> data constructor: A symbol used to construct a data element of some type,
> at either runtime or compile-time. Examples: True, Nothing, Left, 'True,
> 'Nothing, 'Left.
> promotion: No longer used. 'True and True are now the same thing: both
> data constructors, just used in different contexts.
>
>
> NB: This is all about user-facing documentation. I am not proposing any
> change to GHC datatypes.
>
> I hope this helps!
> 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/20180820/f06d10b5/attachment.html>

From simonpj at microsoft.com  Mon Aug 20 13:05:30 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 20 Aug 2018 13:05:30 +0000
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <3FAA3ED0-B1AC-4C10-983D-95211D747075@cs.brynmawr.edu>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
 <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>
 <e35a1d78c27cb0a74c4a5603c3f674583939c41e.camel@joachim-breitner.de>
 <2113C5F7-177B-4B87-B065-8035A2F8B268@cs.brynmawr.edu>
 <4962FFB7-E7F5-4E57-8CF9-EB52A99A9D10@cs.brynmawr.edu>
 <AM0PR83MB0308A2FEA0E755963B924563AD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <1534525210.877731.1477631272.364A71D0@webmail.messagingengine.com>
 <67b2b9f616afa8316fd9fec1a0f52578773a0c20.camel@joachim-breitner.de>
 <3FAA3ED0-B1AC-4C10-983D-95211D747075@cs.brynmawr.edu>
Message-ID: <AM0PR83MB0308B6DB05F5C9638890F4B7AD320@AM0PR83MB0308.EURPRD83.prod.outlook.com>

I think the goal is to preserve the syntactic space for
	f ((f -> Just x) @ (g -> Just y)) = ...
as an "and-pattern" which matches both patterns and binds both x and y.  And also perhaps
 
	f ((f -> Just x)@(g -> Just y)) = ...

by narrowing the situations in which "@" introduces a type argument to just
     <space>@<type>

with white space before, but not after the "@".

And do to his in both terms and patterns.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Richard Eisenberg
|  Sent: 19 August 2018 02:32
|  To: Joachim Breitner <mail at joachim-breitner.de>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Discussion about "Type
|  Application in Patterns" (#126)
|  
|  So what's the new rule? Is it:
|  
|  - @ denotes a type application if it is preceded by a non-identifier
|  character and succeeded by a non-whitespace character
|  - @ denotes an as-pattern if is preceded by an identifier character or
|  succeeded by a whitespace character
|  
|  This means that `f@ Int` is an as-pattern.
|  
|  I think the new rule just adds another twist to an already too-
|  complicated plot.
|  
|  I'm not worried about backward-compat issues here (echoing Joachim's
|  sentiments) but I don't see the advantage to this new spec.
|  
|  Richard
|  
|  > On Aug 17, 2018, at 1:27 PM, Joachim Breitner <mail at joachim-
|  breitner.de> wrote:
|  >
|  > Hi,
|  >
|  > Am Freitag, den 17.08.2018, 13:00 -0400 schrieb Eric Seidel:
|  >> I've always thought of "@Int" as a single syntactic unit, so I'd be
|  happy to disallow spaces between the @ and the type.
|  >
|  > not opposed in principle, but if we go that route, it should also
|  > apply to type applications in expressions, for consistency. Are we
|  > willing to potentially break code out there?  (Well, it’s an
|  > extension, the fix is simple and fully backward-compatible, and most
|  > people probably got it right in the first place, so maybe breaking is
|  > not too bad.)
|  >
|  > Cheers,
|  > Joachim
|  >
|  >
|  > --
|  > Joachim Breitner
|  >  mail at joachim-breitner.de
|  >
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
|  > achim-
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ca3c9
|  >
|  e99884a34ec6670d08d605739f1f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
|  >
|  0%7C636702391484409758&amp;sdata=mFolm%2BaXnNO%2FMdniUugnuqcotyGViJbtf
|  > qK%2FKD1VM0I%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-
|  committ
|  > ee
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committee

From bravit111 at gmail.com  Mon Aug 20 17:05:15 2018
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Mon, 20 Aug 2018 10:05:15 -0700
Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn
 on unbanged strict patterns (#35); Recommendation: Reject
In-Reply-To: <1534524984.877284.1477607664.6168B4D7@webmail.messagingengine.com>
References: <CALpVSmOrzO=EAa=aYxHqwZyj-QFzXKg_8HcF42GJFu1c03iT7w@mail.gmail.com>
 <AM0PR83MB030892D4A17DA41D292C4CF3AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <1534487839.3486.1477078640.2EB260DD@webmail.messagingengine.com>
 <A491A206-CD77-49C0-A5EC-25BF3318F129@cs.brynmawr.edu>
 <1534524984.877284.1477607664.6168B4D7@webmail.messagingengine.com>
Message-ID: <CALpVSmPgGDo_LtJaCA_GwOs3iTar25HQsQ5ktOhGOTnnPmueNg@mail.gmail.com>

Hi Joachim,

I am not sure how to proceed here. I think we need sort of "so be it"
recommendation for such cases that are
* no big deal
* already implemented
* there is no strong opposition (as it looks like)

Maybe the easiest solution is to close corresponding pull request silently,
since the current implementation is not a committee process artifact anyway.


Vitaly




On Fri, Aug 17, 2018 at 9:56 AM Eric Seidel <eric at seidel.io> wrote:

> On Fri, Aug 17, 2018, at 12:10, Richard Eisenberg wrote:
> > I worry that everyone has missed the final sentence of the proposal:
> >
> > > This is already implemented, but it is easy enough to tweak the design.
> >
> > This proposal is fully implemented in 8.4, and I believe it is, too, in
> > 8.2. At the time the proposal was written, the new features had not been
> > released, and it was hoped that the discussion would influence the
> > design. But due to the fact that this was parked for so long, the
> > implementation has since been released.
>
> Oh? I understood "already implemented" to mean on a branch somewhere
> waiting to be merged.
>
> > The big motivation for (A) is that it removes unboxed tuples (resp.
> > sums) from being a special case. Now, we're uniform.
>
> Uniformity is a valuable principle. Another valuable principle is the
> Principle of Least Surprise, which I fear (A) runs afoul of, especially
> given the public discussion. That's my primary concern wrt. (A). The Manual
> states that the purpose of unboxed tuples is to return multiple values in
> registers or on the stack. Boxing the tuples for a lazy pattern match
> violates this purpose.
>
> Here's another alternative: keep the uniform behavior that is now
> implemented, and add a warning for lazy matches on unboxed tuples. I think
> I'd be happy with this warning. Yes, it adds a bit of syntactic overhead,
> but it also forces the programmer to clarify what's clearly a subtle issue!
>
> On the other hand, perhaps the fact that the change is actually in 8.4 and
> GHC is (presumably) not getting tickets about unexpectedly boxing
> unboxed-tuples means that this fuss is much ado about nothing, and GHC is
> clever enough to avoid the boxing.
>
> > The big motivation for (B) is that it allows more (correct) programs to
> > compile. The previous behavior was throwing out programs because GHC was
> > worried that the author was being silly -- but that's precisely what
> > warnings are good for.
>
> Indeed, and I fully support (B) regardless of the outcome for (A).
> _______________________________________________
> 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/20180820/cbf74ac6/attachment.html>

From mail at joachim-breitner.de  Mon Aug 20 17:10:36 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 20 Aug 2018 10:10:36 -0700
Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn
 on unbanged strict patterns (#35); Recommendation: Reject
In-Reply-To: <CALpVSmPgGDo_LtJaCA_GwOs3iTar25HQsQ5ktOhGOTnnPmueNg@mail.gmail.com>
References: <CALpVSmOrzO=EAa=aYxHqwZyj-QFzXKg_8HcF42GJFu1c03iT7w@mail.gmail.com>
 <AM0PR83MB030892D4A17DA41D292C4CF3AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <1534487839.3486.1477078640.2EB260DD@webmail.messagingengine.com>
 <A491A206-CD77-49C0-A5EC-25BF3318F129@cs.brynmawr.edu>
 <1534524984.877284.1477607664.6168B4D7@webmail.messagingengine.com>
 <CALpVSmPgGDo_LtJaCA_GwOs3iTar25HQsQ5ktOhGOTnnPmueNg@mail.gmail.com>
Message-ID: <7833122633ce486b949034fe319bd8c12dc6a198.camel@joachim-breitner.de>

Hi,

if your recommendation is “so be it”, then make that your official
recommendation. If there is no opposition within a week or so, we can
mark the proposal as accepted, and thus bless the status quo.

Cheers,
Joachim

Am Montag, den 20.08.2018, 10:05 -0700 schrieb Vitaly Bragilevsky:
> Hi Joachim,
> 
> I am not sure how to proceed here. I think we need sort of "so be it" recommendation for such cases that are
> * no big deal
> * already implemented
> * there is no strong opposition (as it looks like)
> 
> Maybe the easiest solution is to close corresponding pull request silently, since the current implementation is not a committee process artifact anyway.
> 
> 
> Vitaly
> 
> 
> 
> 
> On Fri, Aug 17, 2018 at 9:56 AM Eric Seidel <eric at seidel.io> wrote:
> > On Fri, Aug 17, 2018, at 12:10, Richard Eisenberg wrote:
> > > I worry that everyone has missed the final sentence of the proposal:
> > > 
> > > > This is already implemented, but it is easy enough to tweak the design.
> > > 
> > > This proposal is fully implemented in 8.4, and I believe it is, too, in 
> > > 8.2. At the time the proposal was written, the new features had not been 
> > > released, and it was hoped that the discussion would influence the 
> > > design. But due to the fact that this was parked for so long, the 
> > > implementation has since been released.
> > 
> > Oh? I understood "already implemented" to mean on a branch somewhere waiting to be merged.
> > 
> > > The big motivation for (A) is that it removes unboxed tuples (resp. 
> > > sums) from being a special case. Now, we're uniform.
> > 
> > Uniformity is a valuable principle. Another valuable principle is the Principle of Least Surprise, which I fear (A) runs afoul of, especially given the public discussion. That's my primary concern wrt. (A). The Manual states that the purpose of unboxed tuples is to return multiple values in registers or on the stack. Boxing the tuples for a lazy pattern match violates this purpose.
> > 
> > Here's another alternative: keep the uniform behavior that is now implemented, and add a warning for lazy matches on unboxed tuples. I think I'd be happy with this warning. Yes, it adds a bit of syntactic overhead, but it also forces the programmer to clarify what's clearly a subtle issue!
> > 
> > On the other hand, perhaps the fact that the change is actually in 8.4 and GHC is (presumably) not getting tickets about unexpectedly boxing unboxed-tuples means that this fuss is much ado about nothing, and GHC is clever enough to avoid the boxing.
> > 
> > > The big motivation for (B) is that it allows more (correct) programs to 
> > > compile. The previous behavior was throwing out programs because GHC was 
> > > worried that the author was being silly -- but that's precisely what 
> > > warnings are good for.
> > 
> > Indeed, and I fully support (B) regardless of the outcome for (A).
> > _______________________________________________
> > 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/20180820/1d1c3b3e/attachment.sig>

From rae at cs.brynmawr.edu  Tue Aug 21 03:56:15 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 20 Aug 2018 23:56:15 -0400
Subject: [ghc-steering-committee] Discussion about "Type Application in
 Patterns" (#126)
In-Reply-To: <AM0PR83MB0308B6DB05F5C9638890F4B7AD320@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <CAGK9nupsNiH5EkPLPtyhnvZvtfVoYCY=SkP7xRcA2+64jB-YMA@mail.gmail.com>
 <6036d7eccc982f7c5df6679a83f2ca98fd1285d2.camel@joachim-breitner.de>
 <AM0PR83MB03087E90020FF4AAC1E8FF51AD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <6e924106c4439ffc923a7dbd09694a4c4bc486df.camel@joachim-breitner.de>
 <AM0PR83MB0308F793E3933A51CF2290CEAD3E0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <662f7706797dd2d75f5ffdf9af3990a6aec951ff.camel@joachim-breitner.de>
 <B616A9B6-4DEC-4F9D-B352-A6C5E37795EC@cs.brynmawr.edu>
 <e35a1d78c27cb0a74c4a5603c3f674583939c41e.camel@joachim-breitner.de>
 <2113C5F7-177B-4B87-B065-8035A2F8B268@cs.brynmawr.edu>
 <4962FFB7-E7F5-4E57-8CF9-EB52A99A9D10@cs.brynmawr.edu>
 <AM0PR83MB0308A2FEA0E755963B924563AD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <1534525210.877731.1477631272.364A71D0@webmail.messagingengine.com>
 <67b2b9f616afa8316fd9fec1a0f52578773a0c20.camel@joachim-breitner.de>
 <3FAA3ED0-B1AC-4C10-983D-95211D747075@cs.brynmawr.edu>
 <AM0PR83MB0308B6DB05F5C9638890F4B7AD320@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <25DD9B5F-31BF-4A78-8445-B60DFF3811E7@cs.brynmawr.edu>

But is this summary correct:

> - @ denotes a type application if it is preceded by a non-identifier character and succeeded by a non-whitespace character
> - @ denotes an as-pattern if is preceded by an identifier character or succeeded by a whitespace character
> 
> This means that `f@ Int` is an as-pattern.

I still say this is an awkward twist, but I see what you're getting at.

Richard

> On Aug 20, 2018, at 9:05 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> I think the goal is to preserve the syntactic space for
> 	f ((f -> Just x) @ (g -> Just y)) = ...
> as an "and-pattern" which matches both patterns and binds both x and y.  And also perhaps
> 
> 	f ((f -> Just x)@(g -> Just y)) = ...
> 
> by narrowing the situations in which "@" introduces a type argument to just
>     <space>@<type>
> 
> with white space before, but not after the "@".
> 
> And do to his in both terms and patterns.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
> |  Sent: 19 August 2018 02:32
> |  To: Joachim Breitner <mail at joachim-breitner.de>
> |  Cc: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] Discussion about "Type
> |  Application in Patterns" (#126)
> |  
> |  So what's the new rule? Is it:
> |  
> |  - @ denotes a type application if it is preceded by a non-identifier
> |  character and succeeded by a non-whitespace character
> |  - @ denotes an as-pattern if is preceded by an identifier character or
> |  succeeded by a whitespace character
> |  
> |  This means that `f@ Int` is an as-pattern.
> |  
> |  I think the new rule just adds another twist to an already too-
> |  complicated plot.
> |  
> |  I'm not worried about backward-compat issues here (echoing Joachim's
> |  sentiments) but I don't see the advantage to this new spec.
> |  
> |  Richard
> |  
> |  > On Aug 17, 2018, at 1:27 PM, Joachim Breitner <mail at joachim-
> |  breitner.de> wrote:
> |  >
> |  > Hi,
> |  >
> |  > Am Freitag, den 17.08.2018, 13:00 -0400 schrieb Eric Seidel:
> |  >> I've always thought of "@Int" as a single syntactic unit, so I'd be
> |  happy to disallow spaces between the @ and the type.
> |  >
> |  > not opposed in principle, but if we go that route, it should also
> |  > apply to type applications in expressions, for consistency. Are we
> |  > willing to potentially break code out there?  (Well, it’s an
> |  > extension, the fix is simple and fully backward-compatible, and most
> |  > people probably got it right in the first place, so maybe breaking is
> |  > not too bad.)
> |  >
> |  > Cheers,
> |  > Joachim
> |  >
> |  >
> |  > --
> |  > Joachim Breitner
> |  >  mail at joachim-breitner.de
> |  >
> |  >
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
> |  > achim-
> |  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ca3c9
> |  >
> |  e99884a34ec6670d08d605739f1f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> |  >
> |  0%7C636702391484409758&amp;sdata=mFolm%2BaXnNO%2FMdniUugnuqcotyGViJbtf
> |  > qK%2FKD1VM0I%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-
> |  committ
> |  > ee
> |  
> |  _______________________________________________
> |  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/20180820/f1648b40/attachment-0001.html>

From rae at cs.brynmawr.edu  Tue Aug 21 04:06:08 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 21 Aug 2018 00:06:08 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
Message-ID: <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>



> On Aug 20, 2018, at 3:00 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello,
> 
> These are significant changes to the current terminology and I really don't think that this is the right place to discuss them---I think that they are significant enough that they deserve their own proposal, with motivation, and discussion by the community.

Perhaps you're right that this should go out to the community. Nevertheless, I'm finding the discussion here to be very helpful, as it's refining my own understanding of this all. If the general consensus here is that we need more community feedback on these points, I'm happy to seek it out.

> 
> Here are some things to think about, if such a proposal is ever written:
>   * in this new terminology `4` is not a type, but it also does not fall in any of the other categories, so what is it?

It's type-level data.

>   * how about `Eq`?

It's a "constraint constructor", a generalization of a type class.

>   * how about a type variable `f`?

It's a type variable. But this is a great question: should it be something else, perhaps a quantified variable (if `f`'s kind isn't Type)? After all, if we have (f :: Nat), then f wouldn't range over types. Indeed, I think calling an f of non-Type kind something other than a type variable would be an improvement. I don't have a great suggestion of what we should call it, though.

>   * are type functions really type constructors?

I'm not sure what this means. Right now, if we have `type family F a`, then F isn't really a type constructor, as we can't ever write a plain F in a Haskell program.

>   * are we really suggesting that we should start supporting things like `'True` at the value level?

No. I'm suggesting that `'True` and `True` are just two different ways of referring to the same thing. The former is accepted only in a type-level context.

> 
> Anyway, it seems to me that we have gone a little off-course, and these changes are not really about making #106 easier to understand.

But I think they are, for the reasons I've articulated above. The GitHub trail contains several comments to the effect of "this proposal is simply a change in data constructors' namespace" but the proposal describes the new feature as a change to promotion.

Richard

From iavor.diatchki at gmail.com  Tue Aug 21 05:47:13 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 21 Aug 2018 08:47:13 +0300
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
	Promotion (#106)
In-Reply-To: <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
 <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
Message-ID: <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>

Hello,

On Tue, Aug 21, 2018 at 7:06 AM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

>
> >
> > Here are some things to think about, if such a proposal is ever written:
> >   * in this new terminology `4` is not a type, but it also does not fall
> in any of the other categories, so what is it?
>
> It's type-level data.
>
> Why? it is not introduced by a `data` declaration.



> >   * how about `Eq`?
>
> It's a "constraint constructor", a generalization of a type class.
>
> Yes, we could refer to the things that construct types of kind K, as
K-constructors, and indeed sometimes people do.   This is consistent, for
example we could say that `4` is a `Nat` constructor.  However, it is also
convenient to have the concept of a "type constructor", which ranges over
all of these things, independent of what their kind is.   And, the question
of how they were introduced (through a `data` declaration, a class, as a
primitive or in some other way) is often completely irrelevant.


>   * how about a type variable `f`?
>
> It's a type variable. But this is a great question: should it be something
> else, perhaps a quantified variable (if `f`'s kind isn't Type)? After all,
> if we have (f :: Nat), then f wouldn't range over types. Indeed, I think
> calling an f of non-Type kind something other than a type variable would be
> an improvement. I don't have a great suggestion of what we should call it,
> though.
>

I think the current terminology works just fine and we don't need to keep
inventing new names.

>   * are type functions really type constructors?
>
> I'm not sure what this means. Right now, if we have `type family F a`,
> then F isn't really a type constructor, as we can't ever write a plain F in
> a Haskell program.
>
> I was referring to the fact that some type functions meet your definition
of a type constructor: when applied to enough arguments they produce
something of kind `Type`.



> >   * are we really suggesting that we should start supporting things like
> `'True` at the value level?
>
> No. I'm suggesting that `'True` and `True` are just two different ways of
> referring to the same thing. The former is accepted only in a type-level
> context.
>

I think that this is the crux of our misunderstanding: if it is really the
same thing, then why does it have different names, and some of them are
only available sometimes.
In what sense does a `type data` declaration introduce a `data`
constructor, if this `data` constructor can never be used at the value
level (e.g., in a case statement)?


> >
> > Anyway, it seems to me that we have gone a little off-course, and these
> changes are not really about making #106 easier to understand.
>
> But I think they are, for the reasons I've articulated above. The GitHub
> trail contains several comments to the effect of "this proposal is simply a
> change in data constructors' namespace" but the proposal describes the new
> feature as a change to promotion.
>

We may be able to implement this proposal as just a change to a
data-constructor's namespace (I am not sure, last time I tried to do it, it
seemed more complicated than this, but this was a long time ago, and I a
much more familiar with how GHC works now).   Explaining it that way is not
simpler, however, as this discussion has illustrated.

This is a summary:
   * this proposal does NOT change `data` declarations---they work just
like they do at the moment,
   * this proposal does NOT change anything to do with promotion (or
whatever we want to call what `DataKinds` does)
   * this proposal DOES introduce a new language construct, `type data`,
which looks somewhat like a `data` declaration, but it is not the same
(e.g. no records, no strictness, unpacking, constructors can't be the same
as the LHS, etc.)
   * the purpose of `type data` is to declare some new type-level
constants, that's all.

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

From eric at seidel.io  Tue Aug 21 13:18:14 2018
From: eric at seidel.io (Eric Seidel)
Date: Tue, 21 Aug 2018 09:18:14 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
 <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
 <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>
Message-ID: <1534857494.2034461.1481235360.7051A7E7@webmail.messagingengine.com>

Thanks Iavor and Richard for your comments. This whole discussion has been quite illuminating to me as well. (The more I sleep on it, the more I feel swayed by Richard's perspective.)

That being said, I don't think this proposal is the right place to settle the issue. I think my recommendation at this point would be to:

1. Accept the proposal as is. It uses standard terminology, and within that framework I think it is quite clear.
2. Encourage Richard to write up another proposal to discuss the broader terminology issue. It seems like ghc-proposals would actually be a natural place to discuss this further. It doesn't really affect the implementation, but it would have a big impact on the Manual.

On Tue, Aug 21, 2018, at 01:47, Iavor Diatchki wrote:
> Hello,
> 
> On Tue, Aug 21, 2018 at 7:06 AM Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
> 
> >
> > >
> > > Here are some things to think about, if such a proposal is ever written:
> > >   * in this new terminology `4` is not a type, but it also does not fall
> > in any of the other categories, so what is it?
> >
> > It's type-level data.
> >
> > Why? it is not introduced by a `data` declaration.
> 
> 
> 
> > >   * how about `Eq`?
> >
> > It's a "constraint constructor", a generalization of a type class.
> >
> > Yes, we could refer to the things that construct types of kind K, as
> K-constructors, and indeed sometimes people do.   This is consistent, for
> example we could say that `4` is a `Nat` constructor.  However, it is also
> convenient to have the concept of a "type constructor", which ranges over
> all of these things, independent of what their kind is.   And, the question
> of how they were introduced (through a `data` declaration, a class, as a
> primitive or in some other way) is often completely irrelevant.
> 
> 
> >   * how about a type variable `f`?
> >
> > It's a type variable. But this is a great question: should it be something
> > else, perhaps a quantified variable (if `f`'s kind isn't Type)? After all,
> > if we have (f :: Nat), then f wouldn't range over types. Indeed, I think
> > calling an f of non-Type kind something other than a type variable would be
> > an improvement. I don't have a great suggestion of what we should call it,
> > though.
> >
> 
> I think the current terminology works just fine and we don't need to keep
> inventing new names.
> 
> >   * are type functions really type constructors?
> >
> > I'm not sure what this means. Right now, if we have `type family F a`,
> > then F isn't really a type constructor, as we can't ever write a plain F in
> > a Haskell program.
> >
> > I was referring to the fact that some type functions meet your definition
> of a type constructor: when applied to enough arguments they produce
> something of kind `Type`.
> 
> 
> 
> > >   * are we really suggesting that we should start supporting things like
> > `'True` at the value level?
> >
> > No. I'm suggesting that `'True` and `True` are just two different ways of
> > referring to the same thing. The former is accepted only in a type-level
> > context.
> >
> 
> I think that this is the crux of our misunderstanding: if it is really the
> same thing, then why does it have different names, and some of them are
> only available sometimes.
> In what sense does a `type data` declaration introduce a `data`
> constructor, if this `data` constructor can never be used at the value
> level (e.g., in a case statement)?
> 
> 
> > >
> > > Anyway, it seems to me that we have gone a little off-course, and these
> > changes are not really about making #106 easier to understand.
> >
> > But I think they are, for the reasons I've articulated above. The GitHub
> > trail contains several comments to the effect of "this proposal is simply a
> > change in data constructors' namespace" but the proposal describes the new
> > feature as a change to promotion.
> >
> 
> We may be able to implement this proposal as just a change to a
> data-constructor's namespace (I am not sure, last time I tried to do it, it
> seemed more complicated than this, but this was a long time ago, and I a
> much more familiar with how GHC works now).   Explaining it that way is not
> simpler, however, as this discussion has illustrated.
> 
> This is a summary:
>    * this proposal does NOT change `data` declarations---they work just
> like they do at the moment,
>    * this proposal does NOT change anything to do with promotion (or
> whatever we want to call what `DataKinds` does)
>    * this proposal DOES introduce a new language construct, `type data`,
> which looks somewhat like a `data` declaration, but it is not the same
> (e.g. no records, no strictness, unpacking, constructors can't be the same
> as the LHS, etc.)
>    * the purpose of `type data` is to declare some new type-level
> constants, that's all.
> 
> -Iavor
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From eric at seidel.io  Thu Aug 23 02:29:13 2018
From: eric at seidel.io (Eric Seidel)
Date: Wed, 22 Aug 2018 22:29:13 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <AM0PR83MB03080C92E78672259DCA10B3AD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
 <1534299393.4019762.1474430160.1C2499EB@webmail.messagingengine.com>
 <AM0PR83MB03080C92E78672259DCA10B3AD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <1534991353.1222080.1483265480.5DCA3BE2@webmail.messagingengine.com>

On Fri, Aug 17, 2018, at 06:06, Simon Peyton Jones wrote:
> Reasonable questions -- maybe put them on the GitHub thread so that 
> Arnaud can respond.
> 
> |  2. Am I correct in understanding that the only way to guarantee resource
> |  safety in this proposal is to write all allocation functions in CPS with a
> |  linear continuation? If so, this seems to be a substantial divergence from
> |  the intuitive notion of type safety.
> 
> It's more modular than that.  In the paper we give the API for mutable 
> arrays.  Yes, the ability to do in-place update on those arrays depends 
> on that API; the type system along does not guarantee it.  It's the type 
> system plus the API.   But its guarantees do not depend on *other* 
> allocators.

Interesting point about modularity. The issue really does seem to come down to the allocation functions. I suggested in my GitHub comment that perhaps we could concoct a warning to identify suspicious allocation functions. I think that would pretty much nullify this concern.

From bravit111 at gmail.com  Sat Aug 25 00:11:48 2018
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Fri, 24 Aug 2018 17:11:48 -0700
Subject: [ghc-steering-committee] Proposal: Lazy unboxed tuples / warn on
 unbanged strict patterns (#35); Recommendation, attempt 2: Accept
Message-ID: <CALpVSmNGiihVmsKveUwcjry=N86bbYS8YFde-cPoxXAxAUs5kg@mail.gmail.com>

Hi,

This is my revised recommendation for the lazy unboxed tuples proposal (
https://github.com/ghc-proposals/ghc-proposals/pull/35). It is already
implemented, and I don't see strong opposition to it, so my recommendation
is ACCEPT.

Silence is understood as agreement.

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

From rae at cs.brynmawr.edu  Mon Aug 27 21:33:26 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 27 Aug 2018 17:33:26 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
Message-ID: <800CB89E-6D3C-4291-B8C9-132D6B880379@cs.brynmawr.edu>

Let's keep the conversation going here. I know this is a *big* proposal, but we owe it to the authors to form a quorum-based consensus (I'd love more voices in these threads!) and offer a response.

> On Aug 7, 2018, at 1:50 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> The main high level concern I have is the overloading of the function space arrow.  We already have it overloaded in all kinds of ways, and adding one more dimension without any kind of underlying system seems too much.  I am not at all convinced that we will be able to "hide" multiplicities when the extension is not enabled.

I agree. I've mused about making (->) be indexed by a type-level record. Right now, that record would look like

> data ArrowIndex = ArrowIndex { argRep :: RuntimeRep, resRep :: RuntimeRep }
> (->) :: forall (ind :: ArrowIndex). TYPE (argRep ind) -> TYPE (resRep ind) -> Type

With this proposal, we move up to

> data ArrowIndex = ArrowIndex { argRep :: RuntimeRep, resRep :: RuntimeRep, multiplicity :: Multiplicity }
> (->) :: forall (ind :: ArrowIndex). TYPE (argRep ind) -> TYPE (resRep ind) -> Type

But I don't have great ideas of how to make this work syntactically -- never mind the fact we don't have type-level records yet.

> 
> Overall, while I like the core ideas, I would prefer a different way of integrating them into Haskell, one that is more modular, even at the cost of having to duplicate some code.  My reasoning is that while linearity might be useful in some cases, most of the time it is not something that we'd care about much, so we should not add it (at least straight away) to the core part of the language (functions and data types).

Is this essentially proposing that we don't make any change to datatypes? That would mean that a library that wishes to have linear datatypes would have to explicitly declare them as such. I think this is a stable middle ground. But, if we can guarantee good error-message behavior, etc., I think the "default datatypes to linear" behavior is the right one.

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

From eric at seidel.io  Tue Aug 28 00:16:10 2018
From: eric at seidel.io (Eric Seidel)
Date: Mon, 27 Aug 2018 20:16:10 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <800CB89E-6D3C-4291-B8C9-132D6B880379@cs.brynmawr.edu>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
 <800CB89E-6D3C-4291-B8C9-132D6B880379@cs.brynmawr.edu>
Message-ID: <1535415370.2195120.1488079448.04E6E405@webmail.messagingengine.com>

On Mon, Aug 27, 2018, at 17:33, Richard Eisenberg wrote:
> > On Aug 7, 2018, at 1:50 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> > The main high level concern I have is the overloading of the function space arrow.  We already have it overloaded in all kinds of ways, and adding one more dimension without any kind of underlying system seems too much.  I am not at all convinced that we will be able to "hide" multiplicities when the extension is not enabled.
> 
> I agree. I've mused about making (->) be indexed by a type-level record. 

This is diverging a bit from the actual proposal, but I'm not convinced that the record index buys us much. The various overloadings of the function arrow add syntactic overhead that a record index could alleviate, but I'd be more concerned about the cognitive overhead.

That being said, I'm less concerned about the overloading of the function arrow because Simon seems confident that we can reliably hide it when -XLinearTypes is disabled, even if datatypes are inferred linear. That makes it opt-in complexity, which I don't have a problem with.

> > Overall, while I like the core ideas, I would prefer a different way of integrating them into Haskell, one that is more modular, even at the cost of having to duplicate some code.  My reasoning is that while linearity might be useful in some cases, most of the time it is not something that we'd care about much, so we should not add it (at least straight away) to the core part of the language (functions and data types).
> 
> Is this essentially proposing that we don't make any change to 
> datatypes? That would mean that a library that wishes to have linear 
> datatypes would have to explicitly declare them as such. I think this is 
> a stable middle ground. But, if we can guarantee good error-message 
> behavior, etc., I think the "default datatypes to linear" behavior is 
> the right one.

Agreed completely.

From rae at cs.brynmawr.edu  Tue Aug 28 02:54:32 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 27 Aug 2018 22:54:32 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <1535415370.2195120.1488079448.04E6E405@webmail.messagingengine.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
 <800CB89E-6D3C-4291-B8C9-132D6B880379@cs.brynmawr.edu>
 <1535415370.2195120.1488079448.04E6E405@webmail.messagingengine.com>
Message-ID: <BE7A7F4A-07C0-4BE2-A6C1-BDFC5F62C1B4@cs.brynmawr.edu>



> On Aug 27, 2018, at 8:16 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> That being said, I'm less concerned about the overloading of the function arrow because Simon seems confident that we can reliably hide it when -XLinearTypes is disabled, even if datatypes are inferred linear. That makes it opt-in complexity, which I don't have a problem with.

I agree that this is opt-in complexity. The problem is that you can't opt-in partially. That is, if someone doesn't care about levity polymorphism or multiplicity polymorphism, then they're OK. If someone cares about both, they're OK. But if someone cares only about one (which is quite sensible in either direction), then they currently have to care about both. If we imagine yet more indices on arrows (e.g. what if we track whether term-level functions are injective? what if we put roles on arrows? both are conceivable) then the situation is worse. Now might be the right time to think about a structure where we can continue to add indices to arrows without overwhelming the cognitive load.

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

From simonpj at microsoft.com  Tue Aug 28 10:49:52 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 28 Aug 2018 10:49:52 +0000
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <800CB89E-6D3C-4291-B8C9-132D6B880379@cs.brynmawr.edu>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
 <800CB89E-6D3C-4291-B8C9-132D6B880379@cs.brynmawr.edu>
Message-ID: <AM0PR83MB0308D8797B877B00B72269E6AD0A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Is this essentially proposing that we don't make any change to datatypes? That would mean that a library that wishes to have linear datatypes would have to explicitly declare them as such. I think this is a stable middle ground.

Are you proposing that pairs, lists, Maybe etc all have non-linear types?   Thus Just :: a -> Maybe a.  That would negate one of the principal merits of the proposal, namely that it allows all the existing data types and library functions to work for linear types too.    We don't want to force people to implement carbon copies of existing libraries!

I think we want both (Just :: a -o Maybe a) and (fromJust :: Maybe a -o a); but suppressing the lollipops when printing for the user unless -XLinear is on.

That is, without -XLinear we behave as if the Prelude data types were ordinary pre-linear types; but when you switch -XLinear on, you see that the Prelude types are in fact linear, so that they are useful in a linear setting.

Or am I misunderstanding the "stable middle ground"?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 27 August 2018 22:33
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types

Let's keep the conversation going here. I know this is a *big* proposal, but we owe it to the authors to form a quorum-based consensus (I'd love more voices in these threads!) and offer a response.


On Aug 7, 2018, at 1:50 AM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

The main high level concern I have is the overloading of the function space arrow.  We already have it overloaded in all kinds of ways, and adding one more dimension without any kind of underlying system seems too much.  I am not at all convinced that we will be able to "hide" multiplicities when the extension is not enabled.

I agree. I've mused about making (->) be indexed by a type-level record. Right now, that record would look like

> data ArrowIndex = ArrowIndex { argRep :: RuntimeRep, resRep :: RuntimeRep }
> (->) :: forall (ind :: ArrowIndex). TYPE (argRep ind) -> TYPE (resRep ind) -> Type

With this proposal, we move up to

> data ArrowIndex = ArrowIndex { argRep :: RuntimeRep, resRep :: RuntimeRep, multiplicity :: Multiplicity }
> (->) :: forall (ind :: ArrowIndex). TYPE (argRep ind) -> TYPE (resRep ind) -> Type

But I don't have great ideas of how to make this work syntactically -- never mind the fact we don't have type-level records yet.



Overall, while I like the core ideas, I would prefer a different way of integrating them into Haskell, one that is more modular, even at the cost of having to duplicate some code.  My reasoning is that while linearity might be useful in some cases, most of the time it is not something that we'd care about much, so we should not add it (at least straight away) to the core part of the language (functions and data types).

Is this essentially proposing that we don't make any change to datatypes? That would mean that a library that wishes to have linear datatypes would have to explicitly declare them as such. I think this is a stable middle ground. But, if we can guarantee good error-message behavior, etc., I think the "default datatypes to linear" behavior is the right one.

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

From rae at cs.brynmawr.edu  Tue Aug 28 13:26:45 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 28 Aug 2018 09:26:45 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <AM0PR83MB0308D8797B877B00B72269E6AD0A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
 <800CB89E-6D3C-4291-B8C9-132D6B880379@cs.brynmawr.edu>
 <AM0PR83MB0308D8797B877B00B72269E6AD0A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <1504EBFE-ADB7-4FD3-83FC-473C87639303@cs.brynmawr.edu>



> On Aug 28, 2018, at 6:49 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> Is this essentially proposing that we don't make any change to datatypes? That would mean that a library that wishes to have linear datatypes would have to explicitly declare them as such. I think this is a stable middle ground.
>  
> Are you proposing that pairs, lists, Maybe etc all have non-linear types? 

I'm not proposing this -- I was trying to interpret Iavor's paragraph:

> Overall, while I like the core ideas, I would prefer a different way of integrating them into Haskell, one that is more modular, even at the cost of having to duplicate some code.  My reasoning is that while linearity might be useful in some cases, most of the time it is not something that we'd care about much, so we should not add it (at least straight away) to the core part of the language (functions and data types).


My "stable middle ground" comment is that such a design would work: be type-safe, expressive, etc. I don't think it's ergonomic, for the reasons you describe.
>  
> I think we want both (Just :: a -o Maybe a) and (fromJust :: Maybe a -o a); but suppressing the lollipops when printing for the user unless -XLinear is on.

Why fromJust? My understanding is that this proposal comes with no changes to `base`, meaning we would retain the existing fromJust.

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

From iavor.diatchki at gmail.com  Tue Aug 28 14:06:09 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 28 Aug 2018 17:06:09 +0300
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <AM0PR83MB0308D8797B877B00B72269E6AD0A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
 <800CB89E-6D3C-4291-B8C9-132D6B880379@cs.brynmawr.edu>
 <AM0PR83MB0308D8797B877B00B72269E6AD0A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nurkCbwO8E4bsR7LzTUUwZM1uchBKxtQEHa9XjK-t1pr7A@mail.gmail.com>

I am not really making a proposal, but I was suggesting that it might be a
simpler way to at least start experimenting with the proposal, without
having to change the types of core Haskell concepts.

The pain of duplicating some libraries would depend on how commonly one
needs the linearity.

I do agree that it is nicer to avoid the duplication, my concern is that
the arrow story is getting quite complex. Perhaps we should view this as a
future challenge to solve and not as a blocker, I am not sure.

By the way, if this is all implemented, it would be interesting to run the
linear GHC on the standard libraries and see what types are inferred for
the various commonly used functions.

Iavor


On Tue, Aug 28, 2018, 1:49 PM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Is this essentially proposing that we don't make any change to datatypes?
> That would mean that a library that wishes to have linear datatypes would
> have to explicitly declare them as such. I think this is a stable middle
> ground.
>
>
>
> Are you proposing that pairs, lists, Maybe etc all have *non-linear*
> types?   Thus Just :: a -> Maybe a.  That would negate one of the principal
> merits of the proposal, namely that it allows all the *existing* data
> types and library functions to work for linear types too.    We don’t want
> to force people to implement carbon copies of existing libraries!
>
>
>
> I think we want both (Just :: a -o Maybe a) and (fromJust :: Maybe a -o
> a); but suppressing the lollipops when printing for the user unless
> -XLinear is on.
>
>
>
> That is, without -XLinear we behave as if the Prelude data types were
> ordinary pre-linear types; but when you switch -XLinear on, you see that
> the Prelude types are in fact linear, so that they are useful in a linear
> setting.
>
>
>
> Or am I misunderstanding the “stable middle ground”?
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Richard Eisenberg
> *Sent:* 27 August 2018 22:33
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Proposal #111: Linear Types
>
>
>
> Let's keep the conversation going here. I know this is a *big* proposal,
> but we owe it to the authors to form a quorum-based consensus (I'd love
> more voices in these threads!) and offer a response.
>
>
>
> On Aug 7, 2018, at 1:50 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>
>
> The main high level concern I have is the overloading of the function
> space arrow.  We already have it overloaded in all kinds of ways, and
> adding one more dimension without any kind of underlying system seems too
> much.  I am not at all convinced that we will be able to "hide"
> multiplicities when the extension is not enabled.
>
>
>
> I agree. I've mused about making (->) be indexed by a type-level record.
> Right now, that record would look like
>
>
>
> > data ArrowIndex = ArrowIndex { argRep :: RuntimeRep, resRep ::
> RuntimeRep }
>
> > (->) :: forall (ind :: ArrowIndex). TYPE (argRep ind) -> TYPE (resRep
> ind) -> Type
>
>
>
> With this proposal, we move up to
>
>
>
> > data ArrowIndex = ArrowIndex { argRep :: RuntimeRep, resRep ::
> RuntimeRep, multiplicity :: Multiplicity }
>
> > (->) :: forall (ind :: ArrowIndex). TYPE (argRep ind) -> TYPE (resRep
> ind) -> Type
>
>
>
> But I don't have great ideas of how to make this work syntactically --
> never mind the fact we don't have type-level records yet.
>
>
>
>
>
> Overall, while I like the core ideas, I would prefer a different way of
> integrating them into Haskell, one that is more modular, even at the cost
> of having to duplicate some code.  My reasoning is that while linearity
> might be useful in some cases, most of the time it is not something that
> we'd care about much, so we should not add it (at least straight away) to
> the core part of the language (functions and data types).
>
>
>
> Is this essentially proposing that we don't make any change to datatypes?
> That would mean that a library that wishes to have linear datatypes would
> have to explicitly declare them as such. I think this is a stable middle
> ground. But, if we can guarantee good error-message behavior, etc., I think
> the "default datatypes to linear" behavior is the right one.
>
>
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180828/73f3552d/attachment.html>

From simonpj at microsoft.com  Tue Aug 28 16:17:26 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 28 Aug 2018 16:17:26 +0000
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <1504EBFE-ADB7-4FD3-83FC-473C87639303@cs.brynmawr.edu>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CAGK9nuo2KzFci5di1DXDLJbt57snZGemZ_2gFfHzcAJ8a8_ruA@mail.gmail.com>
 <800CB89E-6D3C-4291-B8C9-132D6B880379@cs.brynmawr.edu>
 <AM0PR83MB0308D8797B877B00B72269E6AD0A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <1504EBFE-ADB7-4FD3-83FC-473C87639303@cs.brynmawr.edu>
Message-ID: <AM0PR83MB03086F42873FE230291A8A36AD0A0@AM0PR83MB0308.EURPRD83.prod.outlook.com>

Overall, while I like the core ideas, I would prefer a different way of integrating them into Haskell, one that is more modular, even at the cost of having to duplicate some code.

It's hard to argue that a different way of integrating linear types into Haskell could not be superior.    Perhaps it could!  But we can't tell without saying what that different way is.

Later Iavor says

I am not really making a proposal, but I was suggesting that it might be a simpler way to at least start experimenting with the proposal, without having to change the types of core Haskell concepts.

What is "it" that might be simpler?  I genuinely want to understand what you have in mind, because I want to be sure that I'm thinking about the same design choices that you are.

Simon


From: Richard Eisenberg <rae at cs.brynmawr.edu>
Sent: 28 August 2018 14:27
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Iavor Diatchki <iavor.diatchki at gmail.com>; ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types




On Aug 28, 2018, at 6:49 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

Is this essentially proposing that we don't make any change to datatypes? That would mean that a library that wishes to have linear datatypes would have to explicitly declare them as such. I think this is a stable middle ground.

Are you proposing that pairs, lists, Maybe etc all have non-linear types?

I'm not proposing this -- I was trying to interpret Iavor's paragraph:

Overall, while I like the core ideas, I would prefer a different way of integrating them into Haskell, one that is more modular, even at the cost of having to duplicate some code.  My reasoning is that while linearity might be useful in some cases, most of the time it is not something that we'd care about much, so we should not add it (at least straight away) to the core part of the language (functions and data types).

My "stable middle ground" comment is that such a design would work: be type-safe, expressive, etc. I don't think it's ergonomic, for the reasons you describe.

I think we want both (Just :: a -o Maybe a) and (fromJust :: Maybe a -o a); but suppressing the lollipops when printing for the user unless -XLinear is on.

Why fromJust? My understanding is that this proposal comes with no changes to `base`, meaning we would retain the existing fromJust.

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

From rae at cs.brynmawr.edu  Tue Aug 28 20:41:47 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 28 Aug 2018 16:41:47 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
	Promotion (#106)
In-Reply-To: <1534857494.2034461.1481235360.7051A7E7@webmail.messagingengine.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
 <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
 <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>
 <1534857494.2034461.1481235360.7051A7E7@webmail.messagingengine.com>
Message-ID: <B81C5064-6B76-435A-B9BC-8E19FB5ECDCD@cs.brynmawr.edu>

OK. I'm convinced now that I should seek further and wider community feedback before pushing through this terminology change. A proposal may be the right way to do that, though it doesn't quite fit within the proposal-process remit.

Given this, I withdraw my objections and support the current proposal.

Richard

> On Aug 21, 2018, at 9:18 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> Thanks Iavor and Richard for your comments. This whole discussion has been quite illuminating to me as well. (The more I sleep on it, the more I feel swayed by Richard's perspective.)
> 
> That being said, I don't think this proposal is the right place to settle the issue. I think my recommendation at this point would be to:
> 
> 1. Accept the proposal as is. It uses standard terminology, and within that framework I think it is quite clear.
> 2. Encourage Richard to write up another proposal to discuss the broader terminology issue. It seems like ghc-proposals would actually be a natural place to discuss this further. It doesn't really affect the implementation, but it would have a big impact on the Manual.
> 
> On Tue, Aug 21, 2018, at 01:47, Iavor Diatchki wrote:
>> Hello,
>> 
>> On Tue, Aug 21, 2018 at 7:06 AM Richard Eisenberg <rae at cs.brynmawr.edu>
>> wrote:
>> 
>>> 
>>>> 
>>>> Here are some things to think about, if such a proposal is ever written:
>>>>  * in this new terminology `4` is not a type, but it also does not fall
>>> in any of the other categories, so what is it?
>>> 
>>> It's type-level data.
>>> 
>>> Why? it is not introduced by a `data` declaration.
>> 
>> 
>> 
>>>>  * how about `Eq`?
>>> 
>>> It's a "constraint constructor", a generalization of a type class.
>>> 
>>> Yes, we could refer to the things that construct types of kind K, as
>> K-constructors, and indeed sometimes people do.   This is consistent, for
>> example we could say that `4` is a `Nat` constructor.  However, it is also
>> convenient to have the concept of a "type constructor", which ranges over
>> all of these things, independent of what their kind is.   And, the question
>> of how they were introduced (through a `data` declaration, a class, as a
>> primitive or in some other way) is often completely irrelevant.
>> 
>> 
>>>  * how about a type variable `f`?
>>> 
>>> It's a type variable. But this is a great question: should it be something
>>> else, perhaps a quantified variable (if `f`'s kind isn't Type)? After all,
>>> if we have (f :: Nat), then f wouldn't range over types. Indeed, I think
>>> calling an f of non-Type kind something other than a type variable would be
>>> an improvement. I don't have a great suggestion of what we should call it,
>>> though.
>>> 
>> 
>> I think the current terminology works just fine and we don't need to keep
>> inventing new names.
>> 
>>>  * are type functions really type constructors?
>>> 
>>> I'm not sure what this means. Right now, if we have `type family F a`,
>>> then F isn't really a type constructor, as we can't ever write a plain F in
>>> a Haskell program.
>>> 
>>> I was referring to the fact that some type functions meet your definition
>> of a type constructor: when applied to enough arguments they produce
>> something of kind `Type`.
>> 
>> 
>> 
>>>>  * are we really suggesting that we should start supporting things like
>>> `'True` at the value level?
>>> 
>>> No. I'm suggesting that `'True` and `True` are just two different ways of
>>> referring to the same thing. The former is accepted only in a type-level
>>> context.
>>> 
>> 
>> I think that this is the crux of our misunderstanding: if it is really the
>> same thing, then why does it have different names, and some of them are
>> only available sometimes.
>> In what sense does a `type data` declaration introduce a `data`
>> constructor, if this `data` constructor can never be used at the value
>> level (e.g., in a case statement)?
>> 
>> 
>>>> 
>>>> Anyway, it seems to me that we have gone a little off-course, and these
>>> changes are not really about making #106 easier to understand.
>>> 
>>> But I think they are, for the reasons I've articulated above. The GitHub
>>> trail contains several comments to the effect of "this proposal is simply a
>>> change in data constructors' namespace" but the proposal describes the new
>>> feature as a change to promotion.
>>> 
>> 
>> We may be able to implement this proposal as just a change to a
>> data-constructor's namespace (I am not sure, last time I tried to do it, it
>> seemed more complicated than this, but this was a long time ago, and I a
>> much more familiar with how GHC works now).   Explaining it that way is not
>> simpler, however, as this discussion has illustrated.
>> 
>> This is a summary:
>>   * this proposal does NOT change `data` declarations---they work just
>> like they do at the moment,
>>   * this proposal does NOT change anything to do with promotion (or
>> whatever we want to call what `DataKinds` does)
>>   * this proposal DOES introduce a new language construct, `type data`,
>> which looks somewhat like a `data` declaration, but it is not the same
>> (e.g. no records, no strictness, unpacking, constructors can't be the same
>> as the LHS, etc.)
>>   * the purpose of `type data` is to declare some new type-level
>> constants, that's all.
>> 
>> -Iavor
>> _______________________________________________
>> 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 bravit111 at gmail.com  Wed Aug 29 01:32:40 2018
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Tue, 28 Aug 2018 18:32:40 -0700
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
Message-ID: <CALpVSmOuLJKG2LPghe+hee-U=uVgCQ0PR9pPq+SNL4_HWJueug@mail.gmail.com>

The proposal mentions pedagogy at least twice. As an educator I'd like to
raise my voice in this discussion.

1) The proposal says
However, for pedagogical reasons, to prevent linear types from interfering
with newcomers' understanding of the Prelude, this proposal does not modify
base. Instead, we expect that users will publish new libraries on Hackage
including more precisely typed base functions.

I believe these reasons are somewhat misleading. I am not sure that not
having linear arrows in base is better than having another "better" base
with linear arrows there. Anyway, authors says that it's inevitable to
change type of ($). Well, why not change other functions then? As long as
authors struggle for hiding linear arrows in printing it's perfectly
alright to have that stuff in base thus avoiding having another base.

2) I'd like to see examples of :type output and error messages in the
absence of -XLinearTypes in the proposal. These examples should be
respected then very carefully in the implementation. I am not satisfied
with the guarantees given in
 This proposal tries hard to make the changes unintrusive to newcomers, or
indeed to the existing language ecosystem as a whole.

As for the committee recommendation, I don't understand the meaning of "the
road towards acceptance". Doesn't it mean discussing the proposal forever?
I think we should accept it instead as it is or at least set strict
timeframe for the final decision.

Regards,
Vitaly

On Thu, Aug 2, 2018 at 3:41 PM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> Conversation seems to have died down on this trail, both on GitHub and
> here in committee. As the shepherd, it's my job to kick us back into action.
>
> After much conversation on GitHub, there are still a few dangling loose
> ends to this proposal:
>
> - The proposal defined *consume exactly once*, but I don't that definition
> is fully correct and it's not general enough. For example, it doesn't treat
> abstract types or unboxed ones. Simon has suggested that it's meant purely
> for intuition (for which it works well) but is not meant to be a technical
> specification. The other proposal authors seem to disagree with this, but
> I'm yet to be satisfied by an attempt at defining this.
>
> - The proposal says nothing on the subject of type inference. This is
> understandable, because it's really hard to know what will work best.
> However, there has not yet been a commitment that type inference will be
> backward-compatible. The authors want the presence/absence of -XLinearTypes
> not to affect type inference, and they also want sometimes to infer linear
> types. I think these, together, imply that the proposal isn't fully
> backward compatible. See
> https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-406723478
>
> - The proposal mentions the idea of unification of multiplicities up to
> semiring equalities, but then the authors claim that such a procedure is
> undecidable. It's unclear where this stands.
>
> - There is no design that will stop Haskell learners from seeing linear
> types in error messages, though it appears they won't appear with :type.
>
> - Simon M has pushed on the motivations of the proposal, trying to
> understand better exactly what problems this proposal solves. I have not
> followed this sub-thread terribly closely, and will take advantage of the
> fact that Simon is on this committee and can speak for himself on these
> issues.
>
> Despite these dangling pieces, I do think they all can be resolved.
> (Except perhaps the motivation piece if it's problematic enough.) I thus
> recommend that we officially encourage this proposal on the road toward
> acceptance. This recommendation is based on the excitement in the community
> around linear types and the high degree of effort and commitment the
> authors have shown.
>
> If you disagree with this recommendation, please speak up. As usual, I
> will take silence as agreement and make an official pronouncement to the
> authors in due course.
>
> Thanks,
> Richard
>
> On Jul 8, 2018, at 11:41 PM, 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 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/20180828/dee95c12/attachment.html>

From rae at cs.brynmawr.edu  Wed Aug 29 02:39:31 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 28 Aug 2018 22:39:31 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <CALpVSmOuLJKG2LPghe+hee-U=uVgCQ0PR9pPq+SNL4_HWJueug@mail.gmail.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CALpVSmOuLJKG2LPghe+hee-U=uVgCQ0PR9pPq+SNL4_HWJueug@mail.gmail.com>
Message-ID: <9909B75D-17CD-4AEA-8988-7B6F20C4AEED@cs.brynmawr.edu>



> On Aug 28, 2018, at 9:32 PM, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> 
> I don't understand the meaning of "the road towards acceptance". Doesn't it mean discussing the proposal forever? I think we should accept it instead as it is or at least set strict timeframe for the final decision.

This is a good point. The truth is that the committee has no experience dealing with a proposal of the size of this one. It's hard (for me) to accept this proposal as is, because it's not a full specification. The big missing piece is inference. We also don't have a solid description of how much complexity the implementation will have to adopt. Yet, it would be very unfortunate for the authors to put in a ton of time into writing a paper, a proposal, and a prototype implementation only to get turned down. So, my understanding is that I'm recommending something of a conditional acceptance: we say, as a committee, that we're pleased with the general direction of travel and to encourage the authors to keep working. This means that we expect to accept, barring something large and unforeseen. The difference between conditional acceptance and outright acceptance is that it gives the committee further opportunities to suggest amendments to the proposed change. (Even an accepted proposal can effectively get retroactively denied if, say, the implementation requires a 10% slowdown on all programs to support an esoteric feature.)

Does this help to clarify?

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

From bravit111 at gmail.com  Wed Aug 29 05:39:47 2018
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Tue, 28 Aug 2018 22:39:47 -0700
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <9909B75D-17CD-4AEA-8988-7B6F20C4AEED@cs.brynmawr.edu>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CALpVSmOuLJKG2LPghe+hee-U=uVgCQ0PR9pPq+SNL4_HWJueug@mail.gmail.com>
 <9909B75D-17CD-4AEA-8988-7B6F20C4AEED@cs.brynmawr.edu>
Message-ID: <CALpVSmMfga93b3CJJWG-=wMnzYbO0Egw-at2r-ufxxhEeEX9Ww@mail.gmail.com>

Now I get it, thank you for clarification. I agree with your
recommendation.

Vitaly

вт, 28 авг. 2018 г., 19:39 Richard Eisenberg <rae at cs.brynmawr.edu>:

>
>
> On Aug 28, 2018, at 9:32 PM, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
>
> I don't understand the meaning of "the road towards acceptance". Doesn't
> it mean discussing the proposal forever? I think we should accept it
> instead as it is or at least set strict timeframe for the final decision.
>
>
> This is a good point. The truth is that the committee has no experience
> dealing with a proposal of the size of this one. It's hard (for me) to
> accept this proposal as is, because it's not a full specification. The big
> missing piece is inference. We also don't have a solid description of how
> much complexity the implementation will have to adopt. Yet, it would be
> very unfortunate for the authors to put in a ton of time into writing a
> paper, a proposal, and a prototype implementation only to get turned down.
> So, my understanding is that I'm recommending something of a conditional
> acceptance: we say, as a committee, that we're pleased with the general
> direction of travel and to encourage the authors to keep working. This
> means that we expect to accept, barring something large and unforeseen. The
> difference between conditional acceptance and outright acceptance is that
> it gives the committee further opportunities to suggest amendments to the
> proposed change. (Even an accepted proposal can effectively get
> retroactively denied if, say, the implementation requires a 10% slowdown on
> all programs to support an esoteric feature.)
>
> Does this help to clarify?
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180828/0acb9ab0/attachment.html>

From iavor.diatchki at gmail.com  Wed Aug 29 06:50:30 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 29 Aug 2018 09:50:30 +0300
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <CALpVSmMfga93b3CJJWG-=wMnzYbO0Egw-at2r-ufxxhEeEX9Ww@mail.gmail.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CALpVSmOuLJKG2LPghe+hee-U=uVgCQ0PR9pPq+SNL4_HWJueug@mail.gmail.com>
 <9909B75D-17CD-4AEA-8988-7B6F20C4AEED@cs.brynmawr.edu>
 <CALpVSmMfga93b3CJJWG-=wMnzYbO0Egw-at2r-ufxxhEeEX9Ww@mail.gmail.com>
Message-ID: <CAGK9nurmWBn6kLAO3AU+JEvN9cF1d0ZR5_LwECZmN4UKw1gxtw@mail.gmail.com>

I was thinking about a design where the linear arrow is a completely
separate type than the normal function type.

 I think that a choice like that would probably require additional
annotations on other declarations to indicate when the linear machinery
would kick in.

For examplee, `data` declarations would need an extra tag to indicate that
we should generate linear constructors, pattern matching, and single field
selectors.

Similarly, to declare linear functions we would either require a type
signature, or some sort of a tag on the lambda/function declaration to
indicate that it is linear.

I haven't thought through all the details but this is what I was thinking
about.

Essentially, the difference is that the current proposal keeps track of
these tags automatically in the multiplicity of the function space and I
was thinking of a design where these things are specified manually.

I imagine the biggest trade off is that the current proposal allows for
polymorphism in the multiplicity, while I was thinking maybe we could start
without.

I am not arguing for this alternative design as I haven't really thought
through all the details.  I was just thinking of alternatives that leave
the current function space alone.

As I said before, though, perhaps we should not worry that much about the
function space, and just go for it.

I have some comments on the type functions for multiplicities, but I'll
write them in the git hub.

Iavor





On Wed, Aug 29, 2018, 8:40 AM Vitaly Bragilevsky <bravit111 at gmail.com>
wrote:

> Now I get it, thank you for clarification. I agree with your
> recommendation.
>
> Vitaly
>
> вт, 28 авг. 2018 г., 19:39 Richard Eisenberg <rae at cs.brynmawr.edu>:
>
>>
>>
>> On Aug 28, 2018, at 9:32 PM, Vitaly Bragilevsky <bravit111 at gmail.com>
>> wrote:
>>
>> I don't understand the meaning of "the road towards acceptance". Doesn't
>> it mean discussing the proposal forever? I think we should accept it
>> instead as it is or at least set strict timeframe for the final decision.
>>
>>
>> This is a good point. The truth is that the committee has no experience
>> dealing with a proposal of the size of this one. It's hard (for me) to
>> accept this proposal as is, because it's not a full specification. The big
>> missing piece is inference. We also don't have a solid description of how
>> much complexity the implementation will have to adopt. Yet, it would be
>> very unfortunate for the authors to put in a ton of time into writing a
>> paper, a proposal, and a prototype implementation only to get turned down.
>> So, my understanding is that I'm recommending something of a conditional
>> acceptance: we say, as a committee, that we're pleased with the general
>> direction of travel and to encourage the authors to keep working. This
>> means that we expect to accept, barring something large and unforeseen. The
>> difference between conditional acceptance and outright acceptance is that
>> it gives the committee further opportunities to suggest amendments to the
>> proposed change. (Even an accepted proposal can effectively get
>> retroactively denied if, say, the implementation requires a 10% slowdown on
>> all programs to support an esoteric feature.)
>>
>> Does this help to clarify?
>>
>> 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/20180829/a1d0e65f/attachment.html>

From simonpj at microsoft.com  Wed Aug 29 07:47:00 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 29 Aug 2018 07:47:00 +0000
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <CAGK9nurmWBn6kLAO3AU+JEvN9cF1d0ZR5_LwECZmN4UKw1gxtw@mail.gmail.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CALpVSmOuLJKG2LPghe+hee-U=uVgCQ0PR9pPq+SNL4_HWJueug@mail.gmail.com>
 <9909B75D-17CD-4AEA-8988-7B6F20C4AEED@cs.brynmawr.edu>
 <CALpVSmMfga93b3CJJWG-=wMnzYbO0Egw-at2r-ufxxhEeEX9Ww@mail.gmail.com>
 <CAGK9nurmWBn6kLAO3AU+JEvN9cF1d0ZR5_LwECZmN4UKw1gxtw@mail.gmail.com>
Message-ID: <AM0PR83MB03086E32EEC7E35FD099ED8BAD090@AM0PR83MB0308.EURPRD83.prod.outlook.com>

I imagine the biggest trade off is that the current proposal allows for polymorphism in the multiplicity, while I was thinking maybe we could start without.
Yes, that’s a total killer.  Polymorphism is absolutely central to the design.  I don’t think the design would hold water at all with two distinct function arrows.

As I said before, though, perhaps we should not worry that much about the function space, and just go for it.
I support that (albeit of course I have an interest in this, as a co-author).

I’m imagining that, absent -XLinearTypes, we would suppress (a) linearity polymorphism (b) -o (printing it as -> instead.   Every program that is accepted today would still be accepted.    So the extra polymorphism in the function space would be invisible.

Where would you get a bump in that road?  Imagine you imported a function with type
              f :: (Int -o Int) -> Int
and applied it to a function that did not have linear type. Now, we MUST produce a type error: the imported function f may rely on the linearity of its argument.  But note that this could not happen without compiling f with -XLinearTypes.  So, if you don’t use -XLinearTypes, you won’t see any bumps.

Of course that’s an informal argument.  Let’s see.  But it convinces me enough to accept the proposal – subject (as Richard says, and true of any proposal) it later turns out to have unforeseen but unacceptable consequences.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 29 August 2018 07:51
To: Vitaly Bragilevsky <bravit111 at gmail.com>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Proposal #111: Linear Types

I was thinking about a design where the linear arrow is a completely separate type than the normal function type.

 I think that a choice like that would probably require additional annotations on other declarations to indicate when the linear machinery would kick in.

For examplee, `data` declarations would need an extra tag to indicate that we should generate linear constructors, pattern matching, and single field selectors.

Similarly, to declare linear functions we would either require a type signature, or some sort of a tag on the lambda/function declaration to indicate that it is linear.

I haven't thought through all the details but this is what I was thinking about.

Essentially, the difference is that the current proposal keeps track of these tags automatically in the multiplicity of the function space and I was thinking of a design where these things are specified manually.

I imagine the biggest trade off is that the current proposal allows for polymorphism in the multiplicity, while I was thinking maybe we could start without.

I am not arguing for this alternative design as I haven't really thought through all the details.  I was just thinking of alternatives that leave the current function space alone.

As I said before, though, perhaps we should not worry that much about the function space, and just go for it.

I have some comments on the type functions for multiplicities, but I'll write them in the git hub.

Iavor




On Wed, Aug 29, 2018, 8:40 AM Vitaly Bragilevsky <bravit111 at gmail.com<mailto:bravit111 at gmail.com>> wrote:
Now I get it, thank you for clarification. I agree with your recommendation.

Vitaly
вт, 28 авг. 2018 г., 19:39 Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>>:



On Aug 28, 2018, at 9:32 PM, Vitaly Bragilevsky <bravit111 at gmail.com<mailto:bravit111 at gmail.com>> wrote:

I don't understand the meaning of "the road towards acceptance". Doesn't it mean discussing the proposal forever? I think we should accept it instead as it is or at least set strict timeframe for the final decision.

This is a good point. The truth is that the committee has no experience dealing with a proposal of the size of this one. It's hard (for me) to accept this proposal as is, because it's not a full specification. The big missing piece is inference. We also don't have a solid description of how much complexity the implementation will have to adopt. Yet, it would be very unfortunate for the authors to put in a ton of time into writing a paper, a proposal, and a prototype implementation only to get turned down. So, my understanding is that I'm recommending something of a conditional acceptance: we say, as a committee, that we're pleased with the general direction of travel and to encourage the authors to keep working. This means that we expect to accept, barring something large and unforeseen. The difference between conditional acceptance and outright acceptance is that it gives the committee further opportunities to suggest amendments to the proposed change. (Even an accepted proposal can effectively get retroactively denied if, say, the implementation requires a 10% slowdown on all programs to support an esoteric feature.)

Does this help to clarify?

Richard
_______________________________________________
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/20180829/5f7ca36b/attachment-0001.html>

From rae at cs.brynmawr.edu  Wed Aug 29 12:20:48 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Wed, 29 Aug 2018 08:20:48 -0400
Subject: [ghc-steering-committee] Proposal #111: Linear Types
In-Reply-To: <AM0PR83MB03086E32EEC7E35FD099ED8BAD090@AM0PR83MB0308.EURPRD83.prod.outlook.com>
References: <B32584B5-743E-4D36-B548-21B3A521E1D9@cs.brynmawr.edu>
 <6E28F9AA-773C-4E5E-A492-7B6C7DEE3B72@cs.brynmawr.edu>
 <CALpVSmOuLJKG2LPghe+hee-U=uVgCQ0PR9pPq+SNL4_HWJueug@mail.gmail.com>
 <9909B75D-17CD-4AEA-8988-7B6F20C4AEED@cs.brynmawr.edu>
 <CALpVSmMfga93b3CJJWG-=wMnzYbO0Egw-at2r-ufxxhEeEX9Ww@mail.gmail.com>
 <CAGK9nurmWBn6kLAO3AU+JEvN9cF1d0ZR5_LwECZmN4UKw1gxtw@mail.gmail.com>
 <AM0PR83MB03086E32EEC7E35FD099ED8BAD090@AM0PR83MB0308.EURPRD83.prod.outlook.com>
Message-ID: <22185FBA-DF89-48FD-BEAB-2DE4DA3B1275@cs.brynmawr.edu>



> On Aug 29, 2018, at 3:47 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> So the extra polymorphism in the function space would be invisible.

Not quite. It would be visible to anyone who cares about the type of (->), which would now be more elaborate. This includes people using type-level type application (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0015-type-level-type-applications.rst), whose implementation is under way by a student of mine, and anyone looking at the TypeRep of (->). I'm not overly concerned by these bumps, but I don't want to overclaim that everyone who doesn't use -XLinearTypes will be utterly unaffected.

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

From eric at seidel.io  Wed Aug 29 13:27:16 2018
From: eric at seidel.io (Eric Seidel)
Date: Wed, 29 Aug 2018 09:27:16 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <B81C5064-6B76-435A-B9BC-8E19FB5ECDCD@cs.brynmawr.edu>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
 <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
 <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>
 <1534857494.2034461.1481235360.7051A7E7@webmail.messagingengine.com>
 <B81C5064-6B76-435A-B9BC-8E19FB5ECDCD@cs.brynmawr.edu>
Message-ID: <1535549236.2892749.1490033464.30E49ABA@webmail.messagingengine.com>

Thanks Richard!

Iavor, Adam Gundry has raised a good question on the public discussion.

> This proposal doesn't seem to mention record fields. What happens if I write this?
>   type data T = MkT { foo :: Bool }
> Is this an error, or does it simply not bring foo into scope at all (at least until some hypothetical future where we can talk about record field selectors in type-level expressions)?

My inclination is that this should be an error, since there's no way to refer to the `foo` selector, but it would be good to specify the answer in the proposal.

Apart from that, I think we've reached a consensus on accepting the proposal. 

What's the next step, Joachim? Do I just mark the proposal as accepted?

On Tue, Aug 28, 2018, at 16:41, Richard Eisenberg wrote:
> OK. I'm convinced now that I should seek further and wider community 
> feedback before pushing through this terminology change. A proposal may 
> be the right way to do that, though it doesn't quite fit within the 
> proposal-process remit.
> 
> Given this, I withdraw my objections and support the current proposal.
> 
> Richard
> 
> > On Aug 21, 2018, at 9:18 AM, Eric Seidel <eric at seidel.io> wrote:
> > 
> > Thanks Iavor and Richard for your comments. This whole discussion has been quite illuminating to me as well. (The more I sleep on it, the more I feel swayed by Richard's perspective.)
> > 
> > That being said, I don't think this proposal is the right place to settle the issue. I think my recommendation at this point would be to:
> > 
> > 1. Accept the proposal as is. It uses standard terminology, and within that framework I think it is quite clear.
> > 2. Encourage Richard to write up another proposal to discuss the broader terminology issue. It seems like ghc-proposals would actually be a natural place to discuss this further. It doesn't really affect the implementation, but it would have a big impact on the Manual.
> > 
> > On Tue, Aug 21, 2018, at 01:47, Iavor Diatchki wrote:
> >> Hello,
> >> 
> >> On Tue, Aug 21, 2018 at 7:06 AM Richard Eisenberg <rae at cs.brynmawr.edu>
> >> wrote:
> >> 
> >>> 
> >>>> 
> >>>> Here are some things to think about, if such a proposal is ever written:
> >>>>  * in this new terminology `4` is not a type, but it also does not fall
> >>> in any of the other categories, so what is it?
> >>> 
> >>> It's type-level data.
> >>> 
> >>> Why? it is not introduced by a `data` declaration.
> >> 
> >> 
> >> 
> >>>>  * how about `Eq`?
> >>> 
> >>> It's a "constraint constructor", a generalization of a type class.
> >>> 
> >>> Yes, we could refer to the things that construct types of kind K, as
> >> K-constructors, and indeed sometimes people do.   This is consistent, for
> >> example we could say that `4` is a `Nat` constructor.  However, it is also
> >> convenient to have the concept of a "type constructor", which ranges over
> >> all of these things, independent of what their kind is.   And, the question
> >> of how they were introduced (through a `data` declaration, a class, as a
> >> primitive or in some other way) is often completely irrelevant.
> >> 
> >> 
> >>>  * how about a type variable `f`?
> >>> 
> >>> It's a type variable. But this is a great question: should it be something
> >>> else, perhaps a quantified variable (if `f`'s kind isn't Type)? After all,
> >>> if we have (f :: Nat), then f wouldn't range over types. Indeed, I think
> >>> calling an f of non-Type kind something other than a type variable would be
> >>> an improvement. I don't have a great suggestion of what we should call it,
> >>> though.
> >>> 
> >> 
> >> I think the current terminology works just fine and we don't need to keep
> >> inventing new names.
> >> 
> >>>  * are type functions really type constructors?
> >>> 
> >>> I'm not sure what this means. Right now, if we have `type family F a`,
> >>> then F isn't really a type constructor, as we can't ever write a plain F in
> >>> a Haskell program.
> >>> 
> >>> I was referring to the fact that some type functions meet your definition
> >> of a type constructor: when applied to enough arguments they produce
> >> something of kind `Type`.
> >> 
> >> 
> >> 
> >>>>  * are we really suggesting that we should start supporting things like
> >>> `'True` at the value level?
> >>> 
> >>> No. I'm suggesting that `'True` and `True` are just two different ways of
> >>> referring to the same thing. The former is accepted only in a type-level
> >>> context.
> >>> 
> >> 
> >> I think that this is the crux of our misunderstanding: if it is really the
> >> same thing, then why does it have different names, and some of them are
> >> only available sometimes.
> >> In what sense does a `type data` declaration introduce a `data`
> >> constructor, if this `data` constructor can never be used at the value
> >> level (e.g., in a case statement)?
> >> 
> >> 
> >>>> 
> >>>> Anyway, it seems to me that we have gone a little off-course, and these
> >>> changes are not really about making #106 easier to understand.
> >>> 
> >>> But I think they are, for the reasons I've articulated above. The GitHub
> >>> trail contains several comments to the effect of "this proposal is simply a
> >>> change in data constructors' namespace" but the proposal describes the new
> >>> feature as a change to promotion.
> >>> 
> >> 
> >> We may be able to implement this proposal as just a change to a
> >> data-constructor's namespace (I am not sure, last time I tried to do it, it
> >> seemed more complicated than this, but this was a long time ago, and I a
> >> much more familiar with how GHC works now).   Explaining it that way is not
> >> simpler, however, as this discussion has illustrated.
> >> 
> >> This is a summary:
> >>   * this proposal does NOT change `data` declarations---they work just
> >> like they do at the moment,
> >>   * this proposal does NOT change anything to do with promotion (or
> >> whatever we want to call what `DataKinds` does)
> >>   * this proposal DOES introduce a new language construct, `type data`,
> >> which looks somewhat like a `data` declaration, but it is not the same
> >> (e.g. no records, no strictness, unpacking, constructors can't be the same
> >> as the LHS, etc.)
> >>   * the purpose of `type data` is to declare some new type-level
> >> constants, that's all.
> >> 
> >> -Iavor
> >> _______________________________________________
> >> 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  Wed Aug 29 17:17:24 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 29 Aug 2018 19:17:24 +0200
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <1535549236.2892749.1490033464.30E49ABA@webmail.messagingengine.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
 <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
 <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>
 <1534857494.2034461.1481235360.7051A7E7@webmail.messagingengine.com>
 <B81C5064-6B76-435A-B9BC-8E19FB5ECDCD@cs.brynmawr.edu>
 <1535549236.2892749.1490033464.30E49ABA@webmail.messagingengine.com>
Message-ID: <fdd7994e6a7127e388698af1b77ad0c05ce5a17b.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 29.08.2018, 09:27 -0400 schrieb Eric Seidel:
> What's the next step, Joachim? Do I just mark the proposal as accepted?

yes. Or you declare it as accepted here on the mailing list, and I mark
it as such on GitHub (I have to touch it anyways, to merge it and give
it the final proposal number).

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/20180829/13bebd88/attachment.sig>

From eric at seidel.io  Wed Aug 29 17:21:36 2018
From: eric at seidel.io (Eric Seidel)
Date: Wed, 29 Aug 2018 13:21:36 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <fdd7994e6a7127e388698af1b77ad0c05ce5a17b.camel@joachim-breitner.de>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
 <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
 <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>
 <1534857494.2034461.1481235360.7051A7E7@webmail.messagingengine.com>
 <B81C5064-6B76-435A-B9BC-8E19FB5ECDCD@cs.brynmawr.edu>
 <1535549236.2892749.1490033464.30E49ABA@webmail.messagingengine.com>
 <fdd7994e6a7127e388698af1b77ad0c05ce5a17b.camel@joachim-breitner.de>
Message-ID: <1535563296.655366.1490329456.452DC380@webmail.messagingengine.com>

Ok, then I declare it accepted!

On Wed, Aug 29, 2018, at 13:17, Joachim Breitner wrote:
> Hi,
> 
> Am Mittwoch, den 29.08.2018, 09:27 -0400 schrieb Eric Seidel:
> > What's the next step, Joachim? Do I just mark the proposal as accepted?
> 
> yes. Or you declare it as accepted here on the mailing list, and I mark
> it as such on GitHub (I have to touch it anyways, to merge it and give
> it the final proposal number).
> 
> 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
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

From eric at seidel.io  Wed Aug 29 17:22:19 2018
From: eric at seidel.io (Eric Seidel)
Date: Wed, 29 Aug 2018 13:22:19 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <1535563296.655366.1490329456.452DC380@webmail.messagingengine.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
 <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
 <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>
 <1534857494.2034461.1481235360.7051A7E7@webmail.messagingengine.com>
 <B81C5064-6B76-435A-B9BC-8E19FB5ECDCD@cs.brynmawr.edu>
 <1535549236.2892749.1490033464.30E49ABA@webmail.messagingengine.com>
 <fdd7994e6a7127e388698af1b77ad0c05ce5a17b.camel@joachim-breitner.de>
 <1535563296.655366.1490329456.452DC380@webmail.messagingengine.com>
Message-ID: <1535563339.655508.1490330888.63E98E2B@webmail.messagingengine.com>

Though I'd still like to have it specify what happens with record selectors, as pointed out by Adam.

On Wed, Aug 29, 2018, at 13:21, Eric Seidel wrote:
> Ok, then I declare it accepted!
> 
> On Wed, Aug 29, 2018, at 13:17, Joachim Breitner wrote:
> > Hi,
> > 
> > Am Mittwoch, den 29.08.2018, 09:27 -0400 schrieb Eric Seidel:
> > > What's the next step, Joachim? Do I just mark the proposal as accepted?
> > 
> > yes. Or you declare it as accepted here on the mailing list, and I mark
> > it as such on GitHub (I have to touch it anyways, to merge it and give
> > it the final proposal number).
> > 
> > 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
> > Email had 1 attachment:
> > + signature.asc
> >   1k (application/pgp-signature)

From mail at joachim-breitner.de  Wed Aug 29 19:11:30 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 29 Aug 2018 21:11:30 +0200
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <1535563339.655508.1490330888.63E98E2B@webmail.messagingengine.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
 <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
 <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>
 <1534857494.2034461.1481235360.7051A7E7@webmail.messagingengine.com>
 <B81C5064-6B76-435A-B9BC-8E19FB5ECDCD@cs.brynmawr.edu>
 <1535549236.2892749.1490033464.30E49ABA@webmail.messagingengine.com>
 <fdd7994e6a7127e388698af1b77ad0c05ce5a17b.camel@joachim-breitner.de>
 <1535563296.655366.1490329456.452DC380@webmail.messagingengine.com>
 <1535563339.655508.1490330888.63E98E2B@webmail.messagingengine.com>
Message-ID: <e4552874cf271776be4829597428cbbf5b7a99e6.camel@joachim-breitner.de>

Hi,

in that case, I suggest you work with the authors to get that fixed,
and only then pronounce it accepted :-)

Cheers,
Joachim



Am Mittwoch, den 29.08.2018, 13:22 -0400 schrieb Eric Seidel:
> Though I'd still like to have it specify what happens with record selectors, as pointed out by Adam.
> 
> On Wed, Aug 29, 2018, at 13:21, Eric Seidel wrote:
> > Ok, then I declare it accepted!
> > 
> > On Wed, Aug 29, 2018, at 13:17, Joachim Breitner wrote:
> > > Hi,
> > > 
> > > Am Mittwoch, den 29.08.2018, 09:27 -0400 schrieb Eric Seidel:
> > > > What's the next step, Joachim? Do I just mark the proposal as accepted?
> > > 
> > > yes. Or you declare it as accepted here on the mailing list, and I mark
> > > it as such on GitHub (I have to touch it anyways, to merge it and give
> > > it the final proposal number).
> > > 
> > > 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
> > > Email had 1 attachment:
> > > + signature.asc
> > >   1k (application/pgp-signature)
> 
> _______________________________________________
> 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/20180829/07f4ea17/attachment-0001.sig>

From eric at seidel.io  Wed Aug 29 20:42:49 2018
From: eric at seidel.io (Eric Seidel)
Date: Wed, 29 Aug 2018 16:42:49 -0400
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
 Promotion (#106)
In-Reply-To: <e4552874cf271776be4829597428cbbf5b7a99e6.camel@joachim-breitner.de>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
 <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
 <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>
 <1534857494.2034461.1481235360.7051A7E7@webmail.messagingengine.com>
 <B81C5064-6B76-435A-B9BC-8E19FB5ECDCD@cs.brynmawr.edu>
 <1535549236.2892749.1490033464.30E49ABA@webmail.messagingengine.com>
 <fdd7994e6a7127e388698af1b77ad0c05ce5a17b.camel@joachim-breitner.de>
 <1535563296.655366.1490329456.452DC380@webmail.messagingengine.com>
 <1535563339.655508.1490330888.63E98E2B@webmail.messagingengine.com>
 <e4552874cf271776be4829597428cbbf5b7a99e6.camel@joachim-breitner.de>
Message-ID: <1535575369.710652.1490551880.0DEFABF2@webmail.messagingengine.com>

Yes, I got a bit excited to exercise my power :)

On Wed, Aug 29, 2018, at 15:11, Joachim Breitner wrote:
> Hi,
> 
> in that case, I suggest you work with the authors to get that fixed,
> and only then pronounce it accepted :-)
> 
> Cheers,
> Joachim
> 
> 
> 
> Am Mittwoch, den 29.08.2018, 13:22 -0400 schrieb Eric Seidel:
> > Though I'd still like to have it specify what happens with record selectors, as pointed out by Adam.
> > 
> > On Wed, Aug 29, 2018, at 13:21, Eric Seidel wrote:
> > > Ok, then I declare it accepted!
> > > 
> > > On Wed, Aug 29, 2018, at 13:17, Joachim Breitner wrote:
> > > > Hi,
> > > > 
> > > > Am Mittwoch, den 29.08.2018, 09:27 -0400 schrieb Eric Seidel:
> > > > > What's the next step, Joachim? Do I just mark the proposal as accepted?
> > > > 
> > > > yes. Or you declare it as accepted here on the mailing list, and I mark
> > > > it as such on GitHub (I have to touch it anyways, to merge it and give
> > > > it the final proposal number).
> > > > 
> > > > 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
> > > > Email had 1 attachment:
> > > > + signature.asc
> > > >   1k (application/pgp-signature)
> > 
> > _______________________________________________
> > 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
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

From mail at joachim-breitner.de  Thu Aug 30 05:28:52 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 30 Aug 2018 07:28:52 +0200
Subject: [ghc-steering-committee] Please Review: StableName guarantee (#163),
	Shepherd: Simon Marlow
Message-ID: <a3f158bebbaa3afb8b403b9db31ec6015bef64fe.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Remove an undocumented StableName guarantee, by David Feuer, was proposed
https://github.com/ghc-proposals/ghc-proposals/pull/163

I propose Simon Marlow as the shepherd.

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

Thanks,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180830/27869cea/attachment.sig>

From iavor.diatchki at gmail.com  Thu Aug 30 13:53:11 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 30 Aug 2018 16:53:11 +0300
Subject: [ghc-steering-committee] Proposal: Define Kinds Without
	Promotion (#106)
In-Reply-To: <1535575369.710652.1490551880.0DEFABF2@webmail.messagingengine.com>
References: <1534293119.3992207.1474414112.3E640798@webmail.messagingengine.com>
 <E7CF97ED-D82C-4EB8-85AC-2167A0DB2BB2@cs.brynmawr.edu>
 <CAGK9nupcNZNkQT=wsQU_tOHXDhEkC=SgyRLNQSMwzg9L9R5vAQ@mail.gmail.com>
 <1534463249.3187033.1476814616.5C5C1219@webmail.messagingengine.com>
 <AM0PR83MB030864F7145B901E43F3C98CAD3D0@AM0PR83MB0308.EURPRD83.prod.outlook.com>
 <66BAC73A-6A24-4652-B00E-F4237B5DF447@cs.brynmawr.edu>
 <CAGK9nupW0Fw6+ebfeVRhav9m9vks7tn-wGd0Yog34EwqocCEHw@mail.gmail.com>
 <859D625D-5E9F-4221-8438-CA9F22F31D59@cs.brynmawr.edu>
 <CAGK9nurdhBQikHde3uEV03CzRzNszP0V==B=2BSPk9OqrXC7kw@mail.gmail.com>
 <1534857494.2034461.1481235360.7051A7E7@webmail.messagingengine.com>
 <B81C5064-6B76-435A-B9BC-8E19FB5ECDCD@cs.brynmawr.edu>
 <1535549236.2892749.1490033464.30E49ABA@webmail.messagingengine.com>
 <fdd7994e6a7127e388698af1b77ad0c05ce5a17b.camel@joachim-breitner.de>
 <1535563296.655366.1490329456.452DC380@webmail.messagingengine.com>
 <1535563339.655508.1490330888.63E98E2B@webmail.messagingengine.com>
 <e4552874cf271776be4829597428cbbf5b7a99e6.camel@joachim-breitner.de>
 <1535575369.710652.1490551880.0DEFABF2@webmail.messagingengine.com>
Message-ID: <CAGK9nuo77Ge5Rt_+bmp_6pL96pfGaL3BdS_z-tf=KWEQTbVX7A@mail.gmail.com>

Indeed, record selectors are not supported in type data, and should result
in an error.  Same for other special things like strictness annotations,
unpack pragmas, and quantifiers.

 I am on vacation without a computer at the moment and I am not sure if I
can edit the proposal from my phone, but I'll give it a go later.

Iavor

On Wed, Aug 29, 2018, 11:42 PM Eric Seidel <eric at seidel.io> wrote:

> Yes, I got a bit excited to exercise my power :)
>
> On Wed, Aug 29, 2018, at 15:11, Joachim Breitner wrote:
> > Hi,
> >
> > in that case, I suggest you work with the authors to get that fixed,
> > and only then pronounce it accepted :-)
> >
> > Cheers,
> > Joachim
> >
> >
> >
> > Am Mittwoch, den 29.08.2018, 13:22 -0400 schrieb Eric Seidel:
> > > Though I'd still like to have it specify what happens with record
> selectors, as pointed out by Adam.
> > >
> > > On Wed, Aug 29, 2018, at 13:21, Eric Seidel wrote:
> > > > Ok, then I declare it accepted!
> > > >
> > > > On Wed, Aug 29, 2018, at 13:17, Joachim Breitner wrote:
> > > > > Hi,
> > > > >
> > > > > Am Mittwoch, den 29.08.2018, 09:27 -0400 schrieb Eric Seidel:
> > > > > > What's the next step, Joachim? Do I just mark the proposal as
> accepted?
> > > > >
> > > > > yes. Or you declare it as accepted here on the mailing list, and I
> mark
> > > > > it as such on GitHub (I have to touch it anyways, to merge it and
> give
> > > > > it the final proposal number).
> > > > >
> > > > > 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
> > > > > Email had 1 attachment:
> > > > > + signature.asc
> > > > >   1k (application/pgp-signature)
> > >
> > > _______________________________________________
> > > 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
> > Email had 1 attachment:
> > + signature.asc
> >   1k (application/pgp-signature)
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180830/bad78bbc/attachment.html>