From chak at justtesting.org  Thu Feb  1 00:42:00 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Thu, 1 Feb 2018 11:42:00 +1100
Subject: [ghc-steering-committee] =?utf-8?q?Proposal_=2377_=22Deprecating_?=
 =?utf-8?q?STM_invariant_mechanism=22_=E2=80=94_suggesting_acceptance?=
Message-ID: <1CF3A14F-741F-4645-AF81-84E6204AD1AA@justtesting.org>

Folks,

I’d like to reach consensus on Proposal #77 ”Deprecating STM invariant mechanism”:

  https://github.com/bgamari/ghc-proposals/blob/deprecate-stm-invariants/proposals/0000-deprecate-stm-invariants.rst

(The discussion thread is at <https://github.com/ghc-proposals/ghc-proposals/pull/77>.)

This proposal is about removing a rarely used feature that is arguably buggy and also imposes significant complexity. I think, removing ideas that turn out to be not working properly or simply aren’t sufficiently useful for the complexity they impose is an important part of the process. The STM invariant mechanism appears to fit that bill. Hence, I suggest to accept this proposal.

Please let me know if you disagree; otherwise, I will assume tacit approval.

Cheers,
Manuel


From ben at well-typed.com  Thu Feb  1 04:14:39 2018
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 31 Jan 2018 23:14:39 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=2377_=22Deprecating_?=
 =?utf-8?q?STM_invariant_mechanism=22_=E2=80=94_suggesting_acceptance?=
In-Reply-To: <1CF3A14F-741F-4645-AF81-84E6204AD1AA@justtesting.org>
References: <1CF3A14F-741F-4645-AF81-84E6204AD1AA@justtesting.org>
Message-ID: <87zi4t73dg.fsf@smart-cactus.org>

Manuel M T Chakravarty <chak at justtesting.org> writes:

> Folks,
>
> I’d like to reach consensus on Proposal #77 ”Deprecating STM invariant mechanism”:
>
>   https://github.com/bgamari/ghc-proposals/blob/deprecate-stm-invariants/proposals/0000-deprecate-stm-invariants.rst
>
> (The discussion thread is at <https://github.com/ghc-proposals/ghc-proposals/pull/77>.)
>
> This proposal is about removing a rarely used feature that is arguably
> buggy and also imposes significant complexity. I think, removing ideas
> that turn out to be not working properly or simply aren’t sufficiently
> useful for the complexity they impose is an important part of the
> process. The STM invariant mechanism appears to fit that bill. Hence,
> I suggest to accept this proposal.
>
As the author of the proposal, I second.

Cheers,

- Ben

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

From simonpj at microsoft.com  Thu Feb  1 08:15:36 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 1 Feb 2018 08:15:36 +0000
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=2377_=22Deprecating_?=
 =?utf-8?q?STM_invariant_mechanism=22_=E2=80=94_suggesting_acceptance?=
In-Reply-To: <1CF3A14F-741F-4645-AF81-84E6204AD1AA@justtesting.org>
References: <1CF3A14F-741F-4645-AF81-84E6204AD1AA@justtesting.org>
Message-ID: <VI1PR83MB0205EDEE546BF9ACEE192074ADFA0@VI1PR83MB0205.EURPRD83.prod.outlook.com>

I'm ok with removal, and there seems to be a consensus.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Manuel M T Chakravarty
|  Sent: 01 February 2018 00:42
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Proposal #77 "Deprecating STM
|  invariant mechanism" — suggesting acceptance
|  
|  Folks,
|  
|  I’d like to reach consensus on Proposal #77 ”Deprecating STM invariant
|  mechanism”:
|  
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2Fbgamari%2Fghc-proposals%2Fblob%2Fdeprecate-stm-
|  invariants%2Fproposals%2F0000-deprecate-stm-
|  invariants.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C4e98f234d33d43
|  22f53f08d5690ca443%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636530
|  425373375028&sdata=fNC1GjVg6tOSuPiw9p0G747PTSJ79E9QX7C6LrG66Qs%3D&rese
|  rved=0
|  
|  (The discussion thread is at
|  <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F77&data=02%7C01%7Csimonpj%40microsoft.com%7C4e98f23
|  4d33d4322f53f08d5690ca443%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7
|  C636530425373385036&sdata=C8EnmhpV%2Fzd5pWiWuKpmYULB%2BGXlFTcH4%2BBMgM
|  VDHDY%3D&reserved=0>.)
|  
|  This proposal is about removing a rarely used feature that is arguably
|  buggy and also imposes significant complexity. I think, removing ideas
|  that turn out to be not working properly or simply aren’t sufficiently
|  useful for the complexity they impose is an important part of the
|  process. The STM invariant mechanism appears to fit that bill. Hence,
|  I suggest to accept this proposal.
|  
|  Please let me know if you disagree; otherwise, I will assume tacit
|  approval.
|  
|  Cheers,
|  Manuel
|  
|  _______________________________________________
|  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  Fri Feb  2 01:40:50 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Fri, 2 Feb 2018 12:40:50 +1100
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
Message-ID: <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>

I am 100% for Part 2 of the proposal.

Regarding Part 1, I am not keen on moving further from the Report, but then the original Haskell spec wasn’t written with the sort of type-level programming extensions in mind that we have now. Hence, it is probably better to have the short, sharp pain of a change, rather than carry the cruft with us forever.

However, I have to say, I am very intrigued with the alternative to the proposal that Richard mentioned in this thread, namely to use ”type”, not ”Type”. The more I think about it, the more I like this idea.

* It allows us to have ”type” (the kind) available at all times, which, I think, is justified, given its very special meaning and ubiquitous need for denoting kind signatures.

* I also think, it is good to distinguish it from other kind constructors as it is not at all like the others.

* Having a lower case first letter, in my view, does decrease the additional visual noise over ’*’ (that Iavor mentioned) a bit.

* I also don’t think there is much risk to confuse it with a type variable as syntax highlighting will mark it up as a keyword, not a variable.

* Finally, it means that

    type T = Bool

  adds another equality to ”type”, which is really nice.

Cheers,
Manuel

> Am 26.01.2018 um 08:45 schrieb Iavor Diatchki <iavor.diatchki at gmail.com>:
> 
> Hello,
> 
> I am the shepherd for pull request #83 "Embrace Type in Type" ( https://github.com/ghc-proposals/ghc-proposals/pull/83 <https://github.com/ghc-proposals/ghc-proposals/pull/83>), and so I'd like to hear your thoughts about the proposal.
> 
> In short, the proposal has two parts:
>    1. Deprecate the use of `*` for the kind of inhabited Haskell types, and replace it with `Type`.
>    2. Deprecate extension `TypeInType`, and move its functionality to extension `PolyKinds`.
> 
> At first I was quite skeptical about both of these, but after some thought I've realized that most of my concerns are not so much about Type in Type, but rather about the data promotion mechanism, and so I won't discuss them in this e-mail.
> 
> As such, I think I would be OK with part 2.  In particular, I like that when using TypeInType, one is explicit about kind parameters, as the implicit parameters of `PolyKinds` can be quite confusing.  Technically, being explicit about kind parameters is an orthogonal issue to mixing up types and kinds, but this is where we are at the moment, and I think `PolyKinds` is probably more useful with `TypeInType`.
> 
> Part 1 of the proposal is obviously just a syntactic thing, but I am a bit concerned about it.  In part because I actually tried for a while to use `Type` instead of `*`, and I found that the resulting kind signatures looked much more complicated.    Quite possibly this is because I am very used to using `*` and eventually I would adjust, but things just ended up being much longer.  It also seems unfortunate that this would break quite a lot of code, and obsolete a bunch of documentation and tutorials online.
> 
> So while I understand the reason for the proposal (the confusion between `*` the type function, and `*` the kind), I am not very keen on making this change.   The proposal also suggests another extension, `StarIsType`, and when enabled `*` will always refer to the kind, and never to the type function.  I am even less keen about this option, as I think it is better to pick a single notation and stick with it.
> 
> I'd love to hear what others think!
> 
> -Iavor
> 
> 
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From mail at joachim-breitner.de  Fri Feb  2 01:58:18 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 01 Feb 2018 20:58:18 -0500
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
Message-ID: <1517536698.25075.5.camel@joachim-breitner.de>

Hi,

Am Freitag, den 02.02.2018, 12:40 +1100 schrieb Manuel M T Chakravarty:
> However, I have to say, I am very intrigued with the alternative to
> the proposal that Richard mentioned in this thread, namely to use
> ”type”, not ”Type”. The more I think about it, the more I like this
> idea.

This is somewhat analogous to (->). We could treat that as a normal
binary operator that his exported by the Prelude, one that could be
hidden or shadowed… but we don’t. “type” would be another thing that
“Could be a normal name but isn’t”.

But I am not convinced yet.

In particular in light of our use of “type” as a explicit namespace
token – so far in export and import lists and fixity declarations – I
worry that we will prevent ourselves from using more such explicit
namespace things in the future.

Also, the last point:

    Finally, it means that

        type T = Bool

      adds another equality to ”type”, which is really nice.

doesn’t really work for me. If “type” is now just another (albeit)
special object, then this looks rather like a functoin definition for
this thing called “type”.

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/20180201/7c813132/attachment.sig>

From iavor.diatchki at gmail.com  Fri Feb  2 17:24:24 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 02 Feb 2018 17:24:24 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <1517536698.25075.5.camel@joachim-breitner.de>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
Message-ID: <CAGK9nuocmUjhprr2hNk=DEatmYL34ibk5GRbH08ukxsaw04oSw@mail.gmail.com>

Someone pointed out on the git-hub discussion that `Type` is just a type
synonym for `TYPE LiftedRep` and it is odd to use a keyword for a
non-primitive.  I agree.  Also, if we are going to have a special case, I'd
much rather have the special case be for * or ★, rather than for `type`.



On Thu, Feb 1, 2018 at 5:58 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Freitag, den 02.02.2018, 12:40 +1100 schrieb Manuel M T Chakravarty:
> > However, I have to say, I am very intrigued with the alternative to
> > the proposal that Richard mentioned in this thread, namely to use
> > ”type”, not ”Type”. The more I think about it, the more I like this
> > idea.
>
> This is somewhat analogous to (->). We could treat that as a normal
> binary operator that his exported by the Prelude, one that could be
> hidden or shadowed… but we don’t. “type” would be another thing that
> “Could be a normal name but isn’t”.
>
> But I am not convinced yet.
>
> In particular in light of our use of “type” as a explicit namespace
> token – so far in export and import lists and fixity declarations – I
> worry that we will prevent ourselves from using more such explicit
> namespace things in the future.
>
> Also, the last point:
>
>     Finally, it means that
>
>         type T = Bool
>
>       adds another equality to ”type”, which is really nice.
>
> doesn’t really work for me. If “type” is now just another (albeit)
> special object, then this looks rather like a functoin definition for
> this thing called “type”.
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180202/ea64c2b3/attachment.html>

From mail at joachim-breitner.de  Sat Feb  3 15:51:07 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 03 Feb 2018 10:51:07 -0500
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=2377_=22Deprecating_?=
 =?utf-8?q?STM_invariant_mechanism=22_=E2=80=94_suggesting_acceptance?=
In-Reply-To: <VI1PR83MB0205EDEE546BF9ACEE192074ADFA0@VI1PR83MB0205.EURPRD83.prod.outlook.com>
References: <1CF3A14F-741F-4645-AF81-84E6204AD1AA@justtesting.org>
 <VI1PR83MB0205EDEE546BF9ACEE192074ADFA0@VI1PR83MB0205.EURPRD83.prod.outlook.com>
Message-ID: <1517673067.20081.0.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 01.02.2018, 08:15 +0000 schrieb Simon Peyton Jones:
> I'm ok with removal, and there seems to be a consensus.

I detect clear consensus, and declare this as approved.

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/20180203/70af492c/attachment.sig>

From rae at cs.brynmawr.edu  Sun Feb  4 04:24:15 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sat, 3 Feb 2018 23:24:15 -0500
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <1517536698.25075.5.camel@joachim-breitner.de>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
Message-ID: <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>


> On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> In particular in light of our use of “type” as a explicit namespace
> token – so far in export and import lists and fixity declarations – I
> worry that we will prevent ourselves from using more such explicit
> namespace things in the future.

This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does not want to have separate type-level and term-level namespaces. Of course, Haskell has this.

The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.

If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.

All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type` isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.

Richard

From mail at joachim-breitner.de  Mon Feb  5 22:42:00 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 05 Feb 2018 17:42:00 -0500
Subject: [ghc-steering-committee] Do we consider the GHC API in scope?
Message-ID: <1517870520.23352.2.camel@joachim-breitner.de>

Hi,

in https://github.com/ghc-proposals/ghc-proposals/pull/108 David
proposed changes to the plugin API. The propsosal is still under
discussion (so if you want to comment, do it there), but more
generally, I wonder:

Is the GHC API (including the one for plugins) in scope for the GHC
steering committee?

Or should they go the same route as other, genuinely internal changes
in GHC, which would be Trac and Phab?

Note that plugins often have to import arbitrary GHC modules, not just
GhcPlugins, so really every exported function in GHC is part of the GHC
API and hence the plugin API?

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/20180205/9a1df77d/attachment.sig>

From ben at well-typed.com  Tue Feb  6 02:30:13 2018
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 05 Feb 2018 21:30:13 -0500
Subject: [ghc-steering-committee] Do we consider the GHC API in scope?
In-Reply-To: <1517870520.23352.2.camel@joachim-breitner.de>
References: <1517870520.23352.2.camel@joachim-breitner.de>
Message-ID: <87k1vqzw7j.fsf@smart-cactus.org>

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

> Hi,
>
> in https://github.com/ghc-proposals/ghc-proposals/pull/108 David
> proposed changes to the plugin API. The propsosal is still under
> discussion (so if you want to comment, do it there), but more
> generally, I wonder:
>
> Is the GHC API (including the one for plugins) in scope for the GHC
> steering committee?
>
I'm very much on the fence about this, despite being the one who
initially referred the issue. It's not clear to me that making interface
decisions about the GhcPlugins or GHC modules is a task well-suited to a
committee.

Regardless, I think having a relatively high-visibility place to discuss
changes like the plugins proposal is quite helpful. So, even if we
decide that the API is out-of-scope for the committee, I think it may
still be helpful to use the proposal forum to solicit community
feedback. While in principle this discussion could happen just as easily
on Trac, my impression is that GitHub has been a bit more effective in
collecting a wide range of input.

Cheers,

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

From chak at justtesting.org  Tue Feb  6 02:55:01 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 6 Feb 2018 13:55:01 +1100
Subject: [ghc-steering-committee] Do we consider the GHC API in scope?
In-Reply-To: <87k1vqzw7j.fsf@smart-cactus.org>
References: <1517870520.23352.2.camel@joachim-breitner.de>
 <87k1vqzw7j.fsf@smart-cactus.org>
Message-ID: <5D9238A0-452F-467B-9F76-0D2197275722@justtesting.org>

+1

> Am 06.02.2018 um 13:30 schrieb Ben Gamari <ben at well-typed.com>:
> 
> Joachim Breitner <mail at joachim-breitner.de> writes:
> 
>> Hi,
>> 
>> in https://github.com/ghc-proposals/ghc-proposals/pull/108 David
>> proposed changes to the plugin API. The propsosal is still under
>> discussion (so if you want to comment, do it there), but more
>> generally, I wonder:
>> 
>> Is the GHC API (including the one for plugins) in scope for the GHC
>> steering committee?
>> 
> I'm very much on the fence about this, despite being the one who
> initially referred the issue. It's not clear to me that making interface
> decisions about the GhcPlugins or GHC modules is a task well-suited to a
> committee.
> 
> Regardless, I think having a relatively high-visibility place to discuss
> changes like the plugins proposal is quite helpful. So, even if we
> decide that the API is out-of-scope for the committee, I think it may
> still be helpful to use the proposal forum to solicit community
> feedback. While in principle this discussion could happen just as easily
> on Trac, my impression is that GitHub has been a bit more effective in
> collecting a wide range of input.
> 
> Cheers,
> 
> - Ben
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From simonpj at microsoft.com  Tue Feb  6 09:27:03 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 6 Feb 2018 09:27:03 +0000
Subject: [ghc-steering-committee] Do we consider the GHC API in scope?
In-Reply-To: <87k1vqzw7j.fsf@smart-cactus.org>
References: <1517870520.23352.2.camel@joachim-breitner.de>
 <87k1vqzw7j.fsf@smart-cactus.org>
Message-ID: <AM5PR83MB016355CDEFCF61CF2DA35F1FADFD0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

I think we should cover GHC API changes.

* The committee is meant to cover the "users-eye-view" of GHC.
  The GHC API is a major asset, used by many users.  OK, so they
  are nestling a bit closer to the implementation, but still.

* There is no other forum to discuss API changes.

* In principle a user of GHC-as-a-library can call any old internal
  function; we should /not/ cover this.  Only the high-level
  "advertised" API.

* We don't do a good job of advertising that API; it's basically
  what is exported by module GHC.  But I think it that proposals
  focused on improving it would be quite helpful.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Ben Gamari
|  Sent: 06 February 2018 02:30
|  To: Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-
|  committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Do we consider the GHC API in
|  scope?
|  
|  Joachim Breitner <mail at joachim-breitner.de> writes:
|  
|  > Hi,
|  >
|  > in
|  >
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  > b.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F108&data=02%7C01%7Csimo
|  >
|  npj%40microsoft.com%7C45d9aac776734af02fe208d56d09967f%7Cee3303d7fb734
|  b0c8589bcd847f1c277%7C1%7C0%7C636534810305126138&sdata=%2FlGFjPJMUrdqG
|  3Cx1mJ7Rq%2FGoq8NVnY3SEn843dIFWQ%3D&reserved=0 David proposed changes
|  to the plugin API. The propsosal is still under discussion (so if you
|  want to comment, do it there), but more generally, I wonder:
|  >
|  > Is the GHC API (including the one for plugins) in scope for the GHC
|  > steering committee?
|  >
|  I'm very much on the fence about this, despite being the one who
|  initially referred the issue. It's not clear to me that making
|  interface decisions about the GhcPlugins or GHC modules is a task
|  well-suited to a committee.
|  
|  Regardless, I think having a relatively high-visibility place to
|  discuss changes like the plugins proposal is quite helpful. So, even
|  if we decide that the API is out-of-scope for the committee, I think
|  it may still be helpful to use the proposal forum to solicit community
|  feedback. While in principle this discussion could happen just as
|  easily on Trac, my impression is that GitHub has been a bit more
|  effective in collecting a wide range of input.
|  
|  Cheers,
|  
|  - Ben

From mail at joachim-breitner.de  Tue Feb  6 13:57:26 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 06 Feb 2018 08:57:26 -0500
Subject: [ghc-steering-committee] Do we consider the GHC API in scope?
In-Reply-To: <AM5PR83MB016355CDEFCF61CF2DA35F1FADFD0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <1517870520.23352.2.camel@joachim-breitner.de>
 <87k1vqzw7j.fsf@smart-cactus.org>
 <AM5PR83MB016355CDEFCF61CF2DA35F1FADFD0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <1517925446.1079.7.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 06.02.2018, 09:27 +0000 schrieb Simon Peyton Jones:
> I think we should cover GHC API changes.
> 
> * The committee is meant to cover the "users-eye-view" of GHC.
>   The GHC API is a major asset, used by many users.  OK, so they
>   are nestling a bit closer to the implementation, but still.
> 
> * There is no other forum to discuss API changes.
> 
> * In principle a user of GHC-as-a-library can call any old internal
>   function; we should /not/ cover this.  Only the high-level
>   "advertised" API.
> 
> * We don't do a good job of advertising that API; it's basically
>   what is exported by module GHC.  But I think it that proposals
>   focused on improving it would be quite helpful.

just for the reference, that would be this module:
https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.2.2/src/GHC.html

So in particular, every change in HsSyn is no longer an internal change
under that view, as is any modification to DynFlags.

And I presume you’d include
https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.2.2/Plugins.html
and/or
https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.2.2/GhcPlugins.html
to be considered part of the API as well, right? But the latter re-
exports really many internal modules.

Under this rule, a change like
https://git.haskell.org/ghc.git/commitdiff/0e022e56b130ab9d277965b794e70d8d3fb29533
would have required committee approval?


I am worried about adding too much red tape to GHC development and
overloading the committee. How about this as a compromise:

    Changes to the GHC or Plugin API are not automatically within the
    scope of the committee, and can be contributed following the usual
    GHC workflow. Should the GHC maintainers deem a change significant
    or controversial enough to warrant that, they may, at their
    discretion, involve the committee and ask the contributor to write a
    formal proposal.

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/20180206/11a71b41/attachment.sig>

From simonpj at microsoft.com  Tue Feb  6 15:43:15 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 6 Feb 2018 15:43:15 +0000
Subject: [ghc-steering-committee] Do we consider the GHC API in scope?
In-Reply-To: <1517925446.1079.7.camel@joachim-breitner.de>
References: <1517870520.23352.2.camel@joachim-breitner.de>
 <87k1vqzw7j.fsf@smart-cactus.org>
 <AM5PR83MB016355CDEFCF61CF2DA35F1FADFD0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1517925446.1079.7.camel@joachim-breitner.de>
Message-ID: <AM5PR83MB016376A4BEB4D4ADC0B266D6ADFD0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

|  I am worried about adding too much red tape to GHC development and
|  overloading the committee. How about this as a compromise:
|  
|      Changes to the GHC or Plugin API are not automatically within the
|      scope of the committee, and can be contributed following the usual
|      GHC workflow. Should the GHC maintainers deem a change significant
|      or controversial enough to warrant that, they may, at their
|      discretion, involve the committee and ask the contributor to write
|  a
|      formal proposal.

Yes I agree.  We should also allow that others may propose changes to (including new functions) in the GHC API; essentially feature requests.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Joachim Breitner
|  Sent: 06 February 2018 13:57
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Do we consider the GHC API in
|  scope?
|  
|  Hi,
|  
|  Am Dienstag, den 06.02.2018, 09:27 +0000 schrieb Simon Peyton Jones:
|  > I think we should cover GHC API changes.
|  >
|  > * The committee is meant to cover the "users-eye-view" of GHC.
|  >   The GHC API is a major asset, used by many users.  OK, so they
|  >   are nestling a bit closer to the implementation, but still.
|  >
|  > * There is no other forum to discuss API changes.
|  >
|  > * In principle a user of GHC-as-a-library can call any old internal
|  >   function; we should /not/ cover this.  Only the high-level
|  >   "advertised" API.
|  >
|  > * We don't do a good job of advertising that API; it's basically
|  >   what is exported by module GHC.  But I think it that proposals
|  >   focused on improving it would be quite helpful.
|  
|  just for the reference, that would be this module:
|  https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa
|  ds.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Flibraries%2Fghc-
|  8.2.2%2Fsrc%2FGHC.html&data=02%7C01%7Csimonpj%40microsoft.com%7Cf09432
|  3ae91d486011f008d56d699973%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%
|  7C636535222689456123&sdata=dNSg4tkhR1JYxqMVHItcFImJtAnTFgklQZKpslI4gus
|  %3D&reserved=0
|  
|  So in particular, every change in HsSyn is no longer an internal
|  change under that view, as is any modification to DynFlags.
|  
|  And I presume you’d include
|  https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa
|  ds.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Flibraries%2Fghc-
|  8.2.2%2FPlugins.html&data=02%7C01%7Csimonpj%40microsoft.com%7Cf094323a
|  e91d486011f008d56d699973%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C
|  636535222689456123&sdata=Ep2gyYuGnaRnmySNCeSqLlPVrNSivvgMIC%2FN85GyOn0
|  %3D&reserved=0
|  and/or
|  https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa
|  ds.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Flibraries%2Fghc-
|  8.2.2%2FGhcPlugins.html&data=02%7C01%7Csimonpj%40microsoft.com%7Cf0943
|  23ae91d486011f008d56d699973%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0
|  %7C636535222689466131&sdata=D2gK4lk%2F5oOXtUhPfbDsHDXWo17juAEioTK8r1mG
|  0d8%3D&reserved=0
|  to be considered part of the API as well, right? But the latter re-
|  exports really many internal modules.
|  
|  Under this rule, a change like
|  https://git.haskell.org/ghc.git/commitdiff/0e022e56b130ab9d277965b794e
|  70d8d3fb29533
|  would have required committee approval?
|  
|  
|  I am worried about adding too much red tape to GHC development and
|  overloading the committee. How about this as a compromise:
|  
|      Changes to the GHC or Plugin API are not automatically within the
|      scope of the committee, and can be contributed following the usual
|      GHC workflow. Should the GHC maintainers deem a change significant
|      or controversial enough to warrant that, they may, at their
|      discretion, involve the committee and ask the contributor to write
|  a
|      formal proposal.
|  
|  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&data=02%7C01%7Csimonpj%40microsoft.com%7Cf094323ae91d48
|  6011f008d56d699973%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535
|  222689466131&sdata=YQaXg%2F7F9OL01FkHbzkgY9Cy2DVEAlQBUAee65Kt3lk%3D&re
|  served=0

From mail at joachim-breitner.de  Thu Feb  8 03:40:32 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 07 Feb 2018 22:40:32 -0500
Subject: [ghc-steering-committee] Please review: Int8/Word8,
	Shepherd: Simon Marlow
Message-ID: <1518061232.1186.1.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Small types like `Int8#`/`Word8#` were proposed
https://github.com/ghc-proposals/ghc-proposals/pull/74

I propose Simon Marlow as the Shepherd.

Simon, please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process

I suggest you make a recommendation 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/20180207/f5aee023/attachment.sig>

From mail at joachim-breitner.de  Thu Feb  8 03:41:33 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 07 Feb 2018 22:41:33 -0500
Subject: [ghc-steering-committee] Proposal: accept "add
 incomplete-uni-patterns and incomplete-record-updates to -Wall"
In-Reply-To: <CANsrgPKvJjq=6o8wm=7ObWLJz4M=GMCn_8vejxwU-CvFb2=G+Q@mail.gmail.com>
References: <CANsrgPKvJjq=6o8wm=7ObWLJz4M=GMCn_8vejxwU-CvFb2=G+Q@mail.gmail.com>
Message-ID: <1518061293.1186.2.camel@joachim-breitner.de>

Hi,

Am Montag, den 08.01.2018, 10:23 +0000 schrieb Simon Marlow:
> I propose that we accept the proposal 
> 
>   add incomplete-uni-patterns and incomplete-record-updates to -Wall

accepted!


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/20180207/d77bd39c/attachment.sig>

From iavor.diatchki at gmail.com  Thu Feb  8 18:46:33 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 08 Feb 2018 18:46:33 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
Message-ID: <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>

Hello,

I didn't see any discussion about the third part of this proposal, namely
the addition of a new extension called `StarIsKind`.  The idea is that when
this is on, `*` will still be treated as a special alpha-numeric name, and
it will *always* refer to the kind of inhabited types (i.e., same as
know).  The difference is that it cannot be used as another type-level
operator (e.g., for multiplication).

Presumably, when this extension is on, there would be no deprecation
warning emitted for `*`? We should clarify this in the proposal.

I am not certain if this is a good idea.  It makes the use of `*` sort of
"half" deprecated, and leaves us with multiple "standard" ways to refer to
the same thing (e.g., in type errors).  Also, if we want people to update
their code to use `Type` instead of `*`, then we are just delaying the pain
point to whenever `StarIsKind` ends up being not on by default.

OTOH, if we don't have a standard short-hand way to refer to the kind of
inhabited types, I imagine GHC will report some very ugly errors.  For
example:

    • Expecting one more argument to ‘Maybe’
      Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type ->
Data.Kind.Type’

And this is for a fairly simple kind error, they get much longer if, say,
monad transformers are involved.

What do others think?

-Iavor






On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

>
> > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> >
> > In particular in light of our use of “type” as a explicit namespace
> > token – so far in export and import lists and fixity declarations – I
> > worry that we will prevent ourselves from using more such explicit
> > namespace things in the future.
>
> This is a really good point. In private musings, I've often wondered about
> using the keyword `type` in expressions to denote a namespace change. More
> concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is,
> a dependently typed language does not want to have separate type-level and
> term-level namespaces. Of course, Haskell has this.
>
> The best solution I have so far to the DNP is to introduce a *new*
> namespace, distinct from the two namespaces we have so far. Let's call it
> the "default" namespace. When -XDependentTypes is on, the default namespace
> is in effect. Name lookup looks first in the default namespace. If that
> fails the namespace consulted next depends on context: the "data" namespace
> in terms and the "type" namespace in type signatures. (This last bit needs
> to be specified more concretely, but you get the idea.) Or, perhaps, a
> failed lookup in the default namespace will look up in both the type and
> data namespaces, erroring if a name appears in both.
>
> If a user wants to specify a namespace directly, they have a very easy way
> to do so: `type Foo` will look in the type namespace, `data Foo` will look
> in the data namespace, and `default Foo` will look in the default
> namespace. :) Because these keywords make sense currently only at the
> beginning of a line, this Just Works. I also imagined these constructs
> could scope over a subexpression: `type (T S)`.
>
> All of this deserves a proper proposal and it's too early for that
> proposal. Nevertheless, I'm grateful that Joachim said something here,
> given that adding `type` as a spelling of `Type` would invalidate this
> approach. I also am swayed by the fact that `Type` isn't fully primitive,
> and making a keyword mean something that's not primitive is a bit awkward.
> I thus retract this proposed alternative and will update the proposal
> accordingly.
>
> 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/20180208/9b4d9d8b/attachment.html>

From mail at joachim-breitner.de  Thu Feb  8 20:27:01 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 08 Feb 2018 15:27:01 -0500
Subject: [ghc-steering-committee]  Please review: unlifted newtypes,
 Shepherd: Richard Eisenberg
Message-ID: <1518121621.1059.13.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Unlifted Newtypes were proposed
https://github.com/ghc-proposals/ghc-proposals/pull/98

I propose Richard Eisenberg as the Shepherd.

Richard, please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process

I suggest you make a recommendation 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/20180208/1f7810ea/attachment.sig>

From chak at justtesting.org  Fri Feb  9 04:17:35 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Fri, 9 Feb 2018 15:17:35 +1100
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
Message-ID: <E5096E1F-6126-47D2-A704-9FBF793F0F23@justtesting.org>

I agree that this is bad. That’s why I wrote that I like the idea of using ’type’ as a substitute for ’*’, but others didn’t seem to like that.

I think, there needs to be some short notation for ’*’ that is always in scope.

Cheers,
Manuel

> 09.02.2018 05:46 Iavor Diatchki <iavor.diatchki at gmail.com>:
> 
> Hello,
> 
> I didn't see any discussion about the third part of this proposal, namely the addition of a new extension called `StarIsKind`.  The idea is that when this is on, `*` will still be treated as a special alpha-numeric name, and it will *always* refer to the kind of inhabited types (i.e., same as know).  The difference is that it cannot be used as another type-level operator (e.g., for multiplication).
> 
> Presumably, when this extension is on, there would be no deprecation warning emitted for `*`? We should clarify this in the proposal.
> 
> I am not certain if this is a good idea.  It makes the use of `*` sort of "half" deprecated, and leaves us with multiple "standard" ways to refer to the same thing (e.g., in type errors).  Also, if we want people to update their code to use `Type` instead of `*`, then we are just delaying the pain point to whenever `StarIsKind` ends up being not on by default.
> 
> OTOH, if we don't have a standard short-hand way to refer to the kind of inhabited types, I imagine GHC will report some very ugly errors.  For example:
> 
>     • Expecting one more argument to ‘Maybe’
>       Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type -> Data.Kind.Type’
> 
> And this is for a fairly simple kind error, they get much longer if, say, monad transformers are involved.
> 
> What do others think?
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> wrote:
> 
> > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> >
> > In particular in light of our use of “type” as a explicit namespace
> > token – so far in export and import lists and fixity declarations – I
> > worry that we will prevent ourselves from using more such explicit
> > namespace things in the future.
> 
> This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does not want to have separate type-level and term-level namespaces. Of course, Haskell has this.
> 
> The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.
> 
> If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.
> 
> All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type` isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.
> 
> 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 <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/20180209/fb73f0c9/attachment-0001.html>

From rae at cs.brynmawr.edu  Fri Feb  9 04:25:45 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 8 Feb 2018 23:25:45 -0500
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
Message-ID: <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>

Thanks, Iavor, for bringing this up.

To clarify the proposal: -XStarIsType is orthogonal to deprecation. The extension is necessary in order to continue to parse existing programs, but if we choose to deprecate *, then we would deprecate even with -XStarIsType is enabled (precisely to avoid the half-deprecation scenario Iavor is worried about).

I envisioned always printing Type unqualified in error messages, even if it's not imported. If a user writes Type and it's out of scope, we could always have a special-case check suggesting they import Data.Kind. I won't argue this is a principled design, though, and is likely a poor choice if some other Type is in scope.

The truth is that I don't have a great way forward here (and haven't for years) and am very hopeful someone on this list can come up with one! :) The proposal has my best idea, but I'm still not thrilled with it.

Thanks,
Richard

> On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello,
> 
> I didn't see any discussion about the third part of this proposal, namely the addition of a new extension called `StarIsKind`.  The idea is that when this is on, `*` will still be treated as a special alpha-numeric name, and it will *always* refer to the kind of inhabited types (i.e., same as know).  The difference is that it cannot be used as another type-level operator (e.g., for multiplication).
> 
> Presumably, when this extension is on, there would be no deprecation warning emitted for `*`? We should clarify this in the proposal.
> 
> I am not certain if this is a good idea.  It makes the use of `*` sort of "half" deprecated, and leaves us with multiple "standard" ways to refer to the same thing (e.g., in type errors).  Also, if we want people to update their code to use `Type` instead of `*`, then we are just delaying the pain point to whenever `StarIsKind` ends up being not on by default.
> 
> OTOH, if we don't have a standard short-hand way to refer to the kind of inhabited types, I imagine GHC will report some very ugly errors.  For example:
> 
>     • Expecting one more argument to ‘Maybe’
>       Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type -> Data.Kind.Type’
> 
> And this is for a fairly simple kind error, they get much longer if, say, monad transformers are involved.
> 
> What do others think?
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> wrote:
> 
> > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> >
> > In particular in light of our use of “type” as a explicit namespace
> > token – so far in export and import lists and fixity declarations – I
> > worry that we will prevent ourselves from using more such explicit
> > namespace things in the future.
> 
> This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does not want to have separate type-level and term-level namespaces. Of course, Haskell has this.
> 
> The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.
> 
> If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.
> 
> All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type` isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.
> 
> 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 <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/20180208/d63220c8/attachment.html>

From simonpj at microsoft.com  Fri Feb  9 10:41:34 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 9 Feb 2018 10:41:34 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
Message-ID: <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>

I’m not sure I see the problem here.  If ‘Int’ is not in scope then
f :: Int -> Int
won’t work.  What’s different about ‘Type’

Simon

From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Richard Eisenberg
Sent: 09 February 2018 04:26
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type

Thanks, Iavor, for bringing this up.

To clarify the proposal: -XStarIsType is orthogonal to deprecation. The extension is necessary in order to continue to parse existing programs, but if we choose to deprecate *, then we would deprecate even with -XStarIsType is enabled (precisely to avoid the half-deprecation scenario Iavor is worried about).

I envisioned always printing Type unqualified in error messages, even if it's not imported. If a user writes Type and it's out of scope, we could always have a special-case check suggesting they import Data.Kind. I won't argue this is a principled design, though, and is likely a poor choice if some other Type is in scope.

The truth is that I don't have a great way forward here (and haven't for years) and am very hopeful someone on this list can come up with one! :) The proposal has my best idea, but I'm still not thrilled with it.

Thanks,
Richard

On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,

I didn't see any discussion about the third part of this proposal, namely the addition of a new extension called `StarIsKind`.  The idea is that when this is on, `*` will still be treated as a special alpha-numeric name, and it will *always* refer to the kind of inhabited types (i.e., same as know).  The difference is that it cannot be used as another type-level operator (e.g., for multiplication).

Presumably, when this extension is on, there would be no deprecation warning emitted for `*`? We should clarify this in the proposal.

I am not certain if this is a good idea.  It makes the use of `*` sort of "half" deprecated, and leaves us with multiple "standard" ways to refer to the same thing (e.g., in type errors).  Also, if we want people to update their code to use `Type` instead of `*`, then we are just delaying the pain point to whenever `StarIsKind` ends up being not on by default.

OTOH, if we don't have a standard short-hand way to refer to the kind of inhabited types, I imagine GHC will report some very ugly errors.  For example:

    • Expecting one more argument to ‘Maybe’
      Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type -> Data.Kind.Type’

And this is for a fairly simple kind error, they get much longer if, say, monad transformers are involved.

What do others think?

-Iavor






On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:

> On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
>
> In particular in light of our use of “type” as a explicit namespace
> token – so far in export and import lists and fixity declarations – I
> worry that we will prevent ourselves from using more such explicit
> namespace things in the future.

This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does not want to have separate type-level and term-level namespaces. Of course, Haskell has this.

The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.

If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.

All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type` isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.

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/20180209/0af65c01/attachment-0001.html>

From rae at cs.brynmawr.edu  Fri Feb  9 17:05:26 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 9 Feb 2018 12:05:26 -0500
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
Message-ID: <4D9F5FBD-5807-4266-A3BA-991E7392C0C2@cs.brynmawr.edu>

A chat with some colleagues this morning about all this led to a few thoughts I'd like to contribute:

1. We, as a committee, should decide now on the future of * (and its unicode variant). If we decide to deprecate it, we should start adding warnings and support for a long transition away from *. I don't think it's healthy to have two commonly used name for this concept into perpetuity.

2. We *could* put Type into the Prelude (after suitable waiting periods / warnings / etc). It would be painful to do so, but perhaps it's worth enduring the short-lived pain.

3. An alternative that hasn't yet been discussed is to come up with a wholly new name for this concept and use that. Our math colleagues do this all the time (viz. monoid, monad, group, ring, field, category, etc.). Even among dependently typed languages, there is some wiggle room between Set and Type (and Prop). So maybe we just invent a new name that's not as common as Type, and then put it in the Prelude.

Just some food for thought...

Thanks,
Richard

> On Feb 9, 2018, at 5:41 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> I’m not sure I see the problem here.  If ‘Int’ is not in scope then
> f :: Int -> Int
> won’t work.  What’s different about ‘Type’
>  
> Simon
>  
> From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Richard Eisenberg
> Sent: 09 February 2018 04:26
> To: Iavor Diatchki <iavor.diatchki at gmail.com>
> Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
> Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type
>  
> Thanks, Iavor, for bringing this up.
>  
> To clarify the proposal: -XStarIsType is orthogonal to deprecation. The extension is necessary in order to continue to parse existing programs, but if we choose to deprecate *, then we would deprecate even with -XStarIsType is enabled (precisely to avoid the half-deprecation scenario Iavor is worried about).
>  
> I envisioned always printing Type unqualified in error messages, even if it's not imported. If a user writes Type and it's out of scope, we could always have a special-case check suggesting they import Data.Kind. I won't argue this is a principled design, though, and is likely a poor choice if some other Type is in scope.
>  
> The truth is that I don't have a great way forward here (and haven't for years) and am very hopeful someone on this list can come up with one! :) The proposal has my best idea, but I'm still not thrilled with it.
>  
> Thanks,
> Richard
>  
> On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
>  
> Hello,
>  
> I didn't see any discussion about the third part of this proposal, namely the addition of a new extension called `StarIsKind`.  The idea is that when this is on, `*` will still be treated as a special alpha-numeric name, and it will *always* refer to the kind of inhabited types (i.e., same as know).  The difference is that it cannot be used as another type-level operator (e.g., for multiplication).
>  
> Presumably, when this extension is on, there would be no deprecation warning emitted for `*`? We should clarify this in the proposal.
>  
> I am not certain if this is a good idea.  It makes the use of `*` sort of "half" deprecated, and leaves us with multiple "standard" ways to refer to the same thing (e.g., in type errors).  Also, if we want people to update their code to use `Type` instead of `*`, then we are just delaying the pain point to whenever `StarIsKind` ends up being not on by default.
>  
> OTOH, if we don't have a standard short-hand way to refer to the kind of inhabited types, I imagine GHC will report some very ugly errors.  For example:
>  
>     • Expecting one more argument to ‘Maybe’
>       Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type -> Data.Kind.Type’
>  
> And this is for a fairly simple kind error, they get much longer if, say, monad transformers are involved.
>  
> What do others think?
>  
> -Iavor
>  
>  
>  
>  
>  
>  
> On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> wrote:
> 
> > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> >
> > In particular in light of our use of “type” as a explicit namespace
> > token – so far in export and import lists and fixity declarations – I
> > worry that we will prevent ourselves from using more such explicit
> > namespace things in the future.
> 
> This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does not want to have separate type-level and term-level namespaces. Of course, Haskell has this.
> 
> The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.
> 
> If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.
> 
> All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type` isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.
> 
> 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 <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/20180209/b989bd72/attachment.html>

From iavor.diatchki at gmail.com  Fri Feb  9 17:46:53 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 09 Feb 2018 17:46:53 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>

The issue I see is that it is quite common to get a kind error without
doing any fancy type level programming---in particular without writing kind
signatures or anything like that.  So you'd have no reason to import
`Data.Kind(Type)`.    The result would be that GHC would give quite a
verbose error message, using the fully qualified name of `Type`.  Unless we
did something special.

-Iavor


On Fri, Feb 9, 2018 at 2:41 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I’m not sure I see the problem here.  If ‘Int’ is not in scope then
>
> f :: Int -> Int
>
> won’t work.  What’s different about ‘Type’
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee [mailto:
> ghc-steering-committee-bounces at haskell.org] *On Behalf Of *Richard
> Eisenberg
> *Sent:* 09 February 2018 04:26
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
> *Subject:* Re: [ghc-steering-committee] Proposal: Embrace Type in Type
>
>
>
> Thanks, Iavor, for bringing this up.
>
>
>
> To clarify the proposal: -XStarIsType is orthogonal to deprecation. The
> extension is necessary in order to continue to parse existing programs, but
> if we choose to deprecate *, then we would deprecate even with -XStarIsType
> is enabled (precisely to avoid the half-deprecation scenario Iavor is
> worried about).
>
>
>
> I envisioned always printing Type unqualified in error messages, even if
> it's not imported. If a user writes Type and it's out of scope, we could
> always have a special-case check suggesting they import Data.Kind. I won't
> argue this is a principled design, though, and is likely a poor choice if
> some other Type is in scope.
>
>
>
> The truth is that I don't have a great way forward here (and haven't for
> years) and am very hopeful someone on this list can come up with one! :)
> The proposal has my best idea, but I'm still not thrilled with it.
>
>
>
> Thanks,
>
> Richard
>
>
>
> On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>
>
> Hello,
>
>
>
> I didn't see any discussion about the third part of this proposal, namely
> the addition of a new extension called `StarIsKind`.  The idea is that when
> this is on, `*` will still be treated as a special alpha-numeric name, and
> it will *always* refer to the kind of inhabited types (i.e., same as
> know).  The difference is that it cannot be used as another type-level
> operator (e.g., for multiplication).
>
>
>
> Presumably, when this extension is on, there would be no deprecation
> warning emitted for `*`? We should clarify this in the proposal.
>
>
>
> I am not certain if this is a good idea.  It makes the use of `*` sort of
> "half" deprecated, and leaves us with multiple "standard" ways to refer to
> the same thing (e.g., in type errors).  Also, if we want people to update
> their code to use `Type` instead of `*`, then we are just delaying the pain
> point to whenever `StarIsKind` ends up being not on by default.
>
>
>
> OTOH, if we don't have a standard short-hand way to refer to the kind of
> inhabited types, I imagine GHC will report some very ugly errors.  For
> example:
>
>
>
>     • Expecting one more argument to ‘Maybe’
>
>       Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type ->
> Data.Kind.Type’
>
>
>
> And this is for a fairly simple kind error, they get much longer if, say,
> monad transformers are involved.
>
>
>
> What do others think?
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
>
> > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> >
> > In particular in light of our use of “type” as a explicit namespace
> > token – so far in export and import lists and fixity declarations – I
> > worry that we will prevent ourselves from using more such explicit
> > namespace things in the future.
>
> This is a really good point. In private musings, I've often wondered about
> using the keyword `type` in expressions to denote a namespace change. More
> concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is,
> a dependently typed language does not want to have separate type-level and
> term-level namespaces. Of course, Haskell has this.
>
> The best solution I have so far to the DNP is to introduce a *new*
> namespace, distinct from the two namespaces we have so far. Let's call it
> the "default" namespace. When -XDependentTypes is on, the default namespace
> is in effect. Name lookup looks first in the default namespace. If that
> fails the namespace consulted next depends on context: the "data" namespace
> in terms and the "type" namespace in type signatures. (This last bit needs
> to be specified more concretely, but you get the idea.) Or, perhaps, a
> failed lookup in the default namespace will look up in both the type and
> data namespaces, erroring if a name appears in both.
>
> If a user wants to specify a namespace directly, they have a very easy way
> to do so: `type Foo` will look in the type namespace, `data Foo` will look
> in the data namespace, and `default Foo` will look in the default
> namespace. :) Because these keywords make sense currently only at the
> beginning of a line, this Just Works. I also imagined these constructs
> could scope over a subexpression: `type (T S)`.
>
> All of this deserves a proper proposal and it's too early for that
> proposal. Nevertheless, I'm grateful that Joachim said something here,
> given that adding `type` as a spelling of `Type` would invalidate this
> approach. I also am swayed by the fact that `Type` isn't fully primitive,
> and making a keyword mean something that's not primitive is a bit awkward.
> I thus retract this proposed alternative and will update the proposal
> accordingly.
>
> 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/20180209/494c0395/attachment-0001.html>

From chak at justtesting.org  Sat Feb 10 05:42:42 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Sat, 10 Feb 2018 16:42:42 +1100
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
Message-ID: <9B22C92E-D901-4CE5-A918-A1B0F912F4E3@justtesting.org>

Yes, that’s why I think, we cannot deprecate it until we have an alternative that is not the fully qualified name.

Manuel

> Am 10.02.2018 um 04:46 schrieb Iavor Diatchki <iavor.diatchki at gmail.com>:
> 
> The issue I see is that it is quite common to get a kind error without doing any fancy type level programming---in particular without writing kind signatures or anything like that.  So you'd have no reason to import `Data.Kind(Type)`.    The result would be that GHC would give quite a verbose error message, using the fully qualified name of `Type`.  Unless we did something special.
> 
> -Iavor
> 
> 
> On Fri, Feb 9, 2018 at 2:41 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> I’m not sure I see the problem here.  If ‘Int’ is not in scope then
> 
> f :: Int -> Int
> 
> won’t work.  What’s different about ‘Type’
> 
>  
> 
> Simon
> 
>  
> 
> From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>] On Behalf Of Richard Eisenberg
> Sent: 09 February 2018 04:26
> To: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>
> Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
> Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type
> 
>  
> 
> Thanks, Iavor, for bringing this up.
> 
>  
> 
> To clarify the proposal: -XStarIsType is orthogonal to deprecation. The extension is necessary in order to continue to parse existing programs, but if we choose to deprecate *, then we would deprecate even with -XStarIsType is enabled (precisely to avoid the half-deprecation scenario Iavor is worried about).
> 
>  
> 
> I envisioned always printing Type unqualified in error messages, even if it's not imported. If a user writes Type and it's out of scope, we could always have a special-case check suggesting they import Data.Kind. I won't argue this is a principled design, though, and is likely a poor choice if some other Type is in scope.
> 
>  
> 
> The truth is that I don't have a great way forward here (and haven't for years) and am very hopeful someone on this list can come up with one! :) The proposal has my best idea, but I'm still not thrilled with it.
> 
>  
> 
> Thanks,
> 
> Richard
> 
>  
> 
> On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
> 
>  
> 
> Hello,
> 
>  
> 
> I didn't see any discussion about the third part of this proposal, namely the addition of a new extension called `StarIsKind`.  The idea is that when this is on, `*` will still be treated as a special alpha-numeric name, and it will *always* refer to the kind of inhabited types (i.e., same as know).  The difference is that it cannot be used as another type-level operator (e.g., for multiplication).
> 
>  
> 
> Presumably, when this extension is on, there would be no deprecation warning emitted for `*`? We should clarify this in the proposal.
> 
>  
> 
> I am not certain if this is a good idea.  It makes the use of `*` sort of "half" deprecated, and leaves us with multiple "standard" ways to refer to the same thing (e.g., in type errors).  Also, if we want people to update their code to use `Type` instead of `*`, then we are just delaying the pain point to whenever `StarIsKind` ends up being not on by default.
> 
>  
> 
> OTOH, if we don't have a standard short-hand way to refer to the kind of inhabited types, I imagine GHC will report some very ugly errors.  For example:
> 
>  
> 
>     • Expecting one more argument to ‘Maybe’
> 
>       Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type -> Data.Kind.Type’
> 
>  
> 
> And this is for a fairly simple kind error, they get much longer if, say, monad transformers are involved.
> 
>  
> 
> What do others think?
> 
>  
> 
> -Iavor
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> wrote:
> 
> 
> > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> >
> > In particular in light of our use of “type” as a explicit namespace
> > token – so far in export and import lists and fixity declarations – I
> > worry that we will prevent ourselves from using more such explicit
> > namespace things in the future.
> 
> This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does not want to have separate type-level and term-level namespaces. Of course, Haskell has this.
> 
> The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.
> 
> If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.
> 
> All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type` isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.
> 
> 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 <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/20180210/a1cbf508/attachment.html>

From rrnewton at indiana.edu  Sun Feb 11 03:30:43 2018
From: rrnewton at indiana.edu (Ryan Newton)
Date: Sat, 10 Feb 2018 22:30:43 -0500
Subject: [ghc-steering-committee] Please review: embrace Type::Type,
 Shepherd: Iavor
In-Reply-To: <1513651994.10094.21.camel@joachim-breitner.de>
References: <1513651994.10094.21.camel@joachim-breitner.de>
Message-ID: <CACYs5AZivDcUoDMF_h+7Of5zwrZ-27pa7eRNk_V8FQw+b1EYeA@mail.gmail.com>

This seems like a clear step forward, and I think we should accept.

I read the lively discussion
<https://github.com/ghc-proposals/ghc-proposals/pull/83#issuecomment-337685679>,
and my only minor concern is that "StarIsType" wastes extension namespace
on the wart that is "*".  That's ok though because in time that extension
could itself be deprecated.

 -Ryan


On Mon, Dec 18, 2017 at 9:53 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Richards proposes to merge -XTypeInType into -XPolyKinds and -XDataKinds
> https://github.com/ghc-proposals/ghc-proposals/pull/83
>
> I propose Yavor Diatchki as the Shepherd.
>
> Yavor, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> I suggest you make a recommendation 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/20180210/1c686f9a/attachment.html>

From rrnewton at indiana.edu  Sun Feb 11 03:48:49 2018
From: rrnewton at indiana.edu (Ryan Newton)
Date: Sat, 10 Feb 2018 22:48:49 -0500
Subject: [ghc-steering-committee] Please review: unlifted newtypes,
 Shepherd: Richard Eisenberg
In-Reply-To: <1518121621.1059.13.camel@joachim-breitner.de>
References: <1518121621.1059.13.camel@joachim-breitner.de>
Message-ID: <CACYs5AbAhMhKvfKz_xfCN+QzpFiQ3vps8zMMjYq6+eU0+CJE-Q@mail.gmail.com>

I can't tell if SPJ's concerns
<https://github.com/ghc-proposals/ghc-proposals/pull/98#issuecomment-350206819>
were addressed by subsequent edits.

I'm general in favor of all things that make low-allocation, strict
programming more practical.  So it is no surprise that this sounds like
music to my ears, and thus I'm inclined to argue for "accept".

Best,
  -Ryan


On Thu, Feb 8, 2018 at 3:27 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Unlifted Newtypes were proposed
> https://github.com/ghc-proposals/ghc-proposals/pull/98
>
> I propose Richard Eisenberg as the Shepherd.
>
> Richard, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> I suggest you make a recommendation 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/20180210/14265a0d/attachment.html>

From rrnewton at indiana.edu  Sun Feb 11 04:05:44 2018
From: rrnewton at indiana.edu (Ryan Newton)
Date: Sat, 10 Feb 2018 23:05:44 -0500
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <9B22C92E-D901-4CE5-A918-A1B0F912F4E3@justtesting.org>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
 <9B22C92E-D901-4CE5-A918-A1B0F912F4E3@justtesting.org>
Message-ID: <CACYs5Aa7or_2Ss4F62ehJBfmP3EvuGmEkzzhrrXEAThMaD03aw@mail.gmail.com>

@Manuel, for you would it be sufficient for *-deprecation to have an
*eventual* plan to put Type prelude?

I just can't see how, if Haskell were designed today, the "*" convention
would come to be.  Personally, I worry more about legacy/textbook issues
for topics that are a bit closer to CS101 than I believe kind signatures
are.

 -Ryan

On Sat, Feb 10, 2018 at 12:42 AM, Manuel M T Chakravarty <
chak at justtesting.org> wrote:

> Yes, that’s why I think, we cannot deprecate it until we have an
> alternative that is not the fully qualified name.
>
> Manuel
>
>
> Am 10.02.2018 um 04:46 schrieb Iavor Diatchki <iavor.diatchki at gmail.com>:
>
> The issue I see is that it is quite common to get a kind error without
> doing any fancy type level programming---in particular without writing kind
> signatures or anything like that.  So you'd have no reason to import
> `Data.Kind(Type)`.    The result would be that GHC would give quite a
> verbose error message, using the fully qualified name of `Type`.  Unless we
> did something special.
>
> -Iavor
>
>
> On Fri, Feb 9, 2018 at 2:41 AM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>> I’m not sure I see the problem here.  If ‘Int’ is not in scope then
>>
>> f :: Int -> Int
>>
>> won’t work.  What’s different about ‘Type’
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee [mailto:ghc-steering-
>> committee-bounces at haskell.org] *On Behalf Of *Richard Eisenberg
>> *Sent:* 09 February 2018 04:26
>> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
>> mail at joachim-breitner.de>
>> *Subject:* Re: [ghc-steering-committee] Proposal: Embrace Type in Type
>>
>>
>>
>> Thanks, Iavor, for bringing this up.
>>
>>
>>
>> To clarify the proposal: -XStarIsType is orthogonal to deprecation. The
>> extension is necessary in order to continue to parse existing programs, but
>> if we choose to deprecate *, then we would deprecate even with -XStarIsType
>> is enabled (precisely to avoid the half-deprecation scenario Iavor is
>> worried about).
>>
>>
>>
>> I envisioned always printing Type unqualified in error messages, even if
>> it's not imported. If a user writes Type and it's out of scope, we could
>> always have a special-case check suggesting they import Data.Kind. I won't
>> argue this is a principled design, though, and is likely a poor choice if
>> some other Type is in scope.
>>
>>
>>
>> The truth is that I don't have a great way forward here (and haven't for
>> years) and am very hopeful someone on this list can come up with one! :)
>> The proposal has my best idea, but I'm still not thrilled with it.
>>
>>
>>
>> Thanks,
>>
>> Richard
>>
>>
>>
>> On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>>
>>
>>
>> Hello,
>>
>>
>>
>> I didn't see any discussion about the third part of this proposal, namely
>> the addition of a new extension called `StarIsKind`.  The idea is that when
>> this is on, `*` will still be treated as a special alpha-numeric name, and
>> it will *always* refer to the kind of inhabited types (i.e., same as
>> know).  The difference is that it cannot be used as another type-level
>> operator (e.g., for multiplication).
>>
>>
>>
>> Presumably, when this extension is on, there would be no deprecation
>> warning emitted for `*`? We should clarify this in the proposal.
>>
>>
>>
>> I am not certain if this is a good idea.  It makes the use of `*` sort of
>> "half" deprecated, and leaves us with multiple "standard" ways to refer to
>> the same thing (e.g., in type errors).  Also, if we want people to update
>> their code to use `Type` instead of `*`, then we are just delaying the pain
>> point to whenever `StarIsKind` ends up being not on by default.
>>
>>
>>
>> OTOH, if we don't have a standard short-hand way to refer to the kind of
>> inhabited types, I imagine GHC will report some very ugly errors.  For
>> example:
>>
>>
>>
>>     • Expecting one more argument to ‘Maybe’
>>
>>       Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type ->
>> Data.Kind.Type’
>>
>>
>>
>> And this is for a fairly simple kind error, they get much longer if, say,
>> monad transformers are involved.
>>
>>
>>
>> What do others think?
>>
>>
>>
>> -Iavor
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu>
>> wrote:
>>
>>
>> > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>> >
>> > In particular in light of our use of “type” as a explicit namespace
>> > token – so far in export and import lists and fixity declarations – I
>> > worry that we will prevent ourselves from using more such explicit
>> > namespace things in the future.
>>
>> This is a really good point. In private musings, I've often wondered
>> about using the keyword `type` in expressions to denote a namespace change.
>> More concretely, I'm worried about the Dreaded Namespace Problem (DNP):
>> that is, a dependently typed language does not want to have separate
>> type-level and term-level namespaces. Of course, Haskell has this.
>>
>> The best solution I have so far to the DNP is to introduce a *new*
>> namespace, distinct from the two namespaces we have so far. Let's call it
>> the "default" namespace. When -XDependentTypes is on, the default namespace
>> is in effect. Name lookup looks first in the default namespace. If that
>> fails the namespace consulted next depends on context: the "data" namespace
>> in terms and the "type" namespace in type signatures. (This last bit needs
>> to be specified more concretely, but you get the idea.) Or, perhaps, a
>> failed lookup in the default namespace will look up in both the type and
>> data namespaces, erroring if a name appears in both.
>>
>> If a user wants to specify a namespace directly, they have a very easy
>> way to do so: `type Foo` will look in the type namespace, `data Foo` will
>> look in the data namespace, and `default Foo` will look in the default
>> namespace. :) Because these keywords make sense currently only at the
>> beginning of a line, this Just Works. I also imagined these constructs
>> could scope over a subexpression: `type (T S)`.
>>
>> All of this deserves a proper proposal and it's too early for that
>> proposal. Nevertheless, I'm grateful that Joachim said something here,
>> given that adding `type` as a spelling of `Type` would invalidate this
>> approach. I also am swayed by the fact that `Type` isn't fully primitive,
>> and making a keyword mean something that's not primitive is a bit awkward.
>> I thus retract this proposed alternative and will update the proposal
>> accordingly.
>>
>> 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
>
>
>
> _______________________________________________
> 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/20180210/c7cb745f/attachment-0001.html>

From rrnewton at indiana.edu  Sun Feb 11 04:16:05 2018
From: rrnewton at indiana.edu (Ryan Newton)
Date: Sat, 10 Feb 2018 23:16:05 -0500
Subject: [ghc-steering-committee] Please review: Int8/Word8,
 Shepherd: Simon Marlow
In-Reply-To: <1518061232.1186.1.camel@joachim-breitner.de>
References: <1518061232.1186.1.camel@joachim-breitner.de>
Message-ID: <CACYs5Aa8QFMSU03CO8JKLgMCKYXp9oAsP8yChSYPjF1oSHWX3A@mail.gmail.com>

This sounds great, especially as the proposer is working on implementing
it.  Let's accept!

As a procedural note, it seems like if the calling conventions *were* ever
changed (to avoid "rounding up" everything to 64 bits between caller and
callee), that that improvement would not need to go through the proposals
process.  I.e., it's an implementation detail rather than a user-visible
change.

Best,
  -Ryan


On Wed, Feb 7, 2018 at 10:40 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Small types like `Int8#`/`Word8#` were proposed
> https://github.com/ghc-proposals/ghc-proposals/pull/74
>
> I propose Simon Marlow as the Shepherd.
>
> Simon, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> I suggest you make a recommendation 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/20180210/520fbdae/attachment.html>

From chak at justtesting.org  Sun Feb 11 06:43:03 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Sun, 11 Feb 2018 17:43:03 +1100
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CACYs5Aa7or_2Ss4F62ehJBfmP3EvuGmEkzzhrrXEAThMaD03aw@mail.gmail.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
 <9B22C92E-D901-4CE5-A918-A1B0F912F4E3@justtesting.org>
 <CACYs5Aa7or_2Ss4F62ehJBfmP3EvuGmEkzzhrrXEAThMaD03aw@mail.gmail.com>
Message-ID: <3E436D44-6310-4F58-A804-3606D14A54DD@justtesting.org>

Kind signatures may not be the first thing students see, but they pop up pretty quickly, basically when you explain the difference between a manifest type and a type constructor. They also often are part of error messages, even if you don’t do fancy type-level programming and probably don’t import ’Type’ explicitly.

I also think, Haskell is beyond the point where our only worry wrt to textbooks is 101 type material.

So, I think, we need a convenient and concise notation that doesn’t require extra imports.

Manuel

> 11.02.2018 15:05 Ryan Newton <rrnewton at indiana.edu>:
> 
> @Manuel, for you would it be sufficient for *-deprecation to have an eventual plan to put Type prelude?
> 
> I just can't see how, if Haskell were designed today, the "*" convention would come to be.  Personally, I worry more about legacy/textbook issues for topics that are a bit closer to CS101 than I believe kind signatures are.
> 
>  -Ryan
> 
> On Sat, Feb 10, 2018 at 12:42 AM, Manuel M T Chakravarty <chak at justtesting.org <mailto:chak at justtesting.org>> wrote:
> Yes, that’s why I think, we cannot deprecate it until we have an alternative that is not the fully qualified name.
> 
> Manuel
> 
> 
>> Am 10.02.2018 um 04:46 schrieb Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>:
>> 
>> The issue I see is that it is quite common to get a kind error without doing any fancy type level programming---in particular without writing kind signatures or anything like that.  So you'd have no reason to import `Data.Kind(Type)`.    The result would be that GHC would give quite a verbose error message, using the fully qualified name of `Type`.  Unless we did something special.
>> 
>> -Iavor
>> 
>> 
>> On Fri, Feb 9, 2018 at 2:41 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
>> I’m not sure I see the problem here.  If ‘Int’ is not in scope then
>> 
>> f :: Int -> Int
>> 
>> won’t work.  What’s different about ‘Type’
>> 
>>  
>> 
>> Simon
>> 
>>  
>> 
>> From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>] On Behalf Of Richard Eisenberg
>> Sent: 09 February 2018 04:26
>> To: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>
>> Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>
>> Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type
>> 
>>  
>> 
>> Thanks, Iavor, for bringing this up.
>> 
>>  
>> 
>> To clarify the proposal: -XStarIsType is orthogonal to deprecation. The extension is necessary in order to continue to parse existing programs, but if we choose to deprecate *, then we would deprecate even with -XStarIsType is enabled (precisely to avoid the half-deprecation scenario Iavor is worried about).
>> 
>>  
>> 
>> I envisioned always printing Type unqualified in error messages, even if it's not imported. If a user writes Type and it's out of scope, we could always have a special-case check suggesting they import Data.Kind. I won't argue this is a principled design, though, and is likely a poor choice if some other Type is in scope.
>> 
>>  
>> 
>> The truth is that I don't have a great way forward here (and haven't for years) and am very hopeful someone on this list can come up with one! :) The proposal has my best idea, but I'm still not thrilled with it.
>> 
>>  
>> 
>> Thanks,
>> 
>> Richard
>> 
>>  
>> 
>> On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
>> 
>>  
>> 
>> Hello,
>> 
>>  
>> 
>> I didn't see any discussion about the third part of this proposal, namely the addition of a new extension called `StarIsKind`.  The idea is that when this is on, `*` will still be treated as a special alpha-numeric name, and it will *always* refer to the kind of inhabited types (i.e., same as know).  The difference is that it cannot be used as another type-level operator (e.g., for multiplication).
>> 
>>  
>> 
>> Presumably, when this extension is on, there would be no deprecation warning emitted for `*`? We should clarify this in the proposal.
>> 
>>  
>> 
>> I am not certain if this is a good idea.  It makes the use of `*` sort of "half" deprecated, and leaves us with multiple "standard" ways to refer to the same thing (e.g., in type errors).  Also, if we want people to update their code to use `Type` instead of `*`, then we are just delaying the pain point to whenever `StarIsKind` ends up being not on by default.
>> 
>>  
>> 
>> OTOH, if we don't have a standard short-hand way to refer to the kind of inhabited types, I imagine GHC will report some very ugly errors.  For example:
>> 
>>  
>> 
>>     • Expecting one more argument to ‘Maybe’
>> 
>>       Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type -> Data.Kind.Type’
>> 
>>  
>> 
>> And this is for a fairly simple kind error, they get much longer if, say, monad transformers are involved.
>> 
>>  
>> 
>> What do others think?
>> 
>>  
>> 
>> -Iavor
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> wrote:
>> 
>> 
>> > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>> >
>> > In particular in light of our use of “type” as a explicit namespace
>> > token – so far in export and import lists and fixity declarations – I
>> > worry that we will prevent ourselves from using more such explicit
>> > namespace things in the future.
>> 
>> This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does not want to have separate type-level and term-level namespaces. Of course, Haskell has this.
>> 
>> The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.
>> 
>> If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.
>> 
>> All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type` isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.
>> 
>> 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 <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/20180211/62fbfa23/attachment-0001.html>

From mail at joachim-breitner.de  Sun Feb 11 15:04:37 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 11 Feb 2018 10:04:37 -0500
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <3E436D44-6310-4F58-A804-3606D14A54DD@justtesting.org>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
 <9B22C92E-D901-4CE5-A918-A1B0F912F4E3@justtesting.org>
 <CACYs5Aa7or_2Ss4F62ehJBfmP3EvuGmEkzzhrrXEAThMaD03aw@mail.gmail.com>
 <3E436D44-6310-4F58-A804-3606D14A54DD@justtesting.org>
Message-ID: <ED282CCF-B82B-4CBF-AE00-F8310C23F51B@joachim-breitner.de>

Hi,


Am 11. Februar 2018 01:43:03 EST schrieb Manuel M T Chakravarty <chak at justtesting.org>:
>So, I think, we need a convenient and concise notation that doesn’t
>require extra imports.

we have precedence for that: (->) could just as well be a name exported from Data.Function and the Prelude, with all the usual rules around it (qualifications, exports). But it is not, and rather parses as it's own thing. So far, nobody seems to bother about this exception from the rule.

But doing this to `Type` is annoying because existing code out there already used `Type`, in particular GHC.

Maybe if we can find a uncommonly used, short, descriptive name then making that available without imports is viable? Do we have any good ideas?


Joachim

From rae at cs.brynmawr.edu  Sun Feb 11 22:55:12 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 11 Feb 2018 17:55:12 -0500
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <ED282CCF-B82B-4CBF-AE00-F8310C23F51B@joachim-breitner.de>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
 <9B22C92E-D901-4CE5-A918-A1B0F912F4E3@justtesting.org>
 <CACYs5Aa7or_2Ss4F62ehJBfmP3EvuGmEkzzhrrXEAThMaD03aw@mail.gmail.com>
 <3E436D44-6310-4F58-A804-3606D14A54DD@justtesting.org>
 <ED282CCF-B82B-4CBF-AE00-F8310C23F51B@joachim-breitner.de>
Message-ID: <47EE61A9-52C9-4F2F-BF56-F76E651E5F2F@cs.brynmawr.edu>


> Maybe if we can find a uncommonly used, short, descriptive name then making that available without imports is viable? Do we have any good ideas?

My only idea (it's bad) is Sort. This is inspired by Pure Type Systems, where a type system is parametrized by a set of sorts, and (ignoring levity polymorphism and unlifted types), Haskell has one sort, which could be called Sort.

This is a bad idea for two reasons:
 - The motivation behind the name requires a reference to PTSs, which are advanced and esoteric.
 - It has nothing to do with, e.g., bubble sort, as everyone will be asking us into perpetuity.

I've been told that brainstorming works best when even bad ideas are brought up, and so I've done so. :)

Richard

> 
> 
> Joachim
> _______________________________________________
> 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  Mon Feb 12 00:28:14 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 11 Feb 2018 19:28:14 -0500
Subject: [ghc-steering-committee] Unlifted Newtypes (#98)
Message-ID: <C4725662-BF52-4770-B2A7-16B2F8547A12@cs.brynmawr.edu>

I have been assigned as the shepherd for proposal #98: Unlifted Newtypes, https://github.com/ghc-proposals/ghc-proposals/pull/98

Summary:

This proposal suggests lifting the current restriction that newtype kinds are always Type -- that is, TYPE LiftedRep. At its core, that's the entire proposal; the rest is just motivation (which is quite well-written, if you're feeling unmotivated) and consequences. Here are a few of the twists and turns:

- The non-Type kinds should be inferred, based on the kind of the wrapped type. In the event of a trivial recursive newtype (e.g., newtype Void = Void Void), the kind would default to lifted, though the user could override this behavior with a kind signature using GADT syntax. The proposal author conjectures that all inhabited unlifted newtypes will have inferrable kinds; I've not tried hard to prove or refute this claim.

- The proposal suggests that the Coercible mechanism be extended to deal with unlifted types. This could be handled by generalizing the type of `coerce` to be levity-polymorphic. Note that doing so does not violate levity polymorphism restrictions, because coerce always inlines to a cast, and casts are erased before code generation. If `coerce` is generalized, GeneralizedNewtypeDeriving will work over the new unlifted newtypes.

- The proposal suggests that newtypes can indeed be levity-polymorphic: newtype Id# (r :: RuntimeRep) (a :: TYPE r) = MkId# a. This does not appear to violate levity polymorphism restrictions, either, because the MkId# constructor doesn't appear in Core. Any use of this newtype will have to be specialized to a certain RuntimeRep, but that specialization would already be guaranteed by the existing levity polymorphism restrictions.

The main drawback in the proposal is that this is the first way users can create their own unlifted types. Accordingly, a user might unwittingly use an unlifted type where they expect laziness; the strictness that, say, an unlifted-variable pattern binding would induce would be a surprise and hard to find.

Opinion & recommendation:

I am in support of this proposal and propose acceptance. The motivation section in the proposal is compelling, and this seems a natural generalization of existing structures. There are no concrete syntax ramifications. Given the existing levity polymorphism set-up, this proposal seems like an easy win.

If we are concerned about unexpected strictness, we could require that all unlifted newtypes be suffixed with one or more hashes, but I do not recommend doing so, instead encouraging library-writers to be sensitive to this problem, giving those authors the latitude to choose the best name for their types.

Thanks,
Richard


From chak at justtesting.org  Mon Feb 12 03:54:16 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Mon, 12 Feb 2018 14:54:16 +1100
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <ED282CCF-B82B-4CBF-AE00-F8310C23F51B@joachim-breitner.de>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
 <9B22C92E-D901-4CE5-A918-A1B0F912F4E3@justtesting.org>
 <CACYs5Aa7or_2Ss4F62ehJBfmP3EvuGmEkzzhrrXEAThMaD03aw@mail.gmail.com>
 <3E436D44-6310-4F58-A804-3606D14A54DD@justtesting.org>
 <ED282CCF-B82B-4CBF-AE00-F8310C23F51B@joachim-breitner.de>
Message-ID: <5917D40C-96ED-4BE6-8DEE-84C1101DE88B@justtesting.org>

Yes, existing code uses ’Type’, but it also uses ’*’ (GHC included) — i.e., this change is going to be a pain for some devs anyway. A pragma that couples the removal of ’*’ as a synonym for ’Type’ with the implicit importing of ’Type’ could encourage people to just apply both changes in one go.

Manuel

> Am 12.02.2018 um 02:04 schrieb Joachim Breitner <mail at joachim-breitner.de>:
> 
> Hi,
> 
> 
> Am 11. Februar 2018 01:43:03 EST schrieb Manuel M T Chakravarty <chak at justtesting.org>:
>> So, I think, we need a convenient and concise notation that doesn’t
>> require extra imports.
> 
> we have precedence for that: (->) could just as well be a name exported from Data.Function and the Prelude, with all the usual rules around it (qualifications, exports). But it is not, and rather parses as it's own thing. So far, nobody seems to bother about this exception from the rule.
> 
> But doing this to `Type` is annoying because existing code out there already used `Type`, in particular GHC.
> 
> Maybe if we can find a uncommonly used, short, descriptive name then making that available without imports is viable? Do we have any good ideas?
> 
> 
> Joachim
> _______________________________________________
> 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 Feb 12 15:37:26 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 12 Feb 2018 10:37:26 -0500
Subject: [ghc-steering-committee] Please review: plugin recompilation
	avoidance, Shepherd: Ben Gamari
Message-ID: <1518449846.1077.1.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

An API for deciding whether plugins should cause recompilation was proposed:
https://github.com/ghc-proposals/ghc-proposals/pull/108

I propose Ben Gamari as the Shepherd.

Ben, please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process

I suggest you make a recommendation 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/20180212/64c0d0be/attachment.sig>

From rrnewton at gmail.com  Sun Feb 11 05:43:35 2018
From: rrnewton at gmail.com (Ryan Newton)
Date: Sun, 11 Feb 2018 00:43:35 -0500
Subject: [ghc-steering-committee] Please review: Mutable constructor
	fields, Shepherd: Ryan Newton
In-Reply-To: <1500034660.7133.5.camel@joachim-breitner.de>
References: <1500034660.7133.5.camel@joachim-breitner.de>
Message-ID: <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>

Reboot!  This has long sat idle, but I propose to now formally start the
committee discussion period: mandatory 4 weeks, closing at end of day *March
10th*, or earlier if consensus occurs.  Let's use this email thread for
that discussion.  In this mail I summarize public discussion and *argue for
"accept"*.

In short, the proposal adds a way to have multiple mutable fields within a
data-constructor, without the indirection of using IORef.  Second to "linear
types" <https://github.com/ghc-proposals/ghc-proposals/pull/91>, this
proposal <https://github.com/ghc-proposals/ghc-proposals/pull/8> generated
the most total comments during public discussion (107).  This level of
discussion was good -- given that accepted GHC proposals so far are mostly
syntactic (or API tweaks), this would be the first with major compiler
backend & runtime consequences.

Ed Kmett and Ryan Yates have demonstrated the applicability of this concept
to data-structure implementation.  (Indeed, I think there's a good reason
that almost all languages mutation with mutation are implemented so as to
allow a single heap object to have multiple mutable fields within it.)
During the public discussion, questions were raised about interactions with
other features and implementation strategy -- in particularly changes to
core.  But I believe that all major concerns were eventually answered.

  -Ryan

P.S. Iavor, Trevor, and Ryan Yates were all working on implementation of
this feature at various points.  Not sure what the current status of
implementation efforts are.


On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/8
> was brought before the committee, by our own Simon Marlow.
>
> I propose Ryan Newton as the Shepherd, because he asked for it :-)
>
> Ryan, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> I suggest you make a recommendation about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
>
>
> Greetings,
> Joachim
>
>
> --
> 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/20180211/76a94076/attachment.html>

From iavor.diatchki at gmail.com  Mon Feb 12 17:18:54 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 12 Feb 2018 17:18:54 +0000
Subject: [ghc-steering-committee] Unlifted Newtypes (#98)
In-Reply-To: <C4725662-BF52-4770-B2A7-16B2F8547A12@cs.brynmawr.edu>
References: <C4725662-BF52-4770-B2A7-16B2F8547A12@cs.brynmawr.edu>
Message-ID: <CAGK9nuo2j9ryf1B3UwfLJhxR1cja0_gQZNUCmmYT6rkgH_dp4A@mail.gmail.com>

I support this proposal.  I think that having newtypes for non-lifted types
(e.g., `Int#`) can be quite handy.

On Sun, Feb 11, 2018 at 4:28 PM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> I have been assigned as the shepherd for proposal #98: Unlifted Newtypes,
> https://github.com/ghc-proposals/ghc-proposals/pull/98
>
> Summary:
>
> This proposal suggests lifting the current restriction that newtype kinds
> are always Type -- that is, TYPE LiftedRep. At its core, that's the entire
> proposal; the rest is just motivation (which is quite well-written, if
> you're feeling unmotivated) and consequences. Here are a few of the twists
> and turns:
>
> - The non-Type kinds should be inferred, based on the kind of the wrapped
> type. In the event of a trivial recursive newtype (e.g., newtype Void =
> Void Void), the kind would default to lifted, though the user could
> override this behavior with a kind signature using GADT syntax. The
> proposal author conjectures that all inhabited unlifted newtypes will have
> inferrable kinds; I've not tried hard to prove or refute this claim.
>
> - The proposal suggests that the Coercible mechanism be extended to deal
> with unlifted types. This could be handled by generalizing the type of
> `coerce` to be levity-polymorphic. Note that doing so does not violate
> levity polymorphism restrictions, because coerce always inlines to a cast,
> and casts are erased before code generation. If `coerce` is generalized,
> GeneralizedNewtypeDeriving will work over the new unlifted newtypes.
>
> - The proposal suggests that newtypes can indeed be levity-polymorphic:
> newtype Id# (r :: RuntimeRep) (a :: TYPE r) = MkId# a. This does not appear
> to violate levity polymorphism restrictions, either, because the MkId#
> constructor doesn't appear in Core. Any use of this newtype will have to be
> specialized to a certain RuntimeRep, but that specialization would already
> be guaranteed by the existing levity polymorphism restrictions.
>
> The main drawback in the proposal is that this is the first way users can
> create their own unlifted types. Accordingly, a user might unwittingly use
> an unlifted type where they expect laziness; the strictness that, say, an
> unlifted-variable pattern binding would induce would be a surprise and hard
> to find.
>
> Opinion & recommendation:
>
> I am in support of this proposal and propose acceptance. The motivation
> section in the proposal is compelling, and this seems a natural
> generalization of existing structures. There are no concrete syntax
> ramifications. Given the existing levity polymorphism set-up, this proposal
> seems like an easy win.
>
> If we are concerned about unexpected strictness, we could require that all
> unlifted newtypes be suffixed with one or more hashes, but I do not
> recommend doing so, instead encouraging library-writers to be sensitive to
> this problem, giving those authors the latitude to choose the best name for
> their types.
>
> Thanks,
> Richard
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180212/7f928730/attachment.html>

From iavor.diatchki at gmail.com  Mon Feb 12 17:24:54 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 12 Feb 2018 17:24:54 +0000
Subject: [ghc-steering-committee] Please review: Mutable constructor
 fields, Shepherd: Ryan Newton
In-Reply-To: <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
References: <1500034660.7133.5.camel@joachim-breitner.de>
 <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
Message-ID: <CAGK9nuq5Jf9GfXSECkAhMCExNMhx9ZsG4N7ZmJMLUi=Ne04Dig@mail.gmail.com>

I support this.

The status of the implementation, at least on my end. is stalled a bit, as
I've been really busy with work.    Overall though, Ryan has a version that
works for STM (although it is against an older GHC and mixed up with other
experiments he is working on).   I also have a branch, where we've
implemented the basic primitives, and started work on the front-end, but
there is quite a bit to do still (e.g., we haven't really done code the
code generation changes).  I'd say there are a bunch of interesting
implementation questions that we need to answer, but in terms of the
user-facing language changes, the proposal seems sound to me.

On Mon, Feb 12, 2018 at 9:13 AM Ryan Newton <rrnewton at gmail.com> wrote:

> Reboot!  This has long sat idle, but I propose to now formally start the
> committee discussion period: mandatory 4 weeks, closing at end of day *March
> 10th*, or earlier if consensus occurs.  Let's use this email thread for
> that discussion.  In this mail I summarize public discussion and *argue
> for "accept"*.
>
> In short, the proposal adds a way to have multiple mutable fields within
> a data-constructor, without the indirection of using IORef.  Second to "linear
> types" <https://github.com/ghc-proposals/ghc-proposals/pull/91>, this
> proposal <https://github.com/ghc-proposals/ghc-proposals/pull/8>
> generated the most total comments during public discussion (107).  This
> level of discussion was good -- given that accepted GHC proposals so far
> are mostly syntactic (or API tweaks), this would be the first with major
> compiler backend & runtime consequences.
>
> Ed Kmett and Ryan Yates have demonstrated the applicability of this
> concept to data-structure implementation.  (Indeed, I think there's a good
> reason that almost all languages mutation with mutation are implemented so
> as to allow a single heap object to have multiple mutable fields within
> it.) During the public discussion, questions were raised about interactions
> with other features and implementation strategy -- in particularly changes
> to core.  But I believe that all major concerns were eventually answered.
>
>   -Ryan
>
> P.S. Iavor, Trevor, and Ryan Yates were all working on implementation of
> this feature at various points.  Not sure what the current status of
> implementation efforts are.
>
>
> On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
>> Dear Committee,
>>
>> this is your secretary speaking:
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/8
>> was brought before the committee, by our own Simon Marlow.
>>
>> I propose Ryan Newton as the Shepherd, because he asked for it :-)
>>
>> Ryan, please reach consensus as described in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> I suggest you make a recommendation about the decision, maybe point out
>> debatable points, and assume that anyone who stays quiet agrees with
>> you.
>>
>>
>> Greetings,
>> 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/20180212/c72dffb9/attachment-0001.html>

From iavor.diatchki at gmail.com  Mon Feb 12 17:25:32 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 12 Feb 2018 17:25:32 +0000
Subject: [ghc-steering-committee] Please review: Int8/Word8,
 Shepherd: Simon Marlow
In-Reply-To: <CACYs5Aa8QFMSU03CO8JKLgMCKYXp9oAsP8yChSYPjF1oSHWX3A@mail.gmail.com>
References: <1518061232.1186.1.camel@joachim-breitner.de>
 <CACYs5Aa8QFMSU03CO8JKLgMCKYXp9oAsP8yChSYPjF1oSHWX3A@mail.gmail.com>
Message-ID: <CAGK9nuou7DqsG5TKCd6uK+z57SOjFyx37e_MdptCum2Tvhj0=g@mail.gmail.com>

I support this proposal also.

On Sat, Feb 10, 2018 at 8:16 PM Ryan Newton <rrnewton at indiana.edu> wrote:

> This sounds great, especially as the proposer is working on implementing
> it.  Let's accept!
>
> As a procedural note, it seems like if the calling conventions *were*
> ever changed (to avoid "rounding up" everything to 64 bits between caller
> and callee), that that improvement would not need to go through the
> proposals process.  I.e., it's an implementation detail rather than a
> user-visible change.
>
> Best,
>   -Ryan
>
>
> On Wed, Feb 7, 2018 at 10:40 PM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
>> Dear Committee,
>>
>> this is your secretary speaking:
>>
>> Small types like `Int8#`/`Word8#` were proposed
>> https://github.com/ghc-proposals/ghc-proposals/pull/74
>>
>> I propose Simon Marlow as the Shepherd.
>>
>> Simon, please reach consensus as described in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> I suggest you make a recommendation about the decision, maybe point out
>> debatable points, and assume that anyone who stays quiet agrees with
>> you.
>>
>> Thanks,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180212/121b2b7b/attachment.html>

From iavor.diatchki at gmail.com  Mon Feb 12 17:29:59 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 12 Feb 2018 17:29:59 +0000
Subject: [ghc-steering-committee] Do we consider the GHC API in scope?
In-Reply-To: <1517925446.1079.7.camel@joachim-breitner.de>
References: <1517870520.23352.2.camel@joachim-breitner.de>
 <87k1vqzw7j.fsf@smart-cactus.org>
 <AM5PR83MB016355CDEFCF61CF2DA35F1FADFD0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1517925446.1079.7.camel@joachim-breitner.de>
Message-ID: <CAGK9nuqOyM0xG4yjFXesgGDfX8-9KJ16T95K+dsF68wg2dWwyg@mail.gmail.com>

I don't think we should be overly controlling on this and lean towards
being flexible with making changes in the source code as needed.   Overall
my experience with the GHC API has been that it can be very handy, but I've
never managed to get anything done by just sticking to the API proper---I
inevitably end up using other "unofficial" modules from GHC, and I don't
think it is reasonable to expect that none of those would change.    Long
term, it would be nice to have a stable GHC API, but the actual API depends
very much on what you are trying to do, so I can even imagine there being
more than one API.  Until that day though, I like Joachim's phrasing.








On Tue, Feb 6, 2018 at 5:57 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Dienstag, den 06.02.2018, 09:27 +0000 schrieb Simon Peyton Jones:
> > I think we should cover GHC API changes.
> >
> > * The committee is meant to cover the "users-eye-view" of GHC.
> >   The GHC API is a major asset, used by many users.  OK, so they
> >   are nestling a bit closer to the implementation, but still.
> >
> > * There is no other forum to discuss API changes.
> >
> > * In principle a user of GHC-as-a-library can call any old internal
> >   function; we should /not/ cover this.  Only the high-level
> >   "advertised" API.
> >
> > * We don't do a good job of advertising that API; it's basically
> >   what is exported by module GHC.  But I think it that proposals
> >   focused on improving it would be quite helpful.
>
> just for the reference, that would be this module:
>
> https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.2.2/src/GHC.html
>
> So in particular, every change in HsSyn is no longer an internal change
> under that view, as is any modification to DynFlags.
>
> And I presume you’d include
>
> https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.2.2/Plugins.html
> and/or
>
> https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.2.2/GhcPlugins.html
> to be considered part of the API as well, right? But the latter re-
> exports really many internal modules.
>
> Under this rule, a change like
>
> https://git.haskell.org/ghc.git/commitdiff/0e022e56b130ab9d277965b794e70d8d3fb29533
> would have required committee approval?
>
>
> I am worried about adding too much red tape to GHC development and
> overloading the committee. How about this as a compromise:
>
>     Changes to the GHC or Plugin API are not automatically within the
>     scope of the committee, and can be contributed following the usual
>     GHC workflow. Should the GHC maintainers deem a change significant
>     or controversial enough to warrant that, they may, at their
>     discretion, involve the committee and ask the contributor to write a
>     formal proposal.
>
> Cheers,
> Joachim
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180212/e3b20777/attachment.html>

From mail at joachim-breitner.de  Mon Feb 12 17:36:58 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 12 Feb 2018 12:36:58 -0500
Subject: [ghc-steering-committee] Do we consider the GHC API in scope?
In-Reply-To: <CAGK9nuqOyM0xG4yjFXesgGDfX8-9KJ16T95K+dsF68wg2dWwyg@mail.gmail.com>
References: <1517870520.23352.2.camel@joachim-breitner.de>
 <87k1vqzw7j.fsf@smart-cactus.org>
 <AM5PR83MB016355CDEFCF61CF2DA35F1FADFD0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1517925446.1079.7.camel@joachim-breitner.de>
 <CAGK9nuqOyM0xG4yjFXesgGDfX8-9KJ16T95K+dsF68wg2dWwyg@mail.gmail.com>
Message-ID: <1518457018.1077.3.camel@joachim-breitner.de>

Hi,

Am Montag, den 12.02.2018, 17:29 +0000 schrieb Iavor Diatchki:
> Until that day though, I like Joachim's phrasing.

added the wording to the README at
https://github.com/ghc-proposals/ghc-proposals

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/20180212/081a6dea/attachment.sig>

From chak at justtesting.org  Tue Feb 13 02:43:26 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 13 Feb 2018 13:43:26 +1100
Subject: [ghc-steering-committee] Unlifted Newtypes (#98)
In-Reply-To: <C4725662-BF52-4770-B2A7-16B2F8547A12@cs.brynmawr.edu>
References: <C4725662-BF52-4770-B2A7-16B2F8547A12@cs.brynmawr.edu>
Message-ID: <3A79812C-E21D-4D03-B468-F4D29C7723D2@justtesting.org>

Given that you think the levity polymorphism-related implications are fine, the proposal seems fine to me.

Manuel

> 12.02.2018 11:28 Richard Eisenberg <rae at cs.brynmawr.edu>:
> 
> I have been assigned as the shepherd for proposal #98: Unlifted Newtypes, https://github.com/ghc-proposals/ghc-proposals/pull/98
> 
> Summary:
> 
> This proposal suggests lifting the current restriction that newtype kinds are always Type -- that is, TYPE LiftedRep. At its core, that's the entire proposal; the rest is just motivation (which is quite well-written, if you're feeling unmotivated) and consequences. Here are a few of the twists and turns:
> 
> - The non-Type kinds should be inferred, based on the kind of the wrapped type. In the event of a trivial recursive newtype (e.g., newtype Void = Void Void), the kind would default to lifted, though the user could override this behavior with a kind signature using GADT syntax. The proposal author conjectures that all inhabited unlifted newtypes will have inferrable kinds; I've not tried hard to prove or refute this claim.
> 
> - The proposal suggests that the Coercible mechanism be extended to deal with unlifted types. This could be handled by generalizing the type of `coerce` to be levity-polymorphic. Note that doing so does not violate levity polymorphism restrictions, because coerce always inlines to a cast, and casts are erased before code generation. If `coerce` is generalized, GeneralizedNewtypeDeriving will work over the new unlifted newtypes.
> 
> - The proposal suggests that newtypes can indeed be levity-polymorphic: newtype Id# (r :: RuntimeRep) (a :: TYPE r) = MkId# a. This does not appear to violate levity polymorphism restrictions, either, because the MkId# constructor doesn't appear in Core. Any use of this newtype will have to be specialized to a certain RuntimeRep, but that specialization would already be guaranteed by the existing levity polymorphism restrictions.
> 
> The main drawback in the proposal is that this is the first way users can create their own unlifted types. Accordingly, a user might unwittingly use an unlifted type where they expect laziness; the strictness that, say, an unlifted-variable pattern binding would induce would be a surprise and hard to find.
> 
> Opinion & recommendation:
> 
> I am in support of this proposal and propose acceptance. The motivation section in the proposal is compelling, and this seems a natural generalization of existing structures. There are no concrete syntax ramifications. Given the existing levity polymorphism set-up, this proposal seems like an easy win.
> 
> If we are concerned about unexpected strictness, we could require that all unlifted newtypes be suffixed with one or more hashes, but I do not recommend doing so, instead encouraging library-writers to be sensitive to this problem, giving those authors the latitude to choose the best name for their types.
> 
> Thanks,
> Richard
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From ben at well-typed.com  Wed Feb 14 05:43:25 2018
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 14 Feb 2018 00:43:25 -0500
Subject: [ghc-steering-committee] Please review: plugin recompilation
	avoidance, Shepherd: Ben Gamari
In-Reply-To: <1518449846.1077.1.camel@joachim-breitner.de>
References: <1518449846.1077.1.camel@joachim-breitner.de>
Message-ID: <87d118w2h4.fsf@smart-cactus.org>

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

> Dear Committee,
>
> this is your secretary speaking:
>
> An API for deciding whether plugins should cause recompilation was proposed:
> https://github.com/ghc-proposals/ghc-proposals/pull/108
>
> I propose Ben Gamari as the Shepherd.
>
> Ben, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
Thanks Joachim!

Cheers,

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

From iavor.diatchki at gmail.com  Wed Feb 14 18:49:57 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 14 Feb 2018 18:49:57 +0000
Subject: [ghc-steering-committee] Please review: Mutable constructor
 fields, Shepherd: Ryan Newton
In-Reply-To: <CACYs5AaqzxzQdbkFs+caL8S_PeNdQvNNtcyQ9BxQ=qNAurqFoA@mail.gmail.com>
References: <1500034660.7133.5.camel@joachim-breitner.de>
 <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
 <CAGK9nuq5Jf9GfXSECkAhMCExNMhx9ZsG4N7ZmJMLUi=Ne04Dig@mail.gmail.com>
 <CACYs5AaqzxzQdbkFs+caL8S_PeNdQvNNtcyQ9BxQ=qNAurqFoA@mail.gmail.com>
Message-ID: <CAGK9nupbOSZ-jTkenYbrRpvO2CMjz-bG8a6Hs3kdsoo9BooG0g@mail.gmail.com>

Perhaps, although I am not sure it is really worth the extra effort.  I
think if we agree to accept this (which I hope we do), we can just
implement it as intended.   I have some work hours that I've put aside to
work on this, once it is properly approved.






On Mon, Feb 12, 2018 at 9:29 AM Ryan Newton <rrnewton at gmail.com> wrote:

> Ah, I see, does it make sense for it to be implemented "frontend only"
> first, with it desugaring into the current MutVar# primitives in the
> backend?
>
>
> On Mon, Feb 12, 2018 at 12:24 PM, Iavor Diatchki <iavor.diatchki at gmail.com
> > wrote:
>
>> I support this.
>>
>> The status of the implementation, at least on my end. is stalled a bit,
>> as I've been really busy with work.    Overall though, Ryan has a version
>> that works for STM (although it is against an older GHC and mixed up with
>> other experiments he is working on).   I also have a branch, where we've
>> implemented the basic primitives, and started work on the front-end, but
>> there is quite a bit to do still (e.g., we haven't really done code the
>> code generation changes).  I'd say there are a bunch of interesting
>> implementation questions that we need to answer, but in terms of the
>> user-facing language changes, the proposal seems sound to me.
>>
>> On Mon, Feb 12, 2018 at 9:13 AM Ryan Newton <rrnewton at gmail.com> wrote:
>>
>>> Reboot!  This has long sat idle, but I propose to now formally start the
>>> committee discussion period: mandatory 4 weeks, closing at end of day *March
>>> 10th*, or earlier if consensus occurs.  Let's use this email thread for
>>> that discussion.  In this mail I summarize public discussion and *argue
>>> for "accept"*.
>>>
>>> In short, the proposal adds a way to have multiple mutable fields
>>> within a data-constructor, without the indirection of using IORef.  Second
>>> to "linear types"
>>> <https://github.com/ghc-proposals/ghc-proposals/pull/91>, this proposal
>>> <https://github.com/ghc-proposals/ghc-proposals/pull/8> generated the
>>> most total comments during public discussion (107).  This level of
>>> discussion was good -- given that accepted GHC proposals so far are mostly
>>> syntactic (or API tweaks), this would be the first with major compiler
>>> backend & runtime consequences.
>>>
>>> Ed Kmett and Ryan Yates have demonstrated the applicability of this
>>> concept to data-structure implementation.  (Indeed, I think there's a good
>>> reason that almost all languages mutation with mutation are implemented so
>>> as to allow a single heap object to have multiple mutable fields within
>>> it.) During the public discussion, questions were raised about interactions
>>> with other features and implementation strategy -- in particularly changes
>>> to core.  But I believe that all major concerns were eventually answered.
>>>
>>>   -Ryan
>>>
>>> P.S. Iavor, Trevor, and Ryan Yates were all working on implementation of
>>> this feature at various points.  Not sure what the current status of
>>> implementation efforts are.
>>>
>>>
>>> On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <
>>> mail at joachim-breitner.de> wrote:
>>>
>>>> Dear Committee,
>>>>
>>>> this is your secretary speaking:
>>>>
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/8
>>>> was brought before the committee, by our own Simon Marlow.
>>>>
>>>> I propose Ryan Newton as the Shepherd, because he asked for it :-)
>>>>
>>>> Ryan, please reach consensus as described in
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>
>>>> I suggest you make a recommendation about the decision, maybe point out
>>>> debatable points, and assume that anyone who stays quiet agrees with
>>>> you.
>>>>
>>>>
>>>> Greetings,
>>>> 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/20180214/398bf72a/attachment.html>

From rrnewton at gmail.com  Mon Feb 12 17:29:37 2018
From: rrnewton at gmail.com (Ryan Newton)
Date: Mon, 12 Feb 2018 12:29:37 -0500
Subject: [ghc-steering-committee] Please review: Mutable constructor
 fields, Shepherd: Ryan Newton
In-Reply-To: <CAGK9nuq5Jf9GfXSECkAhMCExNMhx9ZsG4N7ZmJMLUi=Ne04Dig@mail.gmail.com>
References: <1500034660.7133.5.camel@joachim-breitner.de>
 <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
 <CAGK9nuq5Jf9GfXSECkAhMCExNMhx9ZsG4N7ZmJMLUi=Ne04Dig@mail.gmail.com>
Message-ID: <CACYs5AaqzxzQdbkFs+caL8S_PeNdQvNNtcyQ9BxQ=qNAurqFoA@mail.gmail.com>

Ah, I see, does it make sense for it to be implemented "frontend only"
first, with it desugaring into the current MutVar# primitives in the
backend?


On Mon, Feb 12, 2018 at 12:24 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> I support this.
>
> The status of the implementation, at least on my end. is stalled a bit, as
> I've been really busy with work.    Overall though, Ryan has a version that
> works for STM (although it is against an older GHC and mixed up with other
> experiments he is working on).   I also have a branch, where we've
> implemented the basic primitives, and started work on the front-end, but
> there is quite a bit to do still (e.g., we haven't really done code the
> code generation changes).  I'd say there are a bunch of interesting
> implementation questions that we need to answer, but in terms of the
> user-facing language changes, the proposal seems sound to me.
>
> On Mon, Feb 12, 2018 at 9:13 AM Ryan Newton <rrnewton at gmail.com> wrote:
>
>> Reboot!  This has long sat idle, but I propose to now formally start the
>> committee discussion period: mandatory 4 weeks, closing at end of day *March
>> 10th*, or earlier if consensus occurs.  Let's use this email thread for
>> that discussion.  In this mail I summarize public discussion and *argue
>> for "accept"*.
>>
>> In short, the proposal adds a way to have multiple mutable fields within
>> a data-constructor, without the indirection of using IORef.  Second to "linear
>> types" <https://github.com/ghc-proposals/ghc-proposals/pull/91>, this
>> proposal <https://github.com/ghc-proposals/ghc-proposals/pull/8>
>> generated the most total comments during public discussion (107).  This
>> level of discussion was good -- given that accepted GHC proposals so far
>> are mostly syntactic (or API tweaks), this would be the first with major
>> compiler backend & runtime consequences.
>>
>> Ed Kmett and Ryan Yates have demonstrated the applicability of this
>> concept to data-structure implementation.  (Indeed, I think there's a good
>> reason that almost all languages mutation with mutation are implemented so
>> as to allow a single heap object to have multiple mutable fields within
>> it.) During the public discussion, questions were raised about interactions
>> with other features and implementation strategy -- in particularly changes
>> to core.  But I believe that all major concerns were eventually answered.
>>
>>   -Ryan
>>
>> P.S. Iavor, Trevor, and Ryan Yates were all working on implementation of
>> this feature at various points.  Not sure what the current status of
>> implementation efforts are.
>>
>>
>> On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>>> Dear Committee,
>>>
>>> this is your secretary speaking:
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/8
>>> was brought before the committee, by our own Simon Marlow.
>>>
>>> I propose Ryan Newton as the Shepherd, because he asked for it :-)
>>>
>>> Ryan, please reach consensus as described in
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>
>>> I suggest you make a recommendation about the decision, maybe point out
>>> debatable points, and assume that anyone who stays quiet agrees with
>>> you.
>>>
>>>
>>> Greetings,
>>> 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/20180212/db243559/attachment.html>

From rae at cs.brynmawr.edu  Fri Feb 16 19:42:09 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 16 Feb 2018 14:42:09 -0500
Subject: [ghc-steering-committee] Please review: Mutable constructor
	fields, Shepherd: Ryan Newton
In-Reply-To: <CAGK9nupbOSZ-jTkenYbrRpvO2CMjz-bG8a6Hs3kdsoo9BooG0g@mail.gmail.com>
References: <1500034660.7133.5.camel@joachim-breitner.de>
 <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
 <CAGK9nuq5Jf9GfXSECkAhMCExNMhx9ZsG4N7ZmJMLUi=Ne04Dig@mail.gmail.com>
 <CACYs5AaqzxzQdbkFs+caL8S_PeNdQvNNtcyQ9BxQ=qNAurqFoA@mail.gmail.com>
 <CAGK9nupbOSZ-jTkenYbrRpvO2CMjz-bG8a6Hs3kdsoo9BooG0g@mail.gmail.com>
Message-ID: <33016754-2802-47E0-87B3-0BBD80C12FFE@cs.brynmawr.edu>

I have not followed the discussion on this one, but I have a clarifying question:

- The proposal describes the shape of the mutable constructors very concretely, offering the PrimMonad formulation separate from IO and ST. However, doesn't the PrimMonad case subsume IO and ST? That is, couldn't we remove the points about IO and ST? Or is the check very syntactic and require one of those concrete syntactic shapes?

Otherwise, I'm not very knowledgeable about this end of the operation. I'll go with the consensus opinion on this.

Richard

> On Feb 14, 2018, at 1:49 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Perhaps, although I am not sure it is really worth the extra effort.  I think if we agree to accept this (which I hope we do), we can just implement it as intended.   I have some work hours that I've put aside to work on this, once it is properly approved.
> 
> 
> 
> 
> 
> 
> On Mon, Feb 12, 2018 at 9:29 AM Ryan Newton <rrnewton at gmail.com <mailto:rrnewton at gmail.com>> wrote:
> Ah, I see, does it make sense for it to be implemented "frontend only" first, with it desugaring into the current MutVar# primitives in the backend?
> 
> 
> On Mon, Feb 12, 2018 at 12:24 PM, Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
> I support this.  
> 
> The status of the implementation, at least on my end. is stalled a bit, as I've been really busy with work.    Overall though, Ryan has a version that works for STM (although it is against an older GHC and mixed up with other experiments he is working on).   I also have a branch, where we've implemented the basic primitives, and started work on the front-end, but there is quite a bit to do still (e.g., we haven't really done code the code generation changes).  I'd say there are a bunch of interesting implementation questions that we need to answer, but in terms of the user-facing language changes, the proposal seems sound to me.
> 
> On Mon, Feb 12, 2018 at 9:13 AM Ryan Newton <rrnewton at gmail.com <mailto:rrnewton at gmail.com>> wrote:
> Reboot!  This has long sat idle, but I propose to now formally start the committee discussion period: mandatory 4 weeks, closing at end of day March 10th, or earlier if consensus occurs.  Let's use this email thread for that discussion.  In this mail I summarize public discussion and argue for "accept".
> 
> In short, the proposal adds a way to have multiple mutable fields within a data-constructor, without the indirection of using IORef.  Second to "linear types" <https://github.com/ghc-proposals/ghc-proposals/pull/91>, this proposal <https://github.com/ghc-proposals/ghc-proposals/pull/8> generated the most total comments during public discussion (107).  This level of discussion was good -- given that accepted GHC proposals so far are mostly syntactic (or API tweaks), this would be the first with major compiler backend & runtime consequences.  
> 
> Ed Kmett and Ryan Yates have demonstrated the applicability of this concept to data-structure implementation.  (Indeed, I think there's a good reason that almost all languages mutation with mutation are implemented so as to allow a single heap object to have multiple mutable fields within it.) During the public discussion, questions were raised about interactions with other features and implementation strategy -- in particularly changes to core.  But I believe that all major concerns were eventually answered.
> 
>   -Ryan
> 
> P.S. Iavor, Trevor, and Ryan Yates were all working on implementation of this feature at various points.  Not sure what the current status of implementation efforts are.
> 
> 
> On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/8 <https://github.com/ghc-proposals/ghc-proposals/pull/8>
> was brought before the committee, by our own Simon Marlow.
> 
> I propose Ryan Newton as the Shepherd, because he asked for it :-)
> 
> Ryan, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> 
> I suggest you make a recommendation about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
> 
> 
> Greetings,
> Joachim
> 
> 
> --
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From rrnewton at gmail.com  Mon Feb 19 16:53:53 2018
From: rrnewton at gmail.com (Ryan Newton)
Date: Mon, 19 Feb 2018 11:53:53 -0500
Subject: [ghc-steering-committee] Please review: Mutable constructor
 fields, Shepherd: Ryan Newton
In-Reply-To: <33016754-2802-47E0-87B3-0BBD80C12FFE@cs.brynmawr.edu>
References: <1500034660.7133.5.camel@joachim-breitner.de>
 <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
 <CAGK9nuq5Jf9GfXSECkAhMCExNMhx9ZsG4N7ZmJMLUi=Ne04Dig@mail.gmail.com>
 <CACYs5AaqzxzQdbkFs+caL8S_PeNdQvNNtcyQ9BxQ=qNAurqFoA@mail.gmail.com>
 <CAGK9nupbOSZ-jTkenYbrRpvO2CMjz-bG8a6Hs3kdsoo9BooG0g@mail.gmail.com>
 <33016754-2802-47E0-87B3-0BBD80C12FFE@cs.brynmawr.edu>
Message-ID: <CACYs5AZBPurRJ0xsqOj06TOz6PgET-Zm3nE0FtyH41PwGqPBEg@mail.gmail.com>

Hi Richard,

My feeling is that "what to allow re: IO/ST/PrimMonad" is can be changed
later if needed.  From a minimality perspective, yes, IO and ST may be
subsumed by a more generic form.  But I think they are probably pretty
important as convenience features.  (And from the perspective of IO being a
PrimMonad, it's just a specialization of an already valid type, which seems
pretty reasonable.)

I was also concerned about a syntactic check, e.g. problems with type
synonyms.  Simon M's response was here:
https://github.com/ghc-proposals/ghc-proposals/pull/8#issuecomment-315449267


-Ryan

On Fri, Feb 16, 2018 at 2:42 PM, Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> I have not followed the discussion on this one, but I have a clarifying
> question:
>
> - The proposal describes the shape of the mutable constructors very
> concretely, offering the PrimMonad formulation separate from IO and ST.
> However, doesn't the PrimMonad case subsume IO and ST? That is, couldn't we
> remove the points about IO and ST? Or is the check very syntactic and
> require one of those concrete syntactic shapes?
>
> Otherwise, I'm not very knowledgeable about this end of the operation.
> I'll go with the consensus opinion on this.
>
> Richard
>
> On Feb 14, 2018, at 1:49 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> Perhaps, although I am not sure it is really worth the extra effort.  I
> think if we agree to accept this (which I hope we do), we can just
> implement it as intended.   I have some work hours that I've put aside to
> work on this, once it is properly approved.
>
>
>
>
>
>
> On Mon, Feb 12, 2018 at 9:29 AM Ryan Newton <rrnewton at gmail.com> wrote:
>
>> Ah, I see, does it make sense for it to be implemented "frontend only"
>> first, with it desugaring into the current MutVar# primitives in the
>> backend?
>>
>>
>> On Mon, Feb 12, 2018 at 12:24 PM, Iavor Diatchki <
>> iavor.diatchki at gmail.com> wrote:
>>
>>> I support this.
>>>
>>> The status of the implementation, at least on my end. is stalled a bit,
>>> as I've been really busy with work.    Overall though, Ryan has a version
>>> that works for STM (although it is against an older GHC and mixed up with
>>> other experiments he is working on).   I also have a branch, where we've
>>> implemented the basic primitives, and started work on the front-end, but
>>> there is quite a bit to do still (e.g., we haven't really done code the
>>> code generation changes).  I'd say there are a bunch of interesting
>>> implementation questions that we need to answer, but in terms of the
>>> user-facing language changes, the proposal seems sound to me.
>>>
>>> On Mon, Feb 12, 2018 at 9:13 AM Ryan Newton <rrnewton at gmail.com> wrote:
>>>
>>>> Reboot!  This has long sat idle, but I propose to now formally start
>>>> the committee discussion period: mandatory 4 weeks, closing at end of day *March
>>>> 10th*, or earlier if consensus occurs.  Let's use this email thread
>>>> for that discussion.  In this mail I summarize public discussion and *argue
>>>> for "accept"*.
>>>>
>>>> In short, the proposal adds a way to have multiple mutable fields
>>>> within a data-constructor, without the indirection of using IORef.  Second
>>>> to "linear types"
>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/91>, this proposal
>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/8> generated the
>>>> most total comments during public discussion (107).  This level of
>>>> discussion was good -- given that accepted GHC proposals so far are mostly
>>>> syntactic (or API tweaks), this would be the first with major compiler
>>>> backend & runtime consequences.
>>>>
>>>> Ed Kmett and Ryan Yates have demonstrated the applicability of this
>>>> concept to data-structure implementation.  (Indeed, I think there's a good
>>>> reason that almost all languages mutation with mutation are implemented so
>>>> as to allow a single heap object to have multiple mutable fields within
>>>> it.) During the public discussion, questions were raised about interactions
>>>> with other features and implementation strategy -- in particularly changes
>>>> to core.  But I believe that all major concerns were eventually answered.
>>>>
>>>>   -Ryan
>>>>
>>>> P.S. Iavor, Trevor, and Ryan Yates were all working on implementation
>>>> of this feature at various points.  Not sure what the current status of
>>>> implementation efforts are.
>>>>
>>>>
>>>> On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <
>>>> mail at joachim-breitner.de> wrote:
>>>>
>>>>> Dear Committee,
>>>>>
>>>>> this is your secretary speaking:
>>>>>
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/8
>>>>> was brought before the committee, by our own Simon Marlow.
>>>>>
>>>>> I propose Ryan Newton as the Shepherd, because he asked for it :-)
>>>>>
>>>>> Ryan, please reach consensus as described in
>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>>
>>>>> I suggest you make a recommendation about the decision, maybe point out
>>>>> debatable points, and assume that anyone who stays quiet agrees with
>>>>> you.
>>>>>
>>>>>
>>>>> Greetings,
>>>>> 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/20180219/da21666f/attachment.html>

From ben at well-typed.com  Tue Feb 20 03:04:22 2018
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 19 Feb 2018 22:04:22 -0500
Subject: [ghc-steering-committee] Plugin recompilation avoidance interface
	(#108)
Message-ID: <87a7w4uzt8.fsf@smart-cactus.org>

Hello everyone,

I have been assigned as the shepard for proposal #108. This proposes a
change in GHC's plugin interface allowing plugins greater control over
recompilation, significantly improving compilation times for projects
relying on compiler plugins.


Summary:

The proposal suggests that the existing fields of the `ghc` package's
Plugin.Plugin type be wrapped with a type capturing a function computing
the plugin's recompilation desired behavior,

   data PluginRecompile = ForceRecompile
                        | NoForceRecompile
                        | MaybeRecompile Fingerprint

GHC can then use this recompilation information to decide whether
evaluating the plugin (and consequently invalidating any existing
compilation artifacts) is necessary.


Opinion & recommendation:

The proposal addresses a long-standing limitation (#7414) of the GHC
plugin interface which has become increasingly visible to users in
recent years. While the particular approach proposed breaks existing
plugin users, it is expressive enough to allow GHC to perform more
aggressive recompilation avoidance in the future [1]. Moreover, the
smart constructors proposed should make for a reasonably smooth
migration path.

Given that the plugins appears to have buy-in from a few notable plugin
authors, I recommend that we accept this proposal.

Cheers,

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

From mail at joachim-breitner.de  Tue Feb 20 03:36:33 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 19 Feb 2018 22:36:33 -0500
Subject: [ghc-steering-committee] Plugin recompilation avoidance
 interface (#108)
In-Reply-To: <87a7w4uzt8.fsf@smart-cactus.org>
References: <87a7w4uzt8.fsf@smart-cactus.org>
Message-ID: <1519097793.1066.22.camel@joachim-breitner.de>

Hi Ben,

thanks for kicking this off.

Am Montag, den 19.02.2018, 22:04 -0500 schrieb Ben Gamari:
> The proposal addresses a long-standing limitation (#7414) of the GHC
> plugin interface which has become increasingly visible to users in
> recent years. While the particular approach proposed breaks existing
> plugin users, it is expressive enough to allow GHC to perform more
> aggressive recompilation avoidance in the future [1]. Moreover, the
> smart constructors proposed should make for a reasonably smooth
> migration path.
> 
> Given that the plugins appears to have buy-in from a few notable plugin
> authors, I recommend that we accept this proposal.

How realistic is it to do the partial module recompilation thing that
warrants multiple PluginRecompile values per module? For this to be
useful the compiler would have to

 * calculate the typechecker plugin’s hash for module M
 * notice that it has changed, and start compiling M
 * but then, when we have core, magically notice that the output of the
   desugarer has not changed, and consider to abort calculation
 * but then notice that a core2core plugin was involved, and ask that 
   for the new hash
 * and then this hash must be unchanged
 * and then really the compilation has ended.

Is that realistic? Can someone fill this example with concrete life?

Maybe I am just not seeing what people have in mind – but I feel unless
this really is more than a very vague idea, we should consider the
simpler variant where each plugin gets to calculate a single hash per
module – and not possibly many in various stages.

Another way of putting it: The compiler pipeline is (simplified)

 1. decide what to compiler
 2. parse
 3. typecheck
 4. desguar
 5. optimize
 6. code gen

Plugins so far hook into step 3 and 5. Every one of these steps
probably eventually deserves a plugin hook. This proposal is about
adding one to step 1. With this view, I find the “add a single function
to Plugin”, as described in
https://github.com/ghc-proposals/ghc-proposals/pull/108#issuecomment-362671438
much more convincing.

Cheers,
Joachim


-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://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/20180219/7bd974c1/attachment.sig>

From mail at joachim-breitner.de  Tue Feb 20 03:58:43 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 19 Feb 2018 22:58:43 -0500
Subject: [ghc-steering-committee] Status
Message-ID: <1519099123.1066.35.camel@joachim-breitner.de>

Cheers everyone,

Since the last status update, we
 * were asked to review these proposals:
     - Int8#/Word8#
     - unlifted newtypes
     - plugin recompilation API
 * got a recommendation from shepherds about:
     - incomplete-uni-patterns (accept)
     - embrace Type in Type (recommendation is somewhat unclear)
     - Deprecate STM invariant (accept)
     - Unlifted newtypes  (accept)    
     - mutable constructor fields (accept)
     - plugin recompilation API (accept)
 * decided about the following proposals
     - Or patterns  (sent back for refinement)
     - Deprecate STM invariant (accept)
     - incomplete-uni-patterns (accept)

Good job, team!


On our table at the moment are 7 proposals:

Mutable constructor fields
https://github.com/ghc-proposals/ghc-proposals/pull/8
Shepherd: Ryan Newton
Status: Ryan recommends acceptance

Lazy unboxed tuples
https://github.com/ghc-proposals/ghc-proposals/pull/35
Shepherd: Ryan Newton
Status: Waiting for Ryan to make a recommendation.

Visible dependent quantification (TL;DR: forall k -> k -> *)
https://github.com/ghc-proposals/ghc-proposals/pull/81
Shepherd: Roman Leshchinskiy
Status: Discussion ebbed down. Do we have consensus?

Embrace (Type :: Type)
https://github.com/ghc-proposals/ghc-proposals/pull/83
Shepherd: Iavor Diatchki
Status: Iavor started a discussion

Small primitive types
https://github.com/ghc-proposals/ghc-proposals/pull/74
Shepherd: Simon Marlow
Status: Waiting for Simon to make a recommenataion

Unlifted Newtypes 
https://github.com/ghc-proposals/ghc-proposals/pull/98
Shepherd: Richard Eisenberg
Status: Richard recommends acceptance

Plugin recompilation avoidance
https://github.com/ghc-proposals/ghc-proposals/pull/108
Shepherd: Ben Gamari
Status: Ben suggests acceptance, but I am nitpicking


Besides these, there are some proposals actively under discussion. You
can always check them out at
https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no%3Alabel


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/20180219/104857fa/attachment-0001.sig>

From marlowsd at gmail.com  Tue Feb 20 10:16:04 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 20 Feb 2018 10:16:04 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <5917D40C-96ED-4BE6-8DEE-84C1101DE88B@justtesting.org>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
 <9B22C92E-D901-4CE5-A918-A1B0F912F4E3@justtesting.org>
 <CACYs5Aa7or_2Ss4F62ehJBfmP3EvuGmEkzzhrrXEAThMaD03aw@mail.gmail.com>
 <3E436D44-6310-4F58-A804-3606D14A54DD@justtesting.org>
 <ED282CCF-B82B-4CBF-AE00-F8310C23F51B@joachim-breitner.de>
 <5917D40C-96ED-4BE6-8DEE-84C1101DE88B@justtesting.org>
Message-ID: <CANsrgPLon9Cqi0LK4upDThG1sfZS0PetgHsOwaQxmF3ah=M2=g@mail.gmail.com>

Personally I'm not convinced by the motivation for deprecating '*': "GHC's
ability to parse * has a significant cost.". There are two kinds of cost
here:
1. implementation complexity
2. potential for users to be confused

for (1), Haskell historically has not made concessions in the name of
implementation simplicity, other concerns have tended to rate more highly:
familiarity, conciseness, consistency, ease of use and so forth. (for an
example of this tradeoff in action just look at the layout rule).

for (2), I think even though we strive for consistency in language design,
humans actually cope with exceptions very well - a few quirks here and
there actually help us remember things.  So the current situation isn't
terrible, in my view.

Furthermore in this case we're also fighting inertia: there's a lot of
code, documentation and other materials using the existing syntax.

Perhaps '*' wouldn't be what we would choose if we had a clean slate, but
at this point I think changing it is likely worse than not changing it.

Cheers
Simon

On 12 February 2018 at 03:54, Manuel M T Chakravarty <chak at justtesting.org>
wrote:

> Yes, existing code uses ’Type’, but it also uses ’*’ (GHC included) —
> i.e., this change is going to be a pain for some devs anyway. A pragma that
> couples the removal of ’*’ as a synonym for ’Type’ with the implicit
> importing of ’Type’ could encourage people to just apply both changes in
> one go.
>
> Manuel
>
> > Am 12.02.2018 um 02:04 schrieb Joachim Breitner <
> mail at joachim-breitner.de>:
> >
> > Hi,
> >
> >
> > Am 11. Februar 2018 01:43:03 EST schrieb Manuel M T Chakravarty <
> chak at justtesting.org>:
> >> So, I think, we need a convenient and concise notation that doesn’t
> >> require extra imports.
> >
> > we have precedence for that: (->) could just as well be a name exported
> from Data.Function and the Prelude, with all the usual rules around it
> (qualifications, exports). But it is not, and rather parses as it's own
> thing. So far, nobody seems to bother about this exception from the rule.
> >
> > But doing this to `Type` is annoying because existing code out there
> already used `Type`, in particular GHC.
> >
> > Maybe if we can find a uncommonly used, short, descriptive name then
> making that available without imports is viable? Do we have any good ideas?
> >
> >
> > Joachim
> > _______________________________________________
> > 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/20180220/5195169f/attachment.html>

From simonpj at microsoft.com  Tue Feb 20 11:19:47 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 20 Feb 2018 11:19:47 +0000
Subject: [ghc-steering-committee] Steering committee discussions
Message-ID: <AM5PR83MB0163AC1720856152C15DF4FFADCF0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Friend on the GHC proposals steering committee

I think it is helpful to have our shepherding process to drive debate to a conclusion.

But I think we are losing value by holding technical discussions on the email list, rather than on the proposal's own thread.  I'm not sure if the steering committee email list is visible to all; but even if it is, the info on a particular proposal is harder to find.

The thread below is a case in point.  Good stuff from Joachim, but not visible to the author or the world; result, lost insights.

Suggestion: could we hold all the committee debase on the proposal thread, thereby allowing the author to chime in if need be?   There might be some messages we want to be private -- very well, use the email list for those, but my sense is that 95% are absolutely publishable.

What changes when the shepherd kicks in?  Answer: the committee switches from observer (and contribute if you like) mode, to obligation-to-consider mode.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Joachim Breitner
|  Sent: 20 February 2018 03:37
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Plugin recompilation avoidance
|  interface (#108)
|  
|  Hi Ben,
|  
|  thanks for kicking this off.
|  
|  Am Montag, den 19.02.2018, 22:04 -0500 schrieb Ben Gamari:
|  > The proposal addresses a long-standing limitation (#7414) of the GHC
|  > plugin interface which has become increasingly visible to users in
|  > recent years. While the particular approach proposed breaks existing
|  > plugin users, it is expressive enough to allow GHC to perform more
|  > aggressive recompilation avoidance in the future [1]. Moreover, the
|  > smart constructors proposed should make for a reasonably smooth
|  > migration path.
|  >
|  > Given that the plugins appears to have buy-in from a few notable
|  > plugin authors, I recommend that we accept this proposal.
|  
|  How realistic is it to do the partial module recompilation thing that
|  warrants multiple PluginRecompile values per module? For this to be
|  useful the compiler would have to
|  
|   * calculate the typechecker plugin’s hash for module M
|   * notice that it has changed, and start compiling M
|   * but then, when we have core, magically notice that the output of
|  the
|     desugarer has not changed, and consider to abort calculation
|   * but then notice that a core2core plugin was involved, and ask that
|     for the new hash
|   * and then this hash must be unchanged
|   * and then really the compilation has ended.
|  
|  Is that realistic? Can someone fill this example with concrete life?
|  
|  Maybe I am just not seeing what people have in mind – but I feel
|  unless this really is more than a very vague idea, we should consider
|  the simpler variant where each plugin gets to calculate a single hash
|  per module – and not possibly many in various stages.
|  
|  Another way of putting it: The compiler pipeline is (simplified)
|  
|   1. decide what to compiler
|   2. parse
|   3. typecheck
|   4. desguar
|   5. optimize
|   6. code gen
|  
|  Plugins so far hook into step 3 and 5. Every one of these steps
|  probably eventually deserves a plugin hook. This proposal is about
|  adding one to step 1. With this view, I find the “add a single
|  function to Plugin”, as described in
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F108%23issuecomment-
|  362671438&data=04%7C01%7Csimonpj%40microsoft.com%7Cc1fc916f00464b7e868
|  c08d578133094%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63654694617
|  3205145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
|  JBTiI6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=C4lfSbadTT23lvfARKolUVSPfPfJSt5PvqJDTvJfYFQ%3D&reserved=0
|  much more convincing.
|  
|  Cheers,
|  Joachim
|  
|  
|  --
|  Joachim “nomeata” Breitner
|    mail at joachim-breitner.de
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc1fc916f00464b
|  7e868c08d578133094%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636546
|  946173205145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
|  zIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=w7Bv0He4imipDZAdnZhNc2EEwXCo7ejMNZ1o%2BGp7HWU%3D&reserved=0

From mail at joachim-breitner.de  Tue Feb 20 13:58:14 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 20 Feb 2018 08:58:14 -0500
Subject: [ghc-steering-committee] Steering committee discussions
In-Reply-To: <AM5PR83MB0163AC1720856152C15DF4FFADCF0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <AM5PR83MB0163AC1720856152C15DF4FFADCF0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <1519135094.1105.6.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 20.02.2018, 11:19 +0000 schrieb Simon Peyton Jones:
> The thread below is a case in point.  Good stuff from Joachim, but
> not visible to the author or the world; result, lost insights.

actually, in this case, I did bring this up in the discussion on
GitHub; the author was not convinced and brought the proposal forward
anyways, so now I am trying to sway the committee instead :-)


> Suggestion: could we hold all the committee debase on the proposal
> thread, thereby allowing the author to chime in if need be?   There
> might be some messages we want to be private -- very well, use the
> email list for those, but my sense is that 95% are absolutely
> publishable.

This list is public, do not post private stuff here! It is just a bit
“less visible” and less noisy.

Having technical discussions on GitHub is a reasonable thing to do. It
will be more noisy, i.e. many people chiming in, but that can of course
also be a good thing.

> What changes when the shepherd kicks in?  Answer: the committee
> switches from observer (and contribute if you like) mode, to
> obligation-to-consider mode.

Correct.

Shall we still require mails to the list when

 * A proposal was put forward
 * A shepherd makes a suggestions, and invites the committee to 
   comment (now on GitHub)
 * The shepherd or the secretary observes consensus, and declares
   a decision?


(This will actually make my life of assembling the “Status” mails
easier, but it will make it harder to determine consensus.)

All in all, I’m up for trying it out!

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/20180220/dd3b61ba/attachment.sig>

From ben at well-typed.com  Tue Feb 20 17:46:20 2018
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 20 Feb 2018 12:46:20 -0500
Subject: [ghc-steering-committee] Plugin recompilation avoidance
	interface (#108)
In-Reply-To: <1519097793.1066.22.camel@joachim-breitner.de>
References: <87a7w4uzt8.fsf@smart-cactus.org>
 <1519097793.1066.22.camel@joachim-breitner.de>
Message-ID: <87y3jntuzg.fsf@smart-cactus.org>

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

> Hi Ben,
>
> thanks for kicking this off.
>
> Am Montag, den 19.02.2018, 22:04 -0500 schrieb Ben Gamari:
>> The proposal addresses a long-standing limitation (#7414) of the GHC
>> plugin interface which has become increasingly visible to users in
>> recent years. While the particular approach proposed breaks existing
>> plugin users, it is expressive enough to allow GHC to perform more
>> aggressive recompilation avoidance in the future [1]. Moreover, the
>> smart constructors proposed should make for a reasonably smooth
>> migration path.
>> 
>> Given that the plugins appears to have buy-in from a few notable plugin
>> authors, I recommend that we accept this proposal.
>
> How realistic is it to do the partial module recompilation thing that
> warrants multiple PluginRecompile values per module? For this to be
> useful the compiler would have to
>
>  * calculate the typechecker plugin’s hash for module M
>  * notice that it has changed, and start compiling M
>  * but then, when we have core, magically notice that the output of the
>    desugarer has not changed, and consider to abort calculation
>  * but then notice that a core2core plugin was involved, and ask that 
>    for the new hash
>  * and then this hash must be unchanged
>  * and then really the compilation has ended.
>
> Is that realistic? Can someone fill this example with concrete life?
>
> Maybe I am just not seeing what people have in mind – but I feel unless
> this really is more than a very vague idea, we should consider the
> simpler variant where each plugin gets to calculate a single hash per
> module – and not possibly many in various stages.
>
> Another way of putting it: The compiler pipeline is (simplified)
>
>  1. decide what to compiler
>  2. parse
>  3. typecheck
>  4. desguar
>  5. optimize
>  6. code gen
>
> Plugins so far hook into step 3 and 5. Every one of these steps
> probably eventually deserves a plugin hook. This proposal is about
> adding one to step 1. With this view, I find the “add a single function
> to Plugin”, as described in
> https://github.com/ghc-proposals/ghc-proposals/pull/108#issuecomment-362671438
> much more convincing.
>
I understand the concern; your description indeed matches how GHC
currently handles recompilation, which makes it quite difficult to bail
out after deciding to recompile.

Simon PJ has mentioned in the past that one of the goals that would be
worth pursuing is more aggressive recompilation avoidance (e.g. perhaps
even some day on a sub-module granularity), especially given the recent
complaints surrounding compilation times. I don't believe there is any
motion on this and it would certainly be a significant undertaking.

Given that we have very little idea of what such a design
would look like, I agree that we shouldn't try to design the plugin
interface too carefully around this (likely quite far-off) goal.
However, I personally feel like the proposed design is a reasonable
compromise. Lumping together all of the recompilation checks into a
single hash would expose a relatively ugly facet of GHC's implementation
to plugin authors and force authors to tie together logic from
conceptually-distinct compilation phases. Furthermore, we would tie
ourselves to GHC's current design.

The one thing that gives me pause is the proposal's treatment of
core-to-core plugins, which return a list of CoreTodos. Tying
recompilation to this function is admittedly a bit odd.

Cheers,

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

From chak at justtesting.org  Wed Feb 21 02:23:22 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 21 Feb 2018 13:23:22 +1100
Subject: [ghc-steering-committee] Steering committee discussions
In-Reply-To: <1519135094.1105.6.camel@joachim-breitner.de>
References: <AM5PR83MB0163AC1720856152C15DF4FFADCF0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1519135094.1105.6.camel@joachim-breitner.de>
Message-ID: <393A464A-3FF2-42F3-9233-D8743B3A01DD@justtesting.org>

I am sorry, but I am against moving the committee discussion to GitHub. This is for the following reasons:

* I don’t think, we will gain anything by moving to GitHub. Nothing is lost on the email list. The proposal author and anybody else can follow along as this is a public list.

* Proposals have a life cycle: writing, public commenting, refinement, and finally committee discussion (and then it may go around again if the proposal needs to be revised). Having the public, collaborative writing, public commenting, refinement steps on GitHub and the somewhat closed committee decision process on different media makes the mode change very explicit, which is good.

* I get a lot of email from GitHub. Most of it I deleted right away (including most ghc-proposal GitHub messages). Having the committee decision process by email makes it clear when I need to pay attention (without having to consult GitHub ticket labels).

* The Shepard has an incentive to briefly summarise the outcome of the committee discussion on GitHub after the decision is made (if it is all on GitHub, everybody needs to wade though everything).

* On GitHub it is much harder to see which comments are new, especially if the thread is long, because there was already a long community discussion phase.

* The committee discussion may be interleaved with additional public comments, because anybody else can comment, too, at the time, making it even harder to distinguish the committee discussion.

Cheers,
Manuel

> 21.02.2018 00:58 Joachim Breitner <mail at joachim-breitner.de>:
> 
> Hi,
> 
> Am Dienstag, den 20.02.2018, 11:19 +0000 schrieb Simon Peyton Jones:
>> The thread below is a case in point.  Good stuff from Joachim, but
>> not visible to the author or the world; result, lost insights.
> 
> actually, in this case, I did bring this up in the discussion on
> GitHub; the author was not convinced and brought the proposal forward
> anyways, so now I am trying to sway the committee instead :-)
> 
> 
>> Suggestion: could we hold all the committee debase on the proposal
>> thread, thereby allowing the author to chime in if need be?   There
>> might be some messages we want to be private -- very well, use the
>> email list for those, but my sense is that 95% are absolutely
>> publishable.
> 
> This list is public, do not post private stuff here! It is just a bit
> “less visible” and less noisy.
> 
> Having technical discussions on GitHub is a reasonable thing to do. It
> will be more noisy, i.e. many people chiming in, but that can of course
> also be a good thing.
> 
>> What changes when the shepherd kicks in?  Answer: the committee
>> switches from observer (and contribute if you like) mode, to
>> obligation-to-consider mode.
> 
> Correct.
> 
> Shall we still require mails to the list when
> 
> * A proposal was put forward
> * A shepherd makes a suggestions, and invites the committee to 
>   comment (now on GitHub)
> * The shepherd or the secretary observes consensus, and declares
>   a decision?
> 
> 
> (This will actually make my life of assembling the “Status” mails
> easier, but it will make it harder to determine consensus.)
> 
> All in all, I’m up for trying it out!
> 
> 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 cma at bitemyapp.com  Wed Feb 21 02:46:30 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 20 Feb 2018 20:46:30 -0600
Subject: [ghc-steering-committee] Steering committee discussions
In-Reply-To: <393A464A-3FF2-42F3-9233-D8743B3A01DD@justtesting.org>
References: <AM5PR83MB0163AC1720856152C15DF4FFADCF0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1519135094.1105.6.camel@joachim-breitner.de>
 <393A464A-3FF2-42F3-9233-D8743B3A01DD@justtesting.org>
Message-ID: <CADnndOo4rRwRaZMCekSd3+B6kAAwi0sM5JvTWiOAJb70As9v+A@mail.gmail.com>

Much as I like GitHub for some kinds of work, I don't think I'd move
this sort of thing to GitHub. Attached screenshot is of the gmail
folder my emails from GitHub get redirected to. I get many and very
few of them are something I should look at. I clear my notifications
using the GitHub notifications menu rather than via email, yet email
is the primary way I'd consume to respond to anything on this mailing
list.

Naturally, YMMV.

--- Chris


On Tue, Feb 20, 2018 at 8:23 PM, Manuel M T Chakravarty
<chak at justtesting.org> wrote:
> I am sorry, but I am against moving the committee discussion to GitHub. This is for the following reasons:
>
> * I don’t think, we will gain anything by moving to GitHub. Nothing is lost on the email list. The proposal author and anybody else can follow along as this is a public list.
>
> * Proposals have a life cycle: writing, public commenting, refinement, and finally committee discussion (and then it may go around again if the proposal needs to be revised). Having the public, collaborative writing, public commenting, refinement steps on GitHub and the somewhat closed committee decision process on different media makes the mode change very explicit, which is good.
>
> * I get a lot of email from GitHub. Most of it I deleted right away (including most ghc-proposal GitHub messages). Having the committee decision process by email makes it clear when I need to pay attention (without having to consult GitHub ticket labels).
>
> * The Shepard has an incentive to briefly summarise the outcome of the committee discussion on GitHub after the decision is made (if it is all on GitHub, everybody needs to wade though everything).
>
> * On GitHub it is much harder to see which comments are new, especially if the thread is long, because there was already a long community discussion phase.
>
> * The committee discussion may be interleaved with additional public comments, because anybody else can comment, too, at the time, making it even harder to distinguish the committee discussion.
>
> Cheers,
> Manuel
>
>> 21.02.2018 00:58 Joachim Breitner <mail at joachim-breitner.de>:
>>
>> Hi,
>>
>> Am Dienstag, den 20.02.2018, 11:19 +0000 schrieb Simon Peyton Jones:
>>> The thread below is a case in point.  Good stuff from Joachim, but
>>> not visible to the author or the world; result, lost insights.
>>
>> actually, in this case, I did bring this up in the discussion on
>> GitHub; the author was not convinced and brought the proposal forward
>> anyways, so now I am trying to sway the committee instead :-)
>>
>>
>>> Suggestion: could we hold all the committee debase on the proposal
>>> thread, thereby allowing the author to chime in if need be?   There
>>> might be some messages we want to be private -- very well, use the
>>> email list for those, but my sense is that 95% are absolutely
>>> publishable.
>>
>> This list is public, do not post private stuff here! It is just a bit
>> “less visible” and less noisy.
>>
>> Having technical discussions on GitHub is a reasonable thing to do. It
>> will be more noisy, i.e. many people chiming in, but that can of course
>> also be a good thing.
>>
>>> What changes when the shepherd kicks in?  Answer: the committee
>>> switches from observer (and contribute if you like) mode, to
>>> obligation-to-consider mode.
>>
>> Correct.
>>
>> Shall we still require mails to the list when
>>
>> * A proposal was put forward
>> * A shepherd makes a suggestions, and invites the committee to
>>   comment (now on GitHub)
>> * The shepherd or the secretary observes consensus, and declares
>>   a decision?
>>
>>
>> (This will actually make my life of assembling the “Status” mails
>> easier, but it will make it harder to determine consensus.)
>>
>> All in all, I’m up for trying it out!
>>
>> 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



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2018-02-20 20-44-49.png
Type: image/png
Size: 2775 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180220/ed498f13/attachment.png>

From rae at cs.brynmawr.edu  Wed Feb 21 02:49:01 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 20 Feb 2018 21:49:01 -0500
Subject: [ghc-steering-committee] Steering committee discussions
In-Reply-To: <393A464A-3FF2-42F3-9233-D8743B3A01DD@justtesting.org>
References: <AM5PR83MB0163AC1720856152C15DF4FFADCF0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1519135094.1105.6.camel@joachim-breitner.de>
 <393A464A-3FF2-42F3-9233-D8743B3A01DD@justtesting.org>
Message-ID: <D5C66C95-52D1-48A0-99CD-A6B8C99BF2DB@cs.brynmawr.edu>

I agree with all of Manuel's points below. I think we can have a more focused discussion on the mailing list -- and this list is archived (and public) for future reference.

Richard

> On Feb 20, 2018, at 9:23 PM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> 
> I am sorry, but I am against moving the committee discussion to GitHub. This is for the following reasons:
> 
> * I don’t think, we will gain anything by moving to GitHub. Nothing is lost on the email list. The proposal author and anybody else can follow along as this is a public list.
> 
> * Proposals have a life cycle: writing, public commenting, refinement, and finally committee discussion (and then it may go around again if the proposal needs to be revised). Having the public, collaborative writing, public commenting, refinement steps on GitHub and the somewhat closed committee decision process on different media makes the mode change very explicit, which is good.
> 
> * I get a lot of email from GitHub. Most of it I deleted right away (including most ghc-proposal GitHub messages). Having the committee decision process by email makes it clear when I need to pay attention (without having to consult GitHub ticket labels).
> 
> * The Shepard has an incentive to briefly summarise the outcome of the committee discussion on GitHub after the decision is made (if it is all on GitHub, everybody needs to wade though everything).
> 
> * On GitHub it is much harder to see which comments are new, especially if the thread is long, because there was already a long community discussion phase.
> 
> * The committee discussion may be interleaved with additional public comments, because anybody else can comment, too, at the time, making it even harder to distinguish the committee discussion.
> 
> Cheers,
> Manuel
> 
>> 21.02.2018 00:58 Joachim Breitner <mail at joachim-breitner.de>:
>> 
>> Hi,
>> 
>> Am Dienstag, den 20.02.2018, 11:19 +0000 schrieb Simon Peyton Jones:
>>> The thread below is a case in point.  Good stuff from Joachim, but
>>> not visible to the author or the world; result, lost insights.
>> 
>> actually, in this case, I did bring this up in the discussion on
>> GitHub; the author was not convinced and brought the proposal forward
>> anyways, so now I am trying to sway the committee instead :-)
>> 
>> 
>>> Suggestion: could we hold all the committee debase on the proposal
>>> thread, thereby allowing the author to chime in if need be?   There
>>> might be some messages we want to be private -- very well, use the
>>> email list for those, but my sense is that 95% are absolutely
>>> publishable.
>> 
>> This list is public, do not post private stuff here! It is just a bit
>> “less visible” and less noisy.
>> 
>> Having technical discussions on GitHub is a reasonable thing to do. It
>> will be more noisy, i.e. many people chiming in, but that can of course
>> also be a good thing.
>> 
>>> What changes when the shepherd kicks in?  Answer: the committee
>>> switches from observer (and contribute if you like) mode, to
>>> obligation-to-consider mode.
>> 
>> Correct.
>> 
>> Shall we still require mails to the list when
>> 
>> * A proposal was put forward
>> * A shepherd makes a suggestions, and invites the committee to 
>>  comment (now on GitHub)
>> * The shepherd or the secretary observes consensus, and declares
>>  a decision?
>> 
>> 
>> (This will actually make my life of assembling the “Status” mails
>> easier, but it will make it harder to determine consensus.)
>> 
>> All in all, I’m up for trying it out!
>> 
>> 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


From simonpj at microsoft.com  Wed Feb 21 09:14:01 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 21 Feb 2018 09:14:01 +0000
Subject: [ghc-steering-committee] Steering committee discussions
In-Reply-To: <393A464A-3FF2-42F3-9233-D8743B3A01DD@justtesting.org>
References: <AM5PR83MB0163AC1720856152C15DF4FFADCF0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1519135094.1105.6.camel@joachim-breitner.de>
 <393A464A-3FF2-42F3-9233-D8743B3A01DD@justtesting.org>
Message-ID: <AM5PR83MB0163B322D81F4F60E4E4B06CADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

I don't feel strongly.

But then I think we should make it clear on the home page https://github.com/ghc-proposals/ghc-proposals  that

* What is the committee email address

* That it is publicly readable (but not writable?)

* That authors are strongly encouraged to follow the discussion about their
  proposal (during step 5), and use to improve their proposal, even
  if it is accepted.

Simon



|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Manuel M T Chakravarty
|  Sent: 21 February 2018 02:23
|  To: Joachim Breitner <mail at joachim-breitner.de>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Steering committee discussions
|  
|  I am sorry, but I am against moving the committee discussion to
|  GitHub. This is for the following reasons:
|  
|  * I don’t think, we will gain anything by moving to GitHub. Nothing is
|  lost on the email list. The proposal author and anybody else can
|  follow along as this is a public list.
|  
|  * Proposals have a life cycle: writing, public commenting, refinement,
|  and finally committee discussion (and then it may go around again if
|  the proposal needs to be revised). Having the public, collaborative
|  writing, public commenting, refinement steps on GitHub and the
|  somewhat closed committee decision process on different media makes
|  the mode change very explicit, which is good.
|  
|  * I get a lot of email from GitHub. Most of it I deleted right away
|  (including most ghc-proposal GitHub messages). Having the committee
|  decision process by email makes it clear when I need to pay attention
|  (without having to consult GitHub ticket labels).
|  
|  * The Shepard has an incentive to briefly summarise the outcome of the
|  committee discussion on GitHub after the decision is made (if it is
|  all on GitHub, everybody needs to wade though everything).
|  
|  * On GitHub it is much harder to see which comments are new,
|  especially if the thread is long, because there was already a long
|  community discussion phase.
|  
|  * The committee discussion may be interleaved with additional public
|  comments, because anybody else can comment, too, at the time, making
|  it even harder to distinguish the committee discussion.
|  
|  Cheers,
|  Manuel
|  
|  > 21.02.2018 00:58 Joachim Breitner <mail at joachim-breitner.de>:
|  >
|  > Hi,
|  >
|  > Am Dienstag, den 20.02.2018, 11:19 +0000 schrieb Simon Peyton Jones:
|  >> The thread below is a case in point.  Good stuff from Joachim, but
|  >> not visible to the author or the world; result, lost insights.
|  >
|  > actually, in this case, I did bring this up in the discussion on
|  > GitHub; the author was not convinced and brought the proposal
|  forward
|  > anyways, so now I am trying to sway the committee instead :-)
|  >
|  >
|  >> Suggestion: could we hold all the committee debase on the proposal
|  >> thread, thereby allowing the author to chime in if need be?   There
|  >> might be some messages we want to be private -- very well, use the
|  >> email list for those, but my sense is that 95% are absolutely
|  >> publishable.
|  >
|  > This list is public, do not post private stuff here! It is just a
|  bit
|  > “less visible” and less noisy.
|  >
|  > Having technical discussions on GitHub is a reasonable thing to do.
|  It
|  > will be more noisy, i.e. many people chiming in, but that can of
|  > course also be a good thing.
|  >
|  >> What changes when the shepherd kicks in?  Answer: the committee
|  >> switches from observer (and contribute if you like) mode, to
|  >> obligation-to-consider mode.
|  >
|  > Correct.
|  >
|  > Shall we still require mails to the list when
|  >
|  > * A proposal was put forward
|  > * A shepherd makes a suggestions, and invites the committee to
|  >   comment (now on GitHub)
|  > * The shepherd or the secretary observes consensus, and declares
|  >   a decision?
|  >
|  >
|  > (This will actually make my life of assembling the “Status” mails
|  > easier, but it will make it harder to determine consensus.)
|  >
|  > All in all, I’m up for trying it out!
|  >
|  > 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-
|  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 mail at joachim-breitner.de  Wed Feb 21 13:54:13 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 21 Feb 2018 08:54:13 -0500
Subject: [ghc-steering-committee] Steering committee discussions
In-Reply-To: <AM5PR83MB0163B322D81F4F60E4E4B06CADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <AM5PR83MB0163AC1720856152C15DF4FFADCF0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1519135094.1105.6.camel@joachim-breitner.de>
 <393A464A-3FF2-42F3-9233-D8743B3A01DD@justtesting.org>
 <AM5PR83MB0163B322D81F4F60E4E4B06CADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <1519221253.1437.3.camel@joachim-breitner.de>

Hi,

I see a strong majority for keeping it this way.

I updated the section
https://github.com/ghc-proposals/ghc-proposals#committee-process
with Simon’s input and also generally made it reflect our de-facto
process.

Cheers,
Joachim


Am Mittwoch, den 21.02.2018, 09:14 +0000 schrieb Simon Peyton Jones:
> I don't feel strongly.
> 
> But then I think we should make it clear on the home page https://github.com/ghc-proposals/ghc-proposals  that
> 
> * What is the committee email address
> 
> * That it is publicly readable (but not writable?)
> 
> * That authors are strongly encouraged to follow the discussion about their
>   proposal (during step 5), and use to improve their proposal, even
>   if it is accepted.
> 
> Simon
> 
> 
> 
> >  -----Original Message-----
> >  From: ghc-steering-committee [mailto:ghc-steering-committee-
> >  bounces at haskell.org] On Behalf Of Manuel M T Chakravarty
> >  Sent: 21 February 2018 02:23
> >  To: Joachim Breitner <mail at joachim-breitner.de>
> >  Cc: ghc-steering-committee at haskell.org
> >  Subject: Re: [ghc-steering-committee] Steering committee discussions
> >  
> >  I am sorry, but I am against moving the committee discussion to
> >  GitHub. This is for the following reasons:
> >  
> >  * I don’t think, we will gain anything by moving to GitHub. Nothing is
> >  lost on the email list. The proposal author and anybody else can
> >  follow along as this is a public list.
> >  
> >  * Proposals have a life cycle: writing, public commenting, refinement,
> >  and finally committee discussion (and then it may go around again if
> >  the proposal needs to be revised). Having the public, collaborative
> >  writing, public commenting, refinement steps on GitHub and the
> >  somewhat closed committee decision process on different media makes
> >  the mode change very explicit, which is good.
> >  
> >  * I get a lot of email from GitHub. Most of it I deleted right away
> >  (including most ghc-proposal GitHub messages). Having the committee
> >  decision process by email makes it clear when I need to pay attention
> >  (without having to consult GitHub ticket labels).
> >  
> >  * The Shepard has an incentive to briefly summarise the outcome of the
> >  committee discussion on GitHub after the decision is made (if it is
> >  all on GitHub, everybody needs to wade though everything).
> >  
> >  * On GitHub it is much harder to see which comments are new,
> >  especially if the thread is long, because there was already a long
> >  community discussion phase.
> >  
> >  * The committee discussion may be interleaved with additional public
> >  comments, because anybody else can comment, too, at the time, making
> >  it even harder to distinguish the committee discussion.
> >  
> >  Cheers,
> >  Manuel
> >  
> >  > 21.02.2018 00:58 Joachim Breitner <mail at joachim-breitner.de>:
> >  >
> >  > Hi,
> >  >
> >  > Am Dienstag, den 20.02.2018, 11:19 +0000 schrieb Simon Peyton Jones:
> >  >> The thread below is a case in point.  Good stuff from Joachim, but
> >  >> not visible to the author or the world; result, lost insights.
> >  >
> >  > actually, in this case, I did bring this up in the discussion on
> >  > GitHub; the author was not convinced and brought the proposal
> >  forward
> >  > anyways, so now I am trying to sway the committee instead :-)
> >  >
> >  >
> >  >> Suggestion: could we hold all the committee debase on the proposal
> >  >> thread, thereby allowing the author to chime in if need be?   There
> >  >> might be some messages we want to be private -- very well, use the
> >  >> email list for those, but my sense is that 95% are absolutely
> >  >> publishable.
> >  >
> >  > This list is public, do not post private stuff here! It is just a
> >  bit
> >  > “less visible” and less noisy.
> >  >
> >  > Having technical discussions on GitHub is a reasonable thing to do.
> >  It
> >  > will be more noisy, i.e. many people chiming in, but that can of
> >  > course also be a good thing.
> >  >
> >  >> What changes when the shepherd kicks in?  Answer: the committee
> >  >> switches from observer (and contribute if you like) mode, to
> >  >> obligation-to-consider mode.
> >  >
> >  > Correct.
> >  >
> >  > Shall we still require mails to the list when
> >  >
> >  > * A proposal was put forward
> >  > * A shepherd makes a suggestions, and invites the committee to
> >  >   comment (now on GitHub)
> >  > * The shepherd or the secretary observes consensus, and declares
> >  >   a decision?
> >  >
> >  >
> >  > (This will actually make my life of assembling the “Status” mails
> >  > easier, but it will make it harder to determine consensus.)
> >  >
> >  > All in all, I’m up for trying it out!
> >  >
> >  > 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-
> >  committ
> >  > ee
> >  
> >  _______________________________________________
> >  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/20180221/937019ad/attachment.sig>

From simonpj at microsoft.com  Wed Feb 21 14:23:07 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 21 Feb 2018 14:23:07 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
Message-ID: <AM5PR83MB016339ECB274F05F00BEEAF9ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Is it true that we are supporting this proposal – except perhaps for the fate of “*”?    If so, let’s agree that much at least!

Simon

From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
Sent: 09 February 2018 17:47
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type

The issue I see is that it is quite common to get a kind error without doing any fancy type level programming---in particular without writing kind signatures or anything like that.  So you'd have no reason to import `Data.Kind(Type)`.    The result would be that GHC would give quite a verbose error message, using the fully qualified name of `Type`.  Unless we did something special.

-Iavor


On Fri, Feb 9, 2018 at 2:41 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I’m not sure I see the problem here.  If ‘Int’ is not in scope then
f :: Int -> Int
won’t work.  What’s different about ‘Type’

Simon

From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>] On Behalf Of Richard Eisenberg
Sent: 09 February 2018 04:26
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type

Thanks, Iavor, for bringing this up.

To clarify the proposal: -XStarIsType is orthogonal to deprecation. The extension is necessary in order to continue to parse existing programs, but if we choose to deprecate *, then we would deprecate even with -XStarIsType is enabled (precisely to avoid the half-deprecation scenario Iavor is worried about).

I envisioned always printing Type unqualified in error messages, even if it's not imported. If a user writes Type and it's out of scope, we could always have a special-case check suggesting they import Data.Kind. I won't argue this is a principled design, though, and is likely a poor choice if some other Type is in scope.

The truth is that I don't have a great way forward here (and haven't for years) and am very hopeful someone on this list can come up with one! :) The proposal has my best idea, but I'm still not thrilled with it.

Thanks,
Richard

On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,

I didn't see any discussion about the third part of this proposal, namely the addition of a new extension called `StarIsKind`.  The idea is that when this is on, `*` will still be treated as a special alpha-numeric name, and it will *always* refer to the kind of inhabited types (i.e., same as know).  The difference is that it cannot be used as another type-level operator (e.g., for multiplication).

Presumably, when this extension is on, there would be no deprecation warning emitted for `*`? We should clarify this in the proposal.

I am not certain if this is a good idea.  It makes the use of `*` sort of "half" deprecated, and leaves us with multiple "standard" ways to refer to the same thing (e.g., in type errors).  Also, if we want people to update their code to use `Type` instead of `*`, then we are just delaying the pain point to whenever `StarIsKind` ends up being not on by default.

OTOH, if we don't have a standard short-hand way to refer to the kind of inhabited types, I imagine GHC will report some very ugly errors.  For example:

    • Expecting one more argument to ‘Maybe’
      Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type -> Data.Kind.Type’

And this is for a fairly simple kind error, they get much longer if, say, monad transformers are involved.

What do others think?

-Iavor






On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:

> On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
>
> In particular in light of our use of “type” as a explicit namespace
> token – so far in export and import lists and fixity declarations – I
> worry that we will prevent ourselves from using more such explicit
> namespace things in the future.

This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does not want to have separate type-level and term-level namespaces. Of course, Haskell has this.

The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.

If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.

All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type` isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.

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/20180221/d08fcfd0/attachment-0001.html>

From simonpj at microsoft.com  Wed Feb 21 16:18:38 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 21 Feb 2018 16:18:38 +0000
Subject: [ghc-steering-committee] Plugin recompilation avoidance
	interface	(#108)
In-Reply-To: <87a7w4uzt8.fsf@smart-cactus.org>
References: <87a7w4uzt8.fsf@smart-cactus.org>
Message-ID: <AM5PR83MB0163E688AF6BC9DD51335A66ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

I don't have well-informed opinion, but I'd like to be sure about 

| Given that the plugins appears to have buy-in from a few notable plugin
| authors, I recommend that we accept this proposal.

Let's enumerate them and check they are supportive.

I'd check with Luite too.  And Edward may have a view.

I'm not against in principle.

Simon

| -----Original Message-----
| From: ghc-steering-committee [mailto:ghc-steering-committee-
| bounces at haskell.org] On Behalf Of Ben Gamari
| Sent: 20 February 2018 03:04
| To: ghc-steering-committee at haskell.org
| Subject: [ghc-steering-committee] Plugin recompilation avoidance
| interface (#108)
| 
| Hello everyone,
| 
| I have been assigned as the shepard for proposal #108. This proposes a
| change in GHC's plugin interface allowing plugins greater control over
| recompilation, significantly improving compilation times for projects
| relying on compiler plugins.
| 
| 
| Summary:
| 
| The proposal suggests that the existing fields of the `ghc` package's
| Plugin.Plugin type be wrapped with a type capturing a function computing
| the plugin's recompilation desired behavior,
| 
|    data PluginRecompile = ForceRecompile
|                         | NoForceRecompile
|                         | MaybeRecompile Fingerprint
| 
| GHC can then use this recompilation information to decide whether
| evaluating the plugin (and consequently invalidating any existing
| compilation artifacts) is necessary.
| 
| 
| Opinion & recommendation:
| 
| The proposal addresses a long-standing limitation (#7414) of the GHC
| plugin interface which has become increasingly visible to users in recent
| years. While the particular approach proposed breaks existing plugin
| users, it is expressive enough to allow GHC to perform more aggressive
| recompilation avoidance in the future [1]. Moreover, the smart
| constructors proposed should make for a reasonably smooth migration path.
| 
| Given that the plugins appears to have buy-in from a few notable plugin
| authors, I recommend that we accept this proposal.

| Given that the plugins appears to have buy-in from a few notable plugin
| authors, I recommend that we accept this proposal.


| 
| Cheers,
| 
| - Ben

From iavor.diatchki at gmail.com  Wed Feb 21 17:18:07 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 21 Feb 2018 17:18:07 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <AM5PR83MB016339ECB274F05F00BEEAF9ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
 <AM5PR83MB016339ECB274F05F00BEEAF9ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nupjwn8szQuoVzPCWOUGZEBvW-v2aU3=LapbctxW2dUFBA@mail.gmail.com>

My impression is that the committee overall supports the part of the
proposal where we merge `TypeInType` with `PolyKinds`.

Based on the discussion so far, opinions differ on the notation for the
kind of inhabited types (currently `*`).

-Iavor




On Wed, Feb 21, 2018 at 6:23 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Is it true that we are supporting this proposal – except perhaps for the
> fate of “*”?    If so, let’s agree that much at least!
>
>
>
> Simon
>
>
>
> *From:* Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
> *Sent:* 09 February 2018 17:47
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Richard Eisenberg <rae at cs.brynmawr.edu>;
> ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
>
>
> *Subject:* Re: [ghc-steering-committee] Proposal: Embrace Type in Type
>
>
>
> The issue I see is that it is quite common to get a kind error without
> doing any fancy type level programming---in particular without writing kind
> signatures or anything like that.  So you'd have no reason to import
> `Data.Kind(Type)`.    The result would be that GHC would give quite a
> verbose error message, using the fully qualified name of `Type`.  Unless we
> did something special.
>
>
>
> -Iavor
>
>
>
>
>
> On Fri, Feb 9, 2018 at 2:41 AM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> I’m not sure I see the problem here.  If ‘Int’ is not in scope then
>
> f :: Int -> Int
>
> won’t work.  What’s different about ‘Type’
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee [mailto:
> ghc-steering-committee-bounces at haskell.org] *On Behalf Of *Richard
> Eisenberg
> *Sent:* 09 February 2018 04:26
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
> *Subject:* Re: [ghc-steering-committee] Proposal: Embrace Type in Type
>
>
>
> Thanks, Iavor, for bringing this up.
>
>
>
> To clarify the proposal: -XStarIsType is orthogonal to deprecation. The
> extension is necessary in order to continue to parse existing programs, but
> if we choose to deprecate *, then we would deprecate even with -XStarIsType
> is enabled (precisely to avoid the half-deprecation scenario Iavor is
> worried about).
>
>
>
> I envisioned always printing Type unqualified in error messages, even if
> it's not imported. If a user writes Type and it's out of scope, we could
> always have a special-case check suggesting they import Data.Kind. I won't
> argue this is a principled design, though, and is likely a poor choice if
> some other Type is in scope.
>
>
>
> The truth is that I don't have a great way forward here (and haven't for
> years) and am very hopeful someone on this list can come up with one! :)
> The proposal has my best idea, but I'm still not thrilled with it.
>
>
>
> Thanks,
>
> Richard
>
>
>
> On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>
>
> Hello,
>
>
>
> I didn't see any discussion about the third part of this proposal, namely
> the addition of a new extension called `StarIsKind`.  The idea is that when
> this is on, `*` will still be treated as a special alpha-numeric name, and
> it will *always* refer to the kind of inhabited types (i.e., same as
> know).  The difference is that it cannot be used as another type-level
> operator (e.g., for multiplication).
>
>
>
> Presumably, when this extension is on, there would be no deprecation
> warning emitted for `*`? We should clarify this in the proposal.
>
>
>
> I am not certain if this is a good idea.  It makes the use of `*` sort of
> "half" deprecated, and leaves us with multiple "standard" ways to refer to
> the same thing (e.g., in type errors).  Also, if we want people to update
> their code to use `Type` instead of `*`, then we are just delaying the pain
> point to whenever `StarIsKind` ends up being not on by default.
>
>
>
> OTOH, if we don't have a standard short-hand way to refer to the kind of
> inhabited types, I imagine GHC will report some very ugly errors.  For
> example:
>
>
>
>     • Expecting one more argument to ‘Maybe’
>
>       Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type ->
> Data.Kind.Type’
>
>
>
> And this is for a fairly simple kind error, they get much longer if, say,
> monad transformers are involved.
>
>
>
> What do others think?
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
>
> > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> >
> > In particular in light of our use of “type” as a explicit namespace
> > token – so far in export and import lists and fixity declarations – I
> > worry that we will prevent ourselves from using more such explicit
> > namespace things in the future.
>
> This is a really good point. In private musings, I've often wondered about
> using the keyword `type` in expressions to denote a namespace change. More
> concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is,
> a dependently typed language does not want to have separate type-level and
> term-level namespaces. Of course, Haskell has this.
>
> The best solution I have so far to the DNP is to introduce a *new*
> namespace, distinct from the two namespaces we have so far. Let's call it
> the "default" namespace. When -XDependentTypes is on, the default namespace
> is in effect. Name lookup looks first in the default namespace. If that
> fails the namespace consulted next depends on context: the "data" namespace
> in terms and the "type" namespace in type signatures. (This last bit needs
> to be specified more concretely, but you get the idea.) Or, perhaps, a
> failed lookup in the default namespace will look up in both the type and
> data namespaces, erroring if a name appears in both.
>
> If a user wants to specify a namespace directly, they have a very easy way
> to do so: `type Foo` will look in the type namespace, `data Foo` will look
> in the data namespace, and `default Foo` will look in the default
> namespace. :) Because these keywords make sense currently only at the
> beginning of a line, this Just Works. I also imagined these constructs
> could scope over a subexpression: `type (T S)`.
>
> All of this deserves a proper proposal and it's too early for that
> proposal. Nevertheless, I'm grateful that Joachim said something here,
> given that adding `type` as a spelling of `Type` would invalidate this
> approach. I also am swayed by the fact that `Type` isn't fully primitive,
> and making a keyword mean something that's not primitive is a bit awkward.
> I thus retract this proposed alternative and will update the proposal
> accordingly.
>
> 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/20180221/18b0a107/attachment-0001.html>

From iavor.diatchki at gmail.com  Wed Feb 21 17:28:00 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 21 Feb 2018 17:28:00 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <AM5PR83MB0163B7281F6CDCEF0A8DF659ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
 <AM5PR83MB0163B7281F6CDCEF0A8DF659ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nupKg49otamTV2nUrnoPg4MiF4uzy4=jefiywn+5O6A+wg@mail.gmail.com>

>From the GitHub discussions and the e-mails, I've seen a couple of other
options being proposed/discussed:

   * Use a unicode star operator.
      - Pros: short, looks like the current star, much less likely to clash
with stuff.
      - Cons:  typing a unicode symbol in some editors could be a pain.

   * Continue using `*` (or another infix operator), but require that it be
written in prefix notation, i.e. write `(*)` instead of `*`.
      - Pros: less of a wart, follows normal language rules
      - Cons: it is odd to use an infix operator that is not binary (i.e.,
can't be written infix);  still uses up the `*` name

    * Continue using `*` but---at the type level---have it always refer to
the kind, when used unqualified. This is what is called `StartIsKind` in
the proposal.


On Wed, Feb 21, 2018 at 7:59 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> The issue about ‘*’ seems to be this
>
>
>
>    - We need a way to write down the kind of types.   E.g.    Int :: ???
>
> What is the “???”
>
>
>
> ·        There are several possibilities
>
> 1.      Continue to use * as *built in syntax.  *It’s a massive wart; you
> can’t write (*->*) because GHC thinks that’s a single lexeme;  and * is a
> terrifically useful infix operator, so stealing it is horrible.   I’m sure
> we would never do this today.
>
> 2.      Import a module Data.Type to bring  Type into scope using the *normal
> module scoping mechanism*.
>
>    - Advantage: no new special things
>          - Disadvantage: an extra import; and error messages might say
>          Data.Type.Type fully qualified if you didn’t have the import.
>
> 3.      Same, but export Type from Prelude.
>
>    - Advantage: no need for that special import
>          - Disadvantage: would break existing programs that define Type,
>          and import Prelude, regardless of flags.
>
> I suppose we could say that you only get Type from Prelude if -XTypeInType
> is also on, but that IS new (and ad hoc) mechanism.
>
> 4.      Define Type as a new *keyword* (with TypeInType).  It does not
> need to be imported; it cannot be overridden or redefined.  (Just like
> (->).)
>
>    - A variant of this (which I quite like) is to use the existing
>          keyword *type* (lowercase).
>          - Advantage: simple clear story
>          - Note: won’t break existing code; only code that says TypeInType
>
> Is that a fair summary of the design space?
>
> Simon
>
>
>
>
>
> *From:* Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
>
> *Sent:* 09 February 2018 17:47
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>
> *Cc:* Richard Eisenberg <rae at cs.brynmawr.edu>;
> ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
>
>
> *Subject:* Re: [ghc-steering-committee] Proposal: Embrace Type in Type
>
>
>
> The issue I see is that it is quite common to get a kind error without
> doing any fancy type level programming---in particular without writing kind
> signatures or anything like that.  So you'd have no reason to import
> `Data.Kind(Type)`.    The result would be that GHC would give quite a
> verbose error message, using the fully qualified name of `Type`.  Unless we
> did something special.
>
>
>
> -Iavor
>
>
>
>
>
> On Fri, Feb 9, 2018 at 2:41 AM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> I’m not sure I see the problem here.  If ‘Int’ is not in scope then
>
> f :: Int -> Int
>
> won’t work.  What’s different about ‘Type’
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee [mailto:
> ghc-steering-committee-bounces at haskell.org] *On Behalf Of *Richard
> Eisenberg
> *Sent:* 09 February 2018 04:26
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
> mail at joachim-breitner.de>
> *Subject:* Re: [ghc-steering-committee] Proposal: Embrace Type in Type
>
>
>
> Thanks, Iavor, for bringing this up.
>
>
>
> To clarify the proposal: -XStarIsType is orthogonal to deprecation. The
> extension is necessary in order to continue to parse existing programs, but
> if we choose to deprecate *, then we would deprecate even with -XStarIsType
> is enabled (precisely to avoid the half-deprecation scenario Iavor is
> worried about).
>
>
>
> I envisioned always printing Type unqualified in error messages, even if
> it's not imported. If a user writes Type and it's out of scope, we could
> always have a special-case check suggesting they import Data.Kind. I won't
> argue this is a principled design, though, and is likely a poor choice if
> some other Type is in scope.
>
>
>
> The truth is that I don't have a great way forward here (and haven't for
> years) and am very hopeful someone on this list can come up with one! :)
> The proposal has my best idea, but I'm still not thrilled with it.
>
>
>
> Thanks,
>
> Richard
>
>
>
> On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>
>
> Hello,
>
>
>
> I didn't see any discussion about the third part of this proposal, namely
> the addition of a new extension called `StarIsKind`.  The idea is that when
> this is on, `*` will still be treated as a special alpha-numeric name, and
> it will *always* refer to the kind of inhabited types (i.e., same as
> know).  The difference is that it cannot be used as another type-level
> operator (e.g., for multiplication).
>
>
>
> Presumably, when this extension is on, there would be no deprecation
> warning emitted for `*`? We should clarify this in the proposal.
>
>
>
> I am not certain if this is a good idea.  It makes the use of `*` sort of
> "half" deprecated, and leaves us with multiple "standard" ways to refer to
> the same thing (e.g., in type errors).  Also, if we want people to update
> their code to use `Type` instead of `*`, then we are just delaying the pain
> point to whenever `StarIsKind` ends up being not on by default.
>
>
>
> OTOH, if we don't have a standard short-hand way to refer to the kind of
> inhabited types, I imagine GHC will report some very ugly errors.  For
> example:
>
>
>
>     • Expecting one more argument to ‘Maybe’
>
>       Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type ->
> Data.Kind.Type’
>
>
>
> And this is for a fairly simple kind error, they get much longer if, say,
> monad transformers are involved.
>
>
>
> What do others think?
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
>
> > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> >
> > In particular in light of our use of “type” as a explicit namespace
> > token – so far in export and import lists and fixity declarations – I
> > worry that we will prevent ourselves from using more such explicit
> > namespace things in the future.
>
> This is a really good point. In private musings, I've often wondered about
> using the keyword `type` in expressions to denote a namespace change. More
> concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is,
> a dependently typed language does not want to have separate type-level and
> term-level namespaces. Of course, Haskell has this.
>
> The best solution I have so far to the DNP is to introduce a *new*
> namespace, distinct from the two namespaces we have so far. Let's call it
> the "default" namespace. When -XDependentTypes is on, the default namespace
> is in effect. Name lookup looks first in the default namespace. If that
> fails the namespace consulted next depends on context: the "data" namespace
> in terms and the "type" namespace in type signatures. (This last bit needs
> to be specified more concretely, but you get the idea.) Or, perhaps, a
> failed lookup in the default namespace will look up in both the type and
> data namespaces, erroring if a name appears in both.
>
> If a user wants to specify a namespace directly, they have a very easy way
> to do so: `type Foo` will look in the type namespace, `data Foo` will look
> in the data namespace, and `default Foo` will look in the default
> namespace. :) Because these keywords make sense currently only at the
> beginning of a line, this Just Works. I also imagined these constructs
> could scope over a subexpression: `type (T S)`.
>
> All of this deserves a proper proposal and it's too early for that
> proposal. Nevertheless, I'm grateful that Joachim said something here,
> given that adding `type` as a spelling of `Type` would invalidate this
> approach. I also am swayed by the fact that `Type` isn't fully primitive,
> and making a keyword mean something that's not primitive is a bit awkward.
> I thus retract this proposed alternative and will update the proposal
> accordingly.
>
> 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/20180221/fa405338/attachment-0001.html>

From rae at cs.brynmawr.edu  Wed Feb 21 17:30:12 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Wed, 21 Feb 2018 12:30:12 -0500
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <AM5PR83MB0163B7281F6CDCEF0A8DF659ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
 <AM5PR83MB0163B7281F6CDCEF0A8DF659ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <DB4A0346-1928-4AC0-B4C8-448A0946DC5F@cs.brynmawr.edu>


> On Feb 21, 2018, at 10:59 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>  
> 4.      Define Type as a new keyword (with TypeInType).  It does not need to be imported; it cannot be overridden or redefined.  (Just like (->).)   
> 
> A variant of this (which I quite like) is to use the existing keyword type (lowercase).
> Advantage: simple clear story
> Note: won’t break existing code; only code that says TypeInType

The overall proposal still would break existing code, because -XTypeOperators would now mean that * is not available. That code would have to switch to using the new syntax, whatever it may be.

Note that we can't really accept this proposal without figuring out what to do about *. Right now, -XTypeInType forces you to import Data.Kind to mention *. This is so that -XTypeInType code can also use type-level multiplication. If we merge -XTypeInType with -XPolyKinds (as proposed), then we need to resolve what will happen to existing code with -XPolyKinds and -XTypeOperators.

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

From mail at joachim-breitner.de  Wed Feb 21 17:52:02 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 21 Feb 2018 12:52:02 -0500
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CAGK9nupKg49otamTV2nUrnoPg4MiF4uzy4=jefiywn+5O6A+wg@mail.gmail.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
 <AM5PR83MB0163B7281F6CDCEF0A8DF659ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nupKg49otamTV2nUrnoPg4MiF4uzy4=jefiywn+5O6A+wg@mail.gmail.com>
Message-ID: <1519235522.1437.7.camel@joachim-breitner.de>

Hi,

here is another variant of 2

2a.  Import a module Data.Type to bring  Type into scope using the
     normal module scoping mechanism.
     But: In error messages, unless some other Type is in scope, write 
     “Type”

Advantage: good error messages for most
Disadvantage: an extra import; a small special-casing in error 
messages.

Cheers,
Joachim

Am Mittwoch, den 21.02.2018, 17:28 +0000 schrieb Iavor Diatchki:
> From the GitHub discussions and the e-mails, I've seen a couple of other options being proposed/discussed:
> 
>    * Use a unicode star operator.
>       - Pros: short, looks like the current star, much less likely to clash with stuff.
>       - Cons:  typing a unicode symbol in some editors could be a pain.
> 
>    * Continue using `*` (or another infix operator), but require that it be written in prefix notation, i.e. write `(*)` instead of `*`.
>       - Pros: less of a wart, follows normal language rules
>       - Cons: it is odd to use an infix operator that is not binary (i.e., can't be written infix);  still uses up the `*` name
> 
>     * Continue using `*` but---at the type level---have it always refer to the kind, when used unqualified. This is what is called `StartIsKind` in the proposal.
> 
> 
> On Wed, Feb 21, 2018 at 7:59 AM Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > The issue about ‘*’ seems to be this
> >  
> > We need a way to write down the kind of types.   E.g.    Int :: ???
> > What is the “???”
> >  
> > ·        There are several possibilities
> > 1.      Continue to use * as built in syntax.  It’s a massive wart; you can’t write (*->*) because GHC thinks that’s a single lexeme;  and * is a terrifically useful infix operator, so stealing it is horrible.   I’m sure we would never do this today.
> > 2.      Import a module Data.Type to bring  Type into scope using the normal module scoping mechanism. 
> > Advantage: no new special things
> > Disadvantage: an extra import; and error messages might say Data.Type.Type fully qualified if you didn’t have the import.
> > 3.      Same, but export Type from Prelude.  
> > Advantage: no need for that special import
> > Disadvantage: would break existing programs that define Type, and import Prelude, regardless of flags.
> > I suppose we could say that you only get Type from Prelude if -XTypeInType is also on, but that IS new (and ad hoc) mechanism.
> > 4.      Define Type as a new keyword (with TypeInType).  It does not need to be imported; it cannot be overridden or redefined.  (Just like (->).)   
> > A variant of this (which I quite like) is to use the existing keyword type (lowercase).
> > Advantage: simple clear story
> > Note: won’t break existing code; only code that says TypeInType
> > Is that a fair summary of the design space?
> > Simon
> >  
> >  
> > From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] 
> > Sent: 09 February 2018 17:47
> > To: Simon Peyton Jones <simonpj at microsoft.com>
> > Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
> > 
> > Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type
> >  
> > The issue I see is that it is quite common to get a kind error without doing any fancy type level programming---in particular without writing kind signatures or anything like that.  So you'd have no reason to import `Data.Kind(Type)`.    The result would be that GHC would give quite a verbose error message, using the fully qualified name of `Type`.  Unless we did something special.
> >  
> > -Iavor
> >  
> >  
> > On Fri, Feb 9, 2018 at 2:41 AM Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > > I’m not sure I see the problem here.  If ‘Int’ is not in scope then
> > > f :: Int -> Int
> > > won’t work.  What’s different about ‘Type’
> > >  
> > > Simon
> > >  
> > > From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Richard Eisenberg
> > > Sent: 09 February 2018 04:26
> > > To: Iavor Diatchki <iavor.diatchki at gmail.com>
> > > Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
> > > Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type
> > >  
> > > Thanks, Iavor, for bringing this up.
> > >  
> > > To clarify the proposal: -XStarIsType is orthogonal to deprecation. The extension is necessary in order to continue to parse existing programs, but if we choose to deprecate *, then we would deprecate even with -XStarIsType is enabled (precisely to avoid the half-deprecation scenario Iavor is worried about).
> > >  
> > > I envisioned always printing Type unqualified in error messages, even if it's not imported. If a user writes Type and it's out of scope, we could always have a special-case check suggesting they import Data.Kind. I won't argue this is a principled design, though, and is likely a poor choice if some other Type is in scope.
> > >  
> > > The truth is that I don't have a great way forward here (and haven't for years) and am very hopeful someone on this list can come up with one! :) The proposal has my best idea, but I'm still not thrilled with it.
> > >  
> > > Thanks,
> > > Richard
> > >  
> > > > On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> > > >  
> > > > Hello,
> > > >  
> > > > I didn't see any discussion about the third part of this proposal, namely the addition of a new extension called `StarIsKind`.  The idea is that when this is on, `*` will still be treated as a special alpha-numeric name, and it will *always* refer to the kind of inhabited types (i.e., same as know).  The difference is that it cannot be used as another type-level operator (e.g., for multiplication).
> > > >  
> > > > Presumably, when this extension is on, there would be no deprecation warning emitted for `*`? We should clarify this in the proposal.
> > > >  
> > > > I am not certain if this is a good idea.  It makes the use of `*` sort of "half" deprecated, and leaves us with multiple "standard" ways to refer to the same thing (e.g., in type errors).  Also, if we want people to update their code to use `Type` instead of `*`, then we are just delaying the pain point to whenever `StarIsKind` ends up being not on by default.
> > > >  
> > > > OTOH, if we don't have a standard short-hand way to refer to the kind of inhabited types, I imagine GHC will report some very ugly errors.  For example:
> > > >  
> > > >     • Expecting one more argument to ‘Maybe’
> > > >       Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type -> Data.Kind.Type’
> > > >  
> > > > And this is for a fairly simple kind error, they get much longer if, say, monad transformers are involved.
> > > >  
> > > > What do others think?
> > > >  
> > > > -Iavor
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > > On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> > > > > > On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > > > > >
> > > > > > In particular in light of our use of “type” as a explicit namespace
> > > > > > token – so far in export and import lists and fixity declarations – I
> > > > > > worry that we will prevent ourselves from using more such explicit
> > > > > > namespace things in the future.
> > > > > 
> > > > > This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does not want to have separate type-level and term-level namespaces. Of course, Haskell has this.
> > > > > 
> > > > > The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.
> > > > > 
> > > > > If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.
> > > > > 
> > > > > All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type` isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.
> > > > > 
> > > > > 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
-- 
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/20180221/8ba0789a/attachment.sig>

From chak at justtesting.org  Wed Feb 21 22:39:05 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Thu, 22 Feb 2018 09:39:05 +1100
Subject: [ghc-steering-committee] Steering committee discussions
In-Reply-To: <1519221253.1437.3.camel@joachim-breitner.de>
References: <AM5PR83MB0163AC1720856152C15DF4FFADCF0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1519135094.1105.6.camel@joachim-breitner.de>
 <393A464A-3FF2-42F3-9233-D8743B3A01DD@justtesting.org>
 <AM5PR83MB0163B322D81F4F60E4E4B06CADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1519221253.1437.3.camel@joachim-breitner.de>
Message-ID: <B3936DC6-07C4-472E-B408-F17E8AAFD905@justtesting.org>

Great, thanks.

> Am 22.02.2018 um 00:54 schrieb Joachim Breitner <mail at joachim-breitner.de>:
> 
> Hi,
> 
> I see a strong majority for keeping it this way.
> 
> I updated the section
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> with Simon’s input and also generally made it reflect our de-facto
> process.
> 
> Cheers,
> Joachim
> 
> 
> Am Mittwoch, den 21.02.2018, 09:14 +0000 schrieb Simon Peyton Jones:
>> I don't feel strongly.
>> 
>> But then I think we should make it clear on the home page https://github.com/ghc-proposals/ghc-proposals  that
>> 
>> * What is the committee email address
>> 
>> * That it is publicly readable (but not writable?)
>> 
>> * That authors are strongly encouraged to follow the discussion about their
>>  proposal (during step 5), and use to improve their proposal, even
>>  if it is accepted.
>> 
>> Simon
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: ghc-steering-committee [mailto:ghc-steering-committee-
>>> bounces at haskell.org] On Behalf Of Manuel M T Chakravarty
>>> Sent: 21 February 2018 02:23
>>> To: Joachim Breitner <mail at joachim-breitner.de>
>>> Cc: ghc-steering-committee at haskell.org
>>> Subject: Re: [ghc-steering-committee] Steering committee discussions
>>> 
>>> I am sorry, but I am against moving the committee discussion to
>>> GitHub. This is for the following reasons:
>>> 
>>> * I don’t think, we will gain anything by moving to GitHub. Nothing is
>>> lost on the email list. The proposal author and anybody else can
>>> follow along as this is a public list.
>>> 
>>> * Proposals have a life cycle: writing, public commenting, refinement,
>>> and finally committee discussion (and then it may go around again if
>>> the proposal needs to be revised). Having the public, collaborative
>>> writing, public commenting, refinement steps on GitHub and the
>>> somewhat closed committee decision process on different media makes
>>> the mode change very explicit, which is good.
>>> 
>>> * I get a lot of email from GitHub. Most of it I deleted right away
>>> (including most ghc-proposal GitHub messages). Having the committee
>>> decision process by email makes it clear when I need to pay attention
>>> (without having to consult GitHub ticket labels).
>>> 
>>> * The Shepard has an incentive to briefly summarise the outcome of the
>>> committee discussion on GitHub after the decision is made (if it is
>>> all on GitHub, everybody needs to wade though everything).
>>> 
>>> * On GitHub it is much harder to see which comments are new,
>>> especially if the thread is long, because there was already a long
>>> community discussion phase.
>>> 
>>> * The committee discussion may be interleaved with additional public
>>> comments, because anybody else can comment, too, at the time, making
>>> it even harder to distinguish the committee discussion.
>>> 
>>> Cheers,
>>> Manuel
>>> 
>>>> 21.02.2018 00:58 Joachim Breitner <mail at joachim-breitner.de>:
>>>> 
>>>> Hi,
>>>> 
>>>> Am Dienstag, den 20.02.2018, 11:19 +0000 schrieb Simon Peyton Jones:
>>>>> The thread below is a case in point.  Good stuff from Joachim, but
>>>>> not visible to the author or the world; result, lost insights.
>>>> 
>>>> actually, in this case, I did bring this up in the discussion on
>>>> GitHub; the author was not convinced and brought the proposal
>>> forward
>>>> anyways, so now I am trying to sway the committee instead :-)
>>>> 
>>>> 
>>>>> Suggestion: could we hold all the committee debase on the proposal
>>>>> thread, thereby allowing the author to chime in if need be?   There
>>>>> might be some messages we want to be private -- very well, use the
>>>>> email list for those, but my sense is that 95% are absolutely
>>>>> publishable.
>>>> 
>>>> This list is public, do not post private stuff here! It is just a
>>> bit
>>>> “less visible” and less noisy.
>>>> 
>>>> Having technical discussions on GitHub is a reasonable thing to do.
>>> It
>>>> will be more noisy, i.e. many people chiming in, but that can of
>>>> course also be a good thing.
>>>> 
>>>>> What changes when the shepherd kicks in?  Answer: the committee
>>>>> switches from observer (and contribute if you like) mode, to
>>>>> obligation-to-consider mode.
>>>> 
>>>> Correct.
>>>> 
>>>> Shall we still require mails to the list when
>>>> 
>>>> * A proposal was put forward
>>>> * A shepherd makes a suggestions, and invites the committee to
>>>>  comment (now on GitHub)
>>>> * The shepherd or the secretary observes consensus, and declares
>>>>  a decision?
>>>> 
>>>> 
>>>> (This will actually make my life of assembling the “Status” mails
>>>> easier, but it will make it harder to determine consensus.)
>>>> 
>>>> All in all, I’m up for trying it out!
>>>> 
>>>> 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-
>>> committ
>>>> ee
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
>>> committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From rae at cs.brynmawr.edu  Thu Feb 22 04:18:56 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Wed, 21 Feb 2018 23:18:56 -0500
Subject: [ghc-steering-committee] Unlifted Newtypes (#98)
In-Reply-To: <3A79812C-E21D-4D03-B468-F4D29C7723D2@justtesting.org>
References: <C4725662-BF52-4770-B2A7-16B2F8547A12@cs.brynmawr.edu>
 <3A79812C-E21D-4D03-B468-F4D29C7723D2@justtesting.org>
Message-ID: <D74F9558-A0C6-42B4-82F1-417CC3A888F8@cs.brynmawr.edu>

Conversation here has ebbed down. I am understanding this to mean acceptance, in accordance with my recommendation. In roughly a week, I'll conclude that indeed we have accepted this proposal.

Thanks,
Richard

> On Feb 12, 2018, at 9:43 PM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> 
> Given that you think the levity polymorphism-related implications are fine, the proposal seems fine to me.
> 
> Manuel
> 
>> 12.02.2018 11:28 Richard Eisenberg <rae at cs.brynmawr.edu>:
>> 
>> I have been assigned as the shepherd for proposal #98: Unlifted Newtypes, https://github.com/ghc-proposals/ghc-proposals/pull/98
>> 
>> Summary:
>> 
>> This proposal suggests lifting the current restriction that newtype kinds are always Type -- that is, TYPE LiftedRep. At its core, that's the entire proposal; the rest is just motivation (which is quite well-written, if you're feeling unmotivated) and consequences. Here are a few of the twists and turns:
>> 
>> - The non-Type kinds should be inferred, based on the kind of the wrapped type. In the event of a trivial recursive newtype (e.g., newtype Void = Void Void), the kind would default to lifted, though the user could override this behavior with a kind signature using GADT syntax. The proposal author conjectures that all inhabited unlifted newtypes will have inferrable kinds; I've not tried hard to prove or refute this claim.
>> 
>> - The proposal suggests that the Coercible mechanism be extended to deal with unlifted types. This could be handled by generalizing the type of `coerce` to be levity-polymorphic. Note that doing so does not violate levity polymorphism restrictions, because coerce always inlines to a cast, and casts are erased before code generation. If `coerce` is generalized, GeneralizedNewtypeDeriving will work over the new unlifted newtypes.
>> 
>> - The proposal suggests that newtypes can indeed be levity-polymorphic: newtype Id# (r :: RuntimeRep) (a :: TYPE r) = MkId# a. This does not appear to violate levity polymorphism restrictions, either, because the MkId# constructor doesn't appear in Core. Any use of this newtype will have to be specialized to a certain RuntimeRep, but that specialization would already be guaranteed by the existing levity polymorphism restrictions.
>> 
>> The main drawback in the proposal is that this is the first way users can create their own unlifted types. Accordingly, a user might unwittingly use an unlifted type where they expect laziness; the strictness that, say, an unlifted-variable pattern binding would induce would be a surprise and hard to find.
>> 
>> Opinion & recommendation:
>> 
>> I am in support of this proposal and propose acceptance. The motivation section in the proposal is compelling, and this seems a natural generalization of existing structures. There are no concrete syntax ramifications. Given the existing levity polymorphism set-up, this proposal seems like an easy win.
>> 
>> If we are concerned about unexpected strictness, we could require that all unlifted newtypes be suffixed with one or more hashes, but I do not recommend doing so, instead encouraging library-writers to be sensitive to this problem, giving those authors the latitude to choose the best name for their types.
>> 
>> Thanks,
>> Richard
>> 
>> _______________________________________________
>> 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  Thu Feb 22 09:25:22 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 22 Feb 2018 09:25:22 +0000
Subject: [ghc-steering-committee] Unlifted Newtypes (#98)
In-Reply-To: <D74F9558-A0C6-42B4-82F1-417CC3A888F8@cs.brynmawr.edu>
References: <C4725662-BF52-4770-B2A7-16B2F8547A12@cs.brynmawr.edu>
 <3A79812C-E21D-4D03-B468-F4D29C7723D2@justtesting.org>
 <D74F9558-A0C6-42B4-82F1-417CC3A888F8@cs.brynmawr.edu>
Message-ID: <AM5PR83MB01630C0F3A131FB71E0E1274ADCD0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Yes, I like this proposal.

Some thoughts about the text of the proposal, here
https://github.com/andrewthad/ghc-proposals/blob/unboxed_newtypes/proposals/0000-unlifted-newtypes.rst

* Data families.  "Under this proposal, this restriction (that data families
  must have a lifted return kind) would be lifted".  That's fine, but I'd like
  some additional text pointing out that the reason for this is that we can
  define newtype instances of that family.  Indeed, if the return kind is
  only unlifted (e.g. TYPE 'IntRep) then we can /only/ define newtype instances
  (because data instances would be lifted).  If the return kind is polymorphic
  (which I assume is allowed -- better to say) then we can define both kinds
  of instances.

* "More generally, if an unlifted newtype is well-kinded, then its kind should
  always be inferrable."  I'm not sure exactly what this means, or if it is correct.
  What we /do/ want is that if the programmer writes a CUSK for each type constructor
  then all the kinds work out.  The question of whether you can /infer/ such kinds
  is another matter, and probably orthogonal to this proposal.

  I think that might be all we need.  E.g. for Recurse, you can't write a CUSK
  because it would be inifinite.

  The text should give the CUSKs for GoodA and GoodB, and explain why you can't
  give one for BadA and BadB.



|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Richard Eisenberg
|  Sent: 22 February 2018 04:19
|  To: Manuel M T Chakravarty <chak at justtesting.org>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Unlifted Newtypes (#98)
|  
|  Conversation here has ebbed down. I am understanding this to mean
|  acceptance, in accordance with my recommendation. In roughly a week,
|  I'll conclude that indeed we have accepted this proposal.
|  
|  Thanks,
|  Richard
|  
|  > On Feb 12, 2018, at 9:43 PM, Manuel M T Chakravarty
|  <chak at justtesting.org> wrote:
|  >
|  > Given that you think the levity polymorphism-related implications
|  are fine, the proposal seems fine to me.
|  >
|  > Manuel
|  >
|  >> 12.02.2018 11:28 Richard Eisenberg <rae at cs.brynmawr.edu>:
|  >>
|  >> I have been assigned as the shepherd for proposal #98: Unlifted
|  Newtypes, https://github.com/ghc-proposals/ghc-proposals/pull/98
|  >>
|  >> Summary:
|  >>
|  >> This proposal suggests lifting the current restriction that newtype
|  kinds are always Type -- that is, TYPE LiftedRep. At its core, that's
|  the entire proposal; the rest is just motivation (which is quite well-
|  written, if you're feeling unmotivated) and consequences. Here are a
|  few of the twists and turns:
|  >>
|  >> - The non-Type kinds should be inferred, based on the kind of the
|  wrapped type. In the event of a trivial recursive newtype (e.g.,
|  newtype Void = Void Void), the kind would default to lifted, though
|  the user could override this behavior with a kind signature using GADT
|  syntax. The proposal author conjectures that all inhabited unlifted
|  newtypes will have inferrable kinds; I've not tried hard to prove or
|  refute this claim.
|  >>
|  >> - The proposal suggests that the Coercible mechanism be extended to
|  deal with unlifted types. This could be handled by generalizing the
|  type of `coerce` to be levity-polymorphic. Note that doing so does not
|  violate levity polymorphism restrictions, because coerce always
|  inlines to a cast, and casts are erased before code generation. If
|  `coerce` is generalized, GeneralizedNewtypeDeriving will work over the
|  new unlifted newtypes.
|  >>
|  >> - The proposal suggests that newtypes can indeed be levity-
|  polymorphic: newtype Id# (r :: RuntimeRep) (a :: TYPE r) = MkId# a.
|  This does not appear to violate levity polymorphism restrictions,
|  either, because the MkId# constructor doesn't appear in Core. Any use
|  of this newtype will have to be specialized to a certain RuntimeRep,
|  but that specialization would already be guaranteed by the existing
|  levity polymorphism restrictions.
|  >>
|  >> The main drawback in the proposal is that this is the first way
|  users can create their own unlifted types. Accordingly, a user might
|  unwittingly use an unlifted type where they expect laziness; the
|  strictness that, say, an unlifted-variable pattern binding would
|  induce would be a surprise and hard to find.
|  >>
|  >> Opinion & recommendation:
|  >>
|  >> I am in support of this proposal and propose acceptance. The
|  motivation section in the proposal is compelling, and this seems a
|  natural generalization of existing structures. There are no concrete
|  syntax ramifications. Given the existing levity polymorphism set-up,
|  this proposal seems like an easy win.
|  >>
|  >> If we are concerned about unexpected strictness, we could require
|  that all unlifted newtypes be suffixed with one or more hashes, but I
|  do not recommend doing so, instead encouraging library-writers to be
|  sensitive to this problem, giving those authors the latitude to choose
|  the best name for their types.
|  >>
|  >> Thanks,
|  >> 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 marlowsd at gmail.com  Thu Feb 22 10:57:35 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 22 Feb 2018 10:57:35 +0000
Subject: [ghc-steering-committee] Unlifted Newtypes (#98)
In-Reply-To: <D74F9558-A0C6-42B4-82F1-417CC3A888F8@cs.brynmawr.edu>
References: <C4725662-BF52-4770-B2A7-16B2F8547A12@cs.brynmawr.edu>
 <3A79812C-E21D-4D03-B468-F4D29C7723D2@justtesting.org>
 <D74F9558-A0C6-42B4-82F1-417CC3A888F8@cs.brynmawr.edu>
Message-ID: <CANsrgPJteiLGAwztH5777O-WJ9q6G=mvt6aHVQ8u+WVif6F-Fw@mail.gmail.com>

I'm in favour of the proposal, but on this point:

> The proposal author conjectures that all inhabited unlifted newtypes will
have inferrable kinds; I've not tried hard to prove or refute this claim.

What will happen if a kind can't be inferred? What error message will the
user see?

I think the potential for confusion goes further than "the strictness that,
say, an unlifted-variable pattern binding would induce would be a surprise
and hard to find.". The user is quite likely to encounter type errors due
to trying to use an unlifted newtype in a pair or a list, for example, or
returning one in a monad.  In this case they'll see a kind mismatch error,
ideally we would want the compiler to emit a helpful hint in these cases.

Cheers
Simon

On 22 February 2018 at 04:18, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:

> Conversation here has ebbed down. I am understanding this to mean
> acceptance, in accordance with my recommendation. In roughly a week, I'll
> conclude that indeed we have accepted this proposal.
>
> Thanks,
> Richard
>
> > On Feb 12, 2018, at 9:43 PM, Manuel M T Chakravarty <
> chak at justtesting.org> wrote:
> >
> > Given that you think the levity polymorphism-related implications are
> fine, the proposal seems fine to me.
> >
> > Manuel
> >
> >> 12.02.2018 11:28 Richard Eisenberg <rae at cs.brynmawr.edu>:
> >>
> >> I have been assigned as the shepherd for proposal #98: Unlifted
> Newtypes, https://github.com/ghc-proposals/ghc-proposals/pull/98
> >>
> >> Summary:
> >>
> >> This proposal suggests lifting the current restriction that newtype
> kinds are always Type -- that is, TYPE LiftedRep. At its core, that's the
> entire proposal; the rest is just motivation (which is quite well-written,
> if you're feeling unmotivated) and consequences. Here are a few of the
> twists and turns:
> >>
> >> - The non-Type kinds should be inferred, based on the kind of the
> wrapped type. In the event of a trivial recursive newtype (e.g., newtype
> Void = Void Void), the kind would default to lifted, though the user could
> override this behavior with a kind signature using GADT syntax. The
> proposal author conjectures that all inhabited unlifted newtypes will have
> inferrable kinds; I've not tried hard to prove or refute this claim.
> >>
> >> - The proposal suggests that the Coercible mechanism be extended to
> deal with unlifted types. This could be handled by generalizing the type of
> `coerce` to be levity-polymorphic. Note that doing so does not violate
> levity polymorphism restrictions, because coerce always inlines to a cast,
> and casts are erased before code generation. If `coerce` is generalized,
> GeneralizedNewtypeDeriving will work over the new unlifted newtypes.
> >>
> >> - The proposal suggests that newtypes can indeed be levity-polymorphic:
> newtype Id# (r :: RuntimeRep) (a :: TYPE r) = MkId# a. This does not appear
> to violate levity polymorphism restrictions, either, because the MkId#
> constructor doesn't appear in Core. Any use of this newtype will have to be
> specialized to a certain RuntimeRep, but that specialization would already
> be guaranteed by the existing levity polymorphism restrictions.
> >>
> >> The main drawback in the proposal is that this is the first way users
> can create their own unlifted types. Accordingly, a user might unwittingly
> use an unlifted type where they expect laziness; the strictness that, say,
> an unlifted-variable pattern binding would induce would be a surprise and
> hard to find.
> >>
> >> Opinion & recommendation:
> >>
> >> I am in support of this proposal and propose acceptance. The motivation
> section in the proposal is compelling, and this seems a natural
> generalization of existing structures. There are no concrete syntax
> ramifications. Given the existing levity polymorphism set-up, this proposal
> seems like an easy win.
> >>
> >> If we are concerned about unexpected strictness, we could require that
> all unlifted newtypes be suffixed with one or more hashes, but I do not
> recommend doing so, instead encouraging library-writers to be sensitive to
> this problem, giving those authors the latitude to choose the best name for
> their types.
> >>
> >> Thanks,
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180222/155b5bc8/attachment-0001.html>

From marlowsd at gmail.com  Thu Feb 22 11:46:54 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 22 Feb 2018 11:46:54 +0000
Subject: [ghc-steering-committee] Please review: Int8/Word8,
 Shepherd: Simon Marlow
In-Reply-To: <1518061232.1186.1.camel@joachim-breitner.de>
References: <1518061232.1186.1.camel@joachim-breitner.de>
Message-ID: <CANsrgPJ0-V7ZvLfkG7Vam8XYSMsf25pG8_TvQKom2D-xcWccLA@mail.gmail.com>

I recommend that we accept this proposal.

The proposal itself I think is uncontroversial: the current situation is
somewhat historical; we realised when implementing the Data.Int and
Data.Word libraries that it would be easier to build on top of a small
family of narrow# primitives than to implement full sized types, so we took
the shortest route at the time. That stopgap has served well up to this
point, but we're missing some functionality that proper sized types would
give us: better packing of unboxed fields in constructors, and in general
better consistency in the internals (e.g. I think sized types will allow
the removal of some ugly hacks in the FFI to do with calling external
functions that take small integer arguments).

So, while the proposal itself is uncontroversial, I expect there to be a
lot to do at the code review stage to ensure we integrate this smoothly
(e.g. the issues around calling conventions and LLVM integration). But
that's not a concern for this committee, so I recommend we just accept.

Cheers
Simon

On 8 February 2018 at 03:40, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Small types like `Int8#`/`Word8#` were proposed
> https://github.com/ghc-proposals/ghc-proposals/pull/74
>
> I propose Simon Marlow as the Shepherd.
>
> Simon, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> I suggest you make a recommendation 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/20180222/99e30240/attachment.html>

From simonpj at microsoft.com  Thu Feb 22 12:27:12 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 22 Feb 2018 12:27:12 +0000
Subject: [ghc-steering-committee] Please review: Int8/Word8,
 Shepherd: Simon Marlow
In-Reply-To: <CANsrgPJ0-V7ZvLfkG7Vam8XYSMsf25pG8_TvQKom2D-xcWccLA@mail.gmail.com>
References: <1518061232.1186.1.camel@joachim-breitner.de>
 <CANsrgPJ0-V7ZvLfkG7Vam8XYSMsf25pG8_TvQKom2D-xcWccLA@mail.gmail.com>
Message-ID: <AM5PR83MB0163461AB2F79438FB72D1D8ADCD0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

OK with me.  (Though I have not really focused on the detail.)

Simon

From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Simon Marlow
Sent: 22 February 2018 11:47
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Please review: Int8/Word8, Shepherd: Simon Marlow

I recommend that we accept this proposal.
The proposal itself I think is uncontroversial: the current situation is somewhat historical; we realised when implementing the Data.Int and Data.Word libraries that it would be easier to build on top of a small family of narrow# primitives than to implement full sized types, so we took the shortest route at the time. That stopgap has served well up to this point, but we're missing some functionality that proper sized types would give us: better packing of unboxed fields in constructors, and in general better consistency in the internals (e.g. I think sized types will allow the removal of some ugly hacks in the FFI to do with calling external functions that take small integer arguments).
So, while the proposal itself is uncontroversial, I expect there to be a lot to do at the code review stage to ensure we integrate this smoothly (e.g. the issues around calling conventions and LLVM integration). But that's not a concern for this committee, so I recommend we just accept.
Cheers
Simon

On 8 February 2018 at 03:40, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

Small types like `Int8#`/`Word8#` were proposed
https://github.com/ghc-proposals/ghc-proposals/pull/74<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F74&data=04%7C01%7Csimonpj%40microsoft.com%7Cd5b8e0a627814b24f58408d579ea000a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636548968299549878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=TFYYSNIhD%2BxwBFD6JoHmHMqcLMP8VDR%2FrP8ZI%2BE8v0o%3D&reserved=0>

I propose Simon Marlow as the Shepherd.

Simon, please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=04%7C01%7Csimonpj%40microsoft.com%7Cd5b8e0a627814b24f58408d579ea000a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636548968299549878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=%2B3Av3hjglae%2BbUENN03KHmqCqlAlVS5vED3eW3NltPA%3D&reserved=0>

I suggest you make a recommendation about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cd5b8e0a627814b24f58408d579ea000a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636548968299706143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=8BW0RQKj67ivdkrbRQvRbKi%2FgdyX%2Fpjf4%2FasummzAUA%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From mail at joachim-breitner.de  Thu Feb 22 16:39:53 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 22 Feb 2018 11:39:53 -0500
Subject: [ghc-steering-committee] Please Review: Source Plugins,
	Shepherd: Chistopher
Message-ID: <1519317593.4837.7.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Source Plugins were proposed
https://github.com/ghc-proposals/ghc-proposals/pull/107

I propose Christopher Allen as the Shepherd.

Christopher, 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, about the
decision, maybe point out debatable points, and assume that anyone who
stays quiet agrees with you.

Thanks,
-- 
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/20180222/6289ace4/attachment.sig>

From mail at joachim-breitner.de  Thu Feb 22 16:39:52 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 22 Feb 2018 11:39:52 -0500
Subject: [ghc-steering-committee] Please Review: kind and type vars in
	forall, Shepherd: Simon PJ
Message-ID: <1519317592.4837.6.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Treating kind and type vars the same in forall was proposed:
https://github.com/ghc-proposals/ghc-proposals/pull/103

I propose Simon PJ as the Shepherd.

Simon, please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process

I suggest you make a recommendation, in a new e-mail thread, about the
decision, maybe point out debatable points, and assume that anyone who
stays quiet agrees with you.

Thanks,
-- 
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/20180222/391c90f8/attachment.sig>

From chak at justtesting.org  Thu Feb 22 23:24:41 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Fri, 23 Feb 2018 10:24:41 +1100
Subject: [ghc-steering-committee] Please review: Int8/Word8,
 Shepherd: Simon Marlow
In-Reply-To: <CANsrgPJ0-V7ZvLfkG7Vam8XYSMsf25pG8_TvQKom2D-xcWccLA@mail.gmail.com>
References: <1518061232.1186.1.camel@joachim-breitner.de>
 <CANsrgPJ0-V7ZvLfkG7Vam8XYSMsf25pG8_TvQKom2D-xcWccLA@mail.gmail.com>
Message-ID: <C3CC1558-1BA4-4A16-B850-DDF257E1EA2C@justtesting.org>

Sounds good to me.

Manuel

> Am 22.02.2018 um 22:46 schrieb Simon Marlow <marlowsd at gmail.com>:
> 
> I recommend that we accept this proposal.
> 
> The proposal itself I think is uncontroversial: the current situation is somewhat historical; we realised when implementing the Data.Int and Data.Word libraries that it would be easier to build on top of a small family of narrow# primitives than to implement full sized types, so we took the shortest route at the time. That stopgap has served well up to this point, but we're missing some functionality that proper sized types would give us: better packing of unboxed fields in constructors, and in general better consistency in the internals (e.g. I think sized types will allow the removal of some ugly hacks in the FFI to do with calling external functions that take small integer arguments).
> 
> So, while the proposal itself is uncontroversial, I expect there to be a lot to do at the code review stage to ensure we integrate this smoothly (e.g. the issues around calling conventions and LLVM integration). But that's not a concern for this committee, so I recommend we just accept.
> 
> Cheers
> Simon
> 
> On 8 February 2018 at 03:40, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Small types like `Int8#`/`Word8#` were proposed
> https://github.com/ghc-proposals/ghc-proposals/pull/74 <https://github.com/ghc-proposals/ghc-proposals/pull/74>
> 
> I propose Simon Marlow as the Shepherd.
> 
> Simon, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> 
> I suggest you make a recommendation about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
> 
> Thanks,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From arnaud.spiwack at tweag.io  Fri Feb 23 14:08:24 2018
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 23 Feb 2018 15:08:24 +0100
Subject: [ghc-steering-committee] GHC proposal process: merging and closing
Message-ID: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>

Dear all,

Joachim directed me here to raise some remarks about the proposal process
that I've brought up.

Out of the hundred or so submitted proposals, only roughly half were
closed, including a mere 11 merged.

On the merging end, I noticed, in particular that the backpack proposal[1]
has not been merged. The reason being that it had been implemented before
the committee had time to evaluate it, hence became out of scope.

Why do we merge proposals? One reason proposal can be referred to by pull
requests authors to describe the changes that they're implementing. The
other reason that I can see is that proposals can serve as documentation:
they can be referred to inside the documentation to explain why things are
done the way they are, they can be browsed by curious onlookers who want to
understand the trade-offs that went into this particular design, we could
even consider linking to them in the manual as longer-form stand-alone
pieces of documentation for individual features.

>From that point of view the backpack proposal ought to have been merged: it
is still documentation after the implementation is finished. Irrespective
of whether the committee has had to work for it.

On the "closing" side, I think we should be better at triaging. It's less
important, of course, because forgotten PRs fall behind are not seen by
anybody. But it could help give a valuable feeling of tidiness. I believe a
tidy repo makes people feel more at ease with sharing their thoughts. And,
just as importantly, it would help Joachim to manage the proposals: with
40+ open proposals, you probably don't know which are active, which need a
push, where he could suggest that the committee get involved. If there were
only 15 proposals to track, Joachim's time would be more efficiently spent.

I don't believe we should hesitate to close a proposal which is not under
discussion any more, authors can still reopen when they want to get back to
discussing the matter. There are quite a few dormant proposals, also
out-of-scope which didn't receive any conversation of late, or
need-revision which don't seem to be seeing any update. These could all be
closed.

What does everybody think?

[1] https://github.com/ghc-proposals/ghc-proposals/pull/5

Best,
Arnaud Spiwack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180223/df7b2912/attachment.html>

From marlowsd at gmail.com  Fri Feb 23 14:24:30 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 23 Feb 2018 14:24:30 +0000
Subject: [ghc-steering-committee] GHC proposal process: merging and
	closing
In-Reply-To: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>
References: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>
Message-ID: <CANsrgP+KTQdbr60u3zi_HwJV5c_OY6YhnYewC9EFSHkxwFP2AQ@mail.gmail.com>

Both points make a lot of sense to me.

Cheers
Simon

On 23 February 2018 at 14:08, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> Joachim directed me here to raise some remarks about the proposal process
> that I've brought up.
>
> Out of the hundred or so submitted proposals, only roughly half were
> closed, including a mere 11 merged.
>
> On the merging end, I noticed, in particular that the backpack proposal[1]
> has not been merged. The reason being that it had been implemented before
> the committee had time to evaluate it, hence became out of scope.
>
> Why do we merge proposals? One reason proposal can be referred to by pull
> requests authors to describe the changes that they're implementing. The
> other reason that I can see is that proposals can serve as documentation:
> they can be referred to inside the documentation to explain why things are
> done the way they are, they can be browsed by curious onlookers who want to
> understand the trade-offs that went into this particular design, we could
> even consider linking to them in the manual as longer-form stand-alone
> pieces of documentation for individual features.
>
> From that point of view the backpack proposal ought to have been merged:
> it is still documentation after the implementation is finished.
> Irrespective of whether the committee has had to work for it.
>
> On the "closing" side, I think we should be better at triaging. It's less
> important, of course, because forgotten PRs fall behind are not seen by
> anybody. But it could help give a valuable feeling of tidiness. I believe a
> tidy repo makes people feel more at ease with sharing their thoughts. And,
> just as importantly, it would help Joachim to manage the proposals: with
> 40+ open proposals, you probably don't know which are active, which need a
> push, where he could suggest that the committee get involved. If there were
> only 15 proposals to track, Joachim's time would be more efficiently spent.
>
> I don't believe we should hesitate to close a proposal which is not under
> discussion any more, authors can still reopen when they want to get back to
> discussing the matter. There are quite a few dormant proposals, also
> out-of-scope which didn't receive any conversation of late, or
> need-revision which don't seem to be seeing any update. These could all be
> closed.
>
> What does everybody think?
>
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/5
>
> Best,
> Arnaud Spiwack
>
> _______________________________________________
> 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/20180223/e63a9d65/attachment.html>

From mail at joachim-breitner.de  Fri Feb 23 14:36:59 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 23 Feb 2018 09:36:59 -0500
Subject: [ghc-steering-committee] GHC proposal process: merging and
 closing
In-Reply-To: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>
References: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>
Message-ID: <1519396619.28221.11.camel@joachim-breitner.de>

Hi Arnaud,

thanks for raising this; let me lay out the reasons for doing it the
current way (which is intentional, but not unchangeable):

 * Merging unapproved, but implemented proposals.

   This would mean that there would be some proposals in the directory 
   https://github.com/ghc-proposals/ghc-proposals/tree/master/proposals
 
   that were not vetted, discussed and approved. Is that desirable? It
   seems it would water down the status of the rest.

   About documentation: The proposal can still be linked, during its 
   implementation. Are you worried that the pull request will be lost 
   somehow?
  
   You also write that the manual should link proposals (I guess that 
   applies to all proposals). I don’t think we would be doing our users
   a favor here; they expect and deserve a comprehensive and self-
   contained manual.

 * Closing:

   We briefly had this discussion a while ago. The rationale to not 
   close tickets that were not officially rejected is because 
   contributor motivation is a scarce resource, and me just going
   around closing people’s proposals just because they are not able to
   press forward a lot.

   I am nudging stagnant proposals, and eventually mark them as 
   “dormant”, as a more friendly way of closing them. Many authors
   then close them voluntarily when they have abandoned it.

   Note that the overview at
   https://github.com/ghc-proposals/ghc-proposals
   links to “≡ List of proposals under discussion”
   which includes only the somewhat active propsoals.

   Maybe I can close dormant porposals when nothing has happened in
   $n$ months, with a friendly message that it can be re-opend any 
   time.

Cheers,
Joachim
   

Am Freitag, den 23.02.2018, 15:08 +0100 schrieb Spiwack, Arnaud:
> Dear all,
> 
> Joachim directed me here to raise some remarks about the proposal process that I've brought up.
> 
> Out of the hundred or so submitted proposals, only roughly half were closed, including a mere 11 merged.
> 
> On the merging end, I noticed, in particular that the backpack proposal[1] has not been merged. The reason being that it had been implemented before the committee had time to evaluate it, hence became out of scope.
> 
> Why do we merge proposals? One reason proposal can be referred to by pull requests authors to describe the changes that they're implementing. The other reason that I can see is that proposals can serve as documentation: they can be referred to inside the documentation to explain why things are done the way they are, they can be browsed by curious onlookers who want to understand the trade-offs that went into this particular design, we could even consider linking to them in the manual as longer-form stand-alone pieces of documentation for individual features.
> 
> From that point of view the backpack proposal ought to have been merged: it is still documentation after the implementation is finished. Irrespective of whether the committee has had to work for it.
> 
> On the "closing" side, I think we should be better at triaging. It's less important, of course, because forgotten PRs fall behind are not seen by anybody. But it could help give a valuable feeling of tidiness. I believe a tidy repo makes people feel more at ease with sharing their thoughts. And, just as importantly, it would help Joachim to manage the proposals: with 40+ open proposals, you probably don't know which are active, which need a push, where he could suggest that the committee get involved. If there were only 15 proposals to track, Joachim's time would be more efficiently spent.
> 
> I don't believe we should hesitate to close a proposal which is not under discussion any more, authors can still reopen when they want to get back to discussing the matter. There are quite a few dormant proposals, also out-of-scope which didn't receive any conversation of late, or need-revision which don't seem to be seeing any update. These could all be closed.
> 
> What does everybody think?
> 
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/5
> 
> Best,
> Arnaud Spiwack
> _______________________________________________
> 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/20180223/7076218b/attachment.sig>

From arnaud.spiwack at tweag.io  Fri Feb 23 15:15:45 2018
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 23 Feb 2018 16:15:45 +0100
Subject: [ghc-steering-committee] GHC proposal process: merging and
	closing
In-Reply-To: <1519396619.28221.11.camel@joachim-breitner.de>
References: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>
 <1519396619.28221.11.camel@joachim-breitner.de>
Message-ID: <CAH6fHQn-O6i4WzVNdVryfQmrz2tcYO9iFMVf091NiVfwNLJFcw@mail.gmail.com>

Hi Joachim,

 * Merging unapproved, but implemented proposals.
>
>    This would mean that there would be some proposals in the directory
>    https://github.com/ghc-proposals/ghc-proposals/tree/master/proposals
>
>    that were not vetted, discussed and approved. Is that desirable? It
>    seems it would water down the status of the rest.
>

I would consider that they were implicitly vetted by whomever merged the CR
into GHC master. Or is it too much of a stretch? Obviously they are changes
which have somewhat side-stepped the process which probably only happens
because the dust hasn't quite settled yet.


>    About documentation: The proposal can still be linked, during its
>    implementation. Are you worried that the pull request will be lost
>    somehow?
>

Not really. But if a proposal is not vetted, referring to it is less strong
an argument when you ask for merge, of course. Merge serves as a witness of
vetting. On the other hand, if this was the only reason to merge proposal,
we should remove them when they are implemented. What I was trying to get
at, is that we probably want proposals to stay, because they serve as
documentation even after they have been implemented.


>    You also write that the manual should link proposals (I guess that
>    applies to all proposals). I don’t think we would be doing our users
>    a favor here; they expect and deserve a comprehensive and self-
>    contained manual.
>

To be fair, I said "could".

And the idea is that a proposal contains a lot beyond what the manual will.
The entire specification section must make it to the manual. However, the
motivations will usually be much shortened, and the alternatives will
typically not be in a manual at all. A proposal also has a link to the
github discussion which can give really insightful historical perspectives
on a feature. So giving a link to the proposal could help someone who, for
instance, is considering contributing an extension to a given feature. It's
not something that should be prominent. But can feature in a "further
reading" section, together with the relevant scientific articles.


>   We briefly had this discussion a while ago. The rationale to not
>    close tickets that were not officially rejected is because
>    contributor motivation is a scarce resource, and me just going
>    around closing people’s proposals just because they are not able to
>    press forward a lot.
>
>    I am nudging stagnant proposals, and eventually mark them as
>    “dormant”, as a more friendly way of closing them. Many authors
>    then close them voluntarily when they have abandoned it.
>
>    Note that the overview at
>    https://github.com/ghc-proposals/ghc-proposals
>    links to “≡ List of proposals under discussion”
>    which includes only the somewhat active propsoals.
>
>    Maybe I can close dormant porposals when nothing has happened in
>    $n$ months, with a friendly message that it can be re-opend any
>    time.
>

I agree that it is a matter of reading people's psychology right. No mean
feat!

I would personally go for closing after a while. Certainly with the
friendly message!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180223/6c8ed3b0/attachment-0001.html>

From mail at joachim-breitner.de  Fri Feb 23 15:19:34 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 23 Feb 2018 10:19:34 -0500
Subject: [ghc-steering-committee] GHC proposal process: merging and
 closing
In-Reply-To: <1519396619.28221.11.camel@joachim-breitner.de>
References: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>
 <1519396619.28221.11.camel@joachim-breitner.de>
Message-ID: <1519399174.28221.14.camel@joachim-breitner.de>

Hi,

I extended my (pretty new) toolbox to gather data about the proposals
at https://github.com/nomeata/ghc-proposals-stats to give me a list
of proposals with no activity in the last 30 days. This allows me to be
efficient in nudging authors to make progress or close their PR.

Maybe that alleviates the second point a bit, while still providing a
friendly experience to the community.

Cheers,
Joachim


Am Freitag, den 23.02.2018, 09:36 -0500 schrieb Joachim Breitner:
> Hi Arnaud,
> 
> thanks for raising this; let me lay out the reasons for doing it the
> current way (which is intentional, but not unchangeable):
> 
>  * Merging unapproved, but implemented proposals.
> 
>    This would mean that there would be some proposals in the directory 
>    https://github.com/ghc-proposals/ghc-proposals/tree/master/proposals
>  
>    that were not vetted, discussed and approved. Is that desirable? It
>    seems it would water down the status of the rest.
> 
>    About documentation: The proposal can still be linked, during its 
>    implementation. Are you worried that the pull request will be lost 
>    somehow?
>   
>    You also write that the manual should link proposals (I guess that 
>    applies to all proposals). I don’t think we would be doing our users
>    a favor here; they expect and deserve a comprehensive and self-
>    contained manual.
> 
>  * Closing:
> 
>    We briefly had this discussion a while ago. The rationale to not 
>    close tickets that were not officially rejected is because 
>    contributor motivation is a scarce resource, and me just going
>    around closing people’s proposals just because they are not able to
>    press forward a lot.
> 
>    I am nudging stagnant proposals, and eventually mark them as 
>    “dormant”, as a more friendly way of closing them. Many authors
>    then close them voluntarily when they have abandoned it.
> 
>    Note that the overview at
>    https://github.com/ghc-proposals/ghc-proposals
>    links to “≡ List of proposals under discussion”
>    which includes only the somewhat active propsoals.
> 
>    Maybe I can close dormant porposals when nothing has happened in
>    $n$ months, with a friendly message that it can be re-opend any 
>    time.
> 
> Cheers,
> Joachim
>    
> 
> Am Freitag, den 23.02.2018, 15:08 +0100 schrieb Spiwack, Arnaud:
> > Dear all,
> > 
> > Joachim directed me here to raise some remarks about the proposal process that I've brought up.
> > 
> > Out of the hundred or so submitted proposals, only roughly half were closed, including a mere 11 merged.
> > 
> > On the merging end, I noticed, in particular that the backpack proposal[1] has not been merged. The reason being that it had been implemented before the committee had time to evaluate it, hence became out of scope.
> > 
> > Why do we merge proposals? One reason proposal can be referred to by pull requests authors to describe the changes that they're implementing. The other reason that I can see is that proposals can serve as documentation: they can be referred to inside the documentation to explain why things are done the way they are, they can be browsed by curious onlookers who want to understand the trade-offs that went into this particular design, we could even consider linking to them in the manual as longer-form stand-alone pieces of documentation for individual features.
> > 
> > From that point of view the backpack proposal ought to have been merged: it is still documentation after the implementation is finished. Irrespective of whether the committee has had to work for it.
> > 
> > On the "closing" side, I think we should be better at triaging. It's less important, of course, because forgotten PRs fall behind are not seen by anybody. But it could help give a valuable feeling of tidiness. I believe a tidy repo makes people feel more at ease with sharing their thoughts. And, just as importantly, it would help Joachim to manage the proposals: with 40+ open proposals, you probably don't know which are active, which need a push, where he could suggest that the committee get involved. If there were only 15 proposals to track, Joachim's time would be more efficiently spent.
> > 
> > I don't believe we should hesitate to close a proposal which is not under discussion any more, authors can still reopen when they want to get back to discussing the matter. There are quite a few dormant proposals, also out-of-scope which didn't receive any conversation of late, or need-revision which don't seem to be seeing any update. These could all be closed.
> > 
> > What does everybody think?
> > 
> > [1] https://github.com/ghc-proposals/ghc-proposals/pull/5
> > 
> > Best,
> > Arnaud Spiwack
> > _______________________________________________
> > 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/20180223/d9915841/attachment.sig>

From mail at joachim-breitner.de  Fri Feb 23 15:22:41 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 23 Feb 2018 10:22:41 -0500
Subject: [ghc-steering-committee] GHC proposal process: merging and
 closing
In-Reply-To: <CAH6fHQn-O6i4WzVNdVryfQmrz2tcYO9iFMVf091NiVfwNLJFcw@mail.gmail.com>
References: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>
 <1519396619.28221.11.camel@joachim-breitner.de>
 <CAH6fHQn-O6i4WzVNdVryfQmrz2tcYO9iFMVf091NiVfwNLJFcw@mail.gmail.com>
Message-ID: <1519399361.28221.17.camel@joachim-breitner.de>

Hi,

Am Freitag, den 23.02.2018, 16:15 +0100 schrieb Spiwack, Arnaud:
> To be fair, I said "could".

that’s fair :-)

> And the idea is that a proposal contains a lot beyond what the manual
> will. The entire specification section must make it to the manual.
> However, the motivations will usually be much shortened, and the
> alternatives will typically not be in a manual at all. A proposal
> also has a link to the github discussion which can give really
> insightful historical perspectives on a feature. So giving a link to
> the proposal could help someone who, for instance, is considering
> contributing an extension to a given feature. It's not something that
> should be prominent. But can feature in a "further reading" section,
> together with the relevant scientific articles.

True.


How about this: Out-of-scope proposals of value should be moved to the
GHC Wiki, where we already store design documents for future benefit.

Linking to them from the manual _for additional information that normal
users do not need_ is encouraged (again, this is something we already
do).


> I would personally go for closing after a while. Certainly with the friendly message!

I just did another round of nudges. I guess I will close when the
author does not respond to the nudges.

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/20180223/8b50f831/attachment.sig>

From mail at joachim-breitner.de  Fri Feb 23 15:38:59 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 23 Feb 2018 10:38:59 -0500
Subject: [ghc-steering-committee] DH quantifiers (#102),
	Recommendation: accept
Message-ID: <1519400339.28221.25.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Dependent Haskell quantifiers were proposed, by Richard.
https://github.com/ghc-proposals/ghc-proposals/pull/102
rendered at
https://github.com/goldfirere/ghc-proposals/blob/pi/proposals/0000-pi.rst

I’ll shepherd that myself.

This proposal defines and reserves the syntax for the quantifiers that
eventually Dependent Haskell will need, and allows their use where it
makes sense already (e.g. in Kinds). The quantifier are:

forall a.
forall a '.
forall a ->
forall a '->
foreach a.
foreach a '.
foreach a ->
foreach a '->
ty =>
ty '=>
ty ->
ty '->


It addresses the interaction with warning (e.g. -Wcompat). It looks
well-thought-through, one might infer that the authors wrote a thesis
about this stuff.

There is some syntactic bikeshedding possible; for example the proposal
proposes "foreach" instead of "pi" (the latter would make "pi" a
keyword, which would be unfortunate for those who deal with circles).

If someone has better ideas, in particular about the use of ' to denote
matchable arrows, we still have time to suggest them.

I recommend to accept this proposal in the current form or with further
refinements to the syntax, if we can come up with them.


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/20180223/3c8b59d9/attachment.sig>

From simonpj at microsoft.com  Fri Feb 23 15:52:46 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 23 Feb 2018 15:52:46 +0000
Subject: [ghc-steering-committee] DH quantifiers (#102),
 Recommendation: accept
In-Reply-To: <1519400339.28221.25.camel@joachim-breitner.de>
References: <1519400339.28221.25.camel@joachim-breitner.de>
Message-ID: <AM5PR83MB0163DE5F41714B4B70250B5CADCC0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Why do we need this now?  There's lots of new syntax.  Is it solving
tomorrow's problems, or todays?

Does the proposal subsume #81 (syntax for visible dependent quantification)?
That one /does/ have a current motivation.

Perhaps #102 is just a grander version of #81, reserving the syntax
but with #81 as the sole current motivation?

I'm very to get #81 nailed, because #54 depends on it, and #54
is highly desirable.

Simon



|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Joachim Breitner
|  Sent: 23 February 2018 15:39
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] DH quantifiers (#102),
|  Recommendation: accept
|  
|  Dear Committee,
|  
|  this is your secretary speaking:
|  
|  Dependent Haskell quantifiers were proposed, by Richard.
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F102&data=04%7C01%7Csimonpj%40microsoft.com%7Cae897a
|  251ef548cae01208d57ad39830%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
|  7C636549971570003501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
|  joiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=28T40QgHYUtkWDOMlME%2B9oj4HNf0d51pyb6i5901kLY%3D&reserved=0
|  rendered at
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fpi%2Fproposals%2F0000-
|  pi.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cae897a251ef548cae01208
|  d57ad39830%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63654997157000
|  3501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
|  iI6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=FLdmQUBlj57sKoREiOqDGXP%2B%2Bw98j3nZG5Z0uZy6wnA%3D&reserved=0
|  
|  I’ll shepherd that myself.
|  
|  This proposal defines and reserves the syntax for the quantifiers that
|  eventually Dependent Haskell will need, and allows their use where it
|  makes sense already (e.g. in Kinds). The quantifier are:
|  
|  forall a.
|  forall a '.
|  forall a ->
|  forall a '->
|  foreach a.
|  foreach a '.
|  foreach a ->
|  foreach a '->
|  ty =>
|  ty '=>
|  ty ->
|  ty '->
|  
|  
|  It addresses the interaction with warning (e.g. -Wcompat). It looks
|  well-thought-through, one might infer that the authors wrote a thesis
|  about this stuff.
|  
|  There is some syntactic bikeshedding possible; for example the
|  proposal proposes "foreach" instead of "pi" (the latter would make
|  "pi" a keyword, which would be unfortunate for those who deal with
|  circles).
|  
|  If someone has better ideas, in particular about the use of ' to
|  denote matchable arrows, we still have time to suggest them.
|  
|  I recommend to accept this proposal in the current form or with
|  further refinements to the syntax, if we can come up with them.
|  
|  
|  Thanks,
|  Joachim
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
|  achim-
|  breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cae897a251ef548
|  cae01208d57ad39830%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636549
|  971570003501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
|  zIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=tH%2Fxbrv4JFzFpoJ3rUm3Nz5GY7ULs1VYFRLXvvYrD5U%3D&reserved=0

From mail at joachim-breitner.de  Fri Feb 23 15:56:43 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 23 Feb 2018 10:56:43 -0500
Subject: [ghc-steering-committee] DH quantifiers (#102),
 Recommendation: accept
In-Reply-To: <AM5PR83MB0163DE5F41714B4B70250B5CADCC0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <1519400339.28221.25.camel@joachim-breitner.de>
 <AM5PR83MB0163DE5F41714B4B70250B5CADCC0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <1519401403.28221.31.camel@joachim-breitner.de>

Hi,


Am Freitag, den 23.02.2018, 15:52 +0000 schrieb Simon Peyton Jones:
> Why do we need this now?  There's lots of new syntax.  Is it solving
> tomorrow's problems, or todays?
> 
> Does the proposal subsume #81 (syntax for visible dependent quantification)?
> That one /does/ have a current motivation.
> 
> Perhaps #102 is just a grander version of #81, reserving the syntax
> but with #81 as the sole current motivation?

when #81 was proposed, Roman (as the shepherd) complained that on its
own, the choice of syntax in #81 was not very well motivated just by
that proposal. Maybe, if #81 was all there is to do, we’d choose a
different syntax! So really, the syntax in #81 is motivated by coming
up with a consistent and comprehensive syntax scheme for _all_
variations of the quantifier, and Roman asked Richard to write that up
as one proposal, instead of introducing the syntax piece by piece. And
that’s now #102.

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/20180223/842c570d/attachment-0001.sig>

From iavor.diatchki at gmail.com  Fri Feb 23 16:59:57 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 23 Feb 2018 16:59:57 +0000
Subject: [ghc-steering-committee] GHC proposal process: merging and
	closing
In-Reply-To: <1519399361.28221.17.camel@joachim-breitner.de>
References: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>
 <1519396619.28221.11.camel@joachim-breitner.de>
 <CAH6fHQn-O6i4WzVNdVryfQmrz2tcYO9iFMVf091NiVfwNLJFcw@mail.gmail.com>
 <1519399361.28221.17.camel@joachim-breitner.de>
Message-ID: <CAGK9nuoh34TV1Uom=nOYQzA+XgKg2AN=M60jmPvCjVXusdmRoQ@mail.gmail.com>

I agree that we should be more aggressive with clearing out proposals.
Here is a suggestion:  specify in the process, that after some period of
discussion proposals should either be sumbitted to the committee, or closed.

-Iavor

On Fri, Feb 23, 2018 at 7:22 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Freitag, den 23.02.2018, 16:15 +0100 schrieb Spiwack, Arnaud:
> > To be fair, I said "could".
>
> that’s fair :-)
>
> > And the idea is that a proposal contains a lot beyond what the manual
> > will. The entire specification section must make it to the manual.
> > However, the motivations will usually be much shortened, and the
> > alternatives will typically not be in a manual at all. A proposal
> > also has a link to the github discussion which can give really
> > insightful historical perspectives on a feature. So giving a link to
> > the proposal could help someone who, for instance, is considering
> > contributing an extension to a given feature. It's not something that
> > should be prominent. But can feature in a "further reading" section,
> > together with the relevant scientific articles.
>
> True.
>
>
> How about this: Out-of-scope proposals of value should be moved to the
> GHC Wiki, where we already store design documents for future benefit.
>
> Linking to them from the manual _for additional information that normal
> users do not need_ is encouraged (again, this is something we already
> do).
>
>
> > I would personally go for closing after a while. Certainly with the
> friendly message!
>
> I just did another round of nudges. I guess I will close when the
> author does not respond to the nudges.
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180223/1193a612/attachment.html>

From rae at cs.brynmawr.edu  Fri Feb 23 17:06:08 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 23 Feb 2018 12:06:08 -0500
Subject: [ghc-steering-committee] DH quantifiers (#102),
 Recommendation: accept
In-Reply-To: <1519401403.28221.31.camel@joachim-breitner.de>
References: <1519400339.28221.25.camel@joachim-breitner.de>
 <AM5PR83MB0163DE5F41714B4B70250B5CADCC0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1519401403.28221.31.camel@joachim-breitner.de>
Message-ID: <BC5D01D7-93AE-4D2B-ADBA-019461A8AEC7@cs.brynmawr.edu>

Joachim is right here. #102 is motivated by putting #81 (the `forall x y z ->` syntax)  in context. I see a few possible reactions (after suitable bikeshedding):

1. Reject the syntax. If we do this, I'd love to open a larger conversation of ways forward -- do we want tweaks to the syntax or a wholly new approach?

2. Put this idea on hold, with a plan to accept or reject #81 on its own merits.

3. Accept the proposal, but put implementation on the back burner. This would serve to reserve the syntax, without burdening our users until the features are more fully-formed.

4. Accept the proposal and plan to implement.

An advantage of implementing this now (option 4) is that it will ease backward-compatibility problems later. A disadvantage of implementing this now is that further thought may refine our ideas. Option 3 is similar, but both the advantage and disadvantage are at lower volume. Option 2 puts this advantage and disadvantage on mute.

Indeed, the only reason I would advocate for going beyond Option 2 is that the idea, in Joachim's words, looks well-thought-through [1].

Thanks,
Richard

[1]: https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1074&context=compsci_pubs

> On Feb 23, 2018, at 10:56 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> 
> Am Freitag, den 23.02.2018, 15:52 +0000 schrieb Simon Peyton Jones:
>> Why do we need this now?  There's lots of new syntax.  Is it solving
>> tomorrow's problems, or todays?
>> 
>> Does the proposal subsume #81 (syntax for visible dependent quantification)?
>> That one /does/ have a current motivation.
>> 
>> Perhaps #102 is just a grander version of #81, reserving the syntax
>> but with #81 as the sole current motivation?
> 
> when #81 was proposed, Roman (as the shepherd) complained that on its
> own, the choice of syntax in #81 was not very well motivated just by
> that proposal. Maybe, if #81 was all there is to do, we’d choose a
> different syntax! So really, the syntax in #81 is motivated by coming
> up with a consistent and comprehensive syntax scheme for _all_
> variations of the quantifier, and Roman asked Richard to write that up
> as one proposal, instead of introducing the syntax piece by piece. And
> that’s now #102.
> 
> 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  Fri Feb 23 17:12:31 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 23 Feb 2018 17:12:31 +0000
Subject: [ghc-steering-committee] DH quantifiers (#102),
	Recommendation: accept
In-Reply-To: <1519400339.28221.25.camel@joachim-breitner.de>
References: <1519400339.28221.25.camel@joachim-breitner.de>
Message-ID: <CAGK9nuoHsajv_SFnMTea1nxpdivMaSEPOSuXkRUBu3a_0rsCbw@mail.gmail.com>

Hello,

I don't think we should accept this proposal, for the following reasons:
    * it is premature to "reserve" syntax for a future extension
    * I am not convinced that a design with 12 quantifiers is what I'd want
to use
    * I am not convinced about the utility of the "dependent haskell"
extension in the first place.

-Iavor



On Fri, Feb 23, 2018 at 7:39 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Dependent Haskell quantifiers were proposed, by Richard.
> https://github.com/ghc-proposals/ghc-proposals/pull/102
> rendered at
> https://github.com/goldfirere/ghc-proposals/blob/pi/proposals/0000-pi.rst
>
> I’ll shepherd that myself.
>
> This proposal defines and reserves the syntax for the quantifiers that
> eventually Dependent Haskell will need, and allows their use where it
> makes sense already (e.g. in Kinds). The quantifier are:
>
> forall a.
> forall a '.
> forall a ->
> forall a '->
> foreach a.
> foreach a '.
> foreach a ->
> foreach a '->
> ty =>
> ty '=>
> ty ->
> ty '->
>
>
> It addresses the interaction with warning (e.g. -Wcompat). It looks
> well-thought-through, one might infer that the authors wrote a thesis
> about this stuff.
>
> There is some syntactic bikeshedding possible; for example the proposal
> proposes "foreach" instead of "pi" (the latter would make "pi" a
> keyword, which would be unfortunate for those who deal with circles).
>
> If someone has better ideas, in particular about the use of ' to denote
> matchable arrows, we still have time to suggest them.
>
> I recommend to accept this proposal in the current form or with further
> refinements to the syntax, if we can come up with them.
>
>
> 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/20180223/6478cf54/attachment.html>

From mail at joachim-breitner.de  Fri Feb 23 17:19:27 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 23 Feb 2018 12:19:27 -0500
Subject: [ghc-steering-committee] GHC proposal process: merging and
 closing
In-Reply-To: <CAGK9nuoh34TV1Uom=nOYQzA+XgKg2AN=M60jmPvCjVXusdmRoQ@mail.gmail.com>
References: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>
 <1519396619.28221.11.camel@joachim-breitner.de>
 <CAH6fHQn-O6i4WzVNdVryfQmrz2tcYO9iFMVf091NiVfwNLJFcw@mail.gmail.com>
 <1519399361.28221.17.camel@joachim-breitner.de>
 <CAGK9nuoh34TV1Uom=nOYQzA+XgKg2AN=M60jmPvCjVXusdmRoQ@mail.gmail.com>
Message-ID: <1519406367.14939.0.camel@joachim-breitner.de>

Hi,

I want to avoid codifying what does not need to be codified, but I get
the message and will close more aggressively.

(I.e. when marked as dormant and no action for another month, I’ll
close.)

Cheers,
Joachim


Am Freitag, den 23.02.2018, 16:59 +0000 schrieb Iavor Diatchki:
> I agree that we should be more aggressive with clearing out proposals.  Here is a suggestion:  specify in the process, that after some period of discussion proposals should either be sumbitted to the committee, or closed.
> 
> -Iavor
> 
> On Fri, Feb 23, 2018 at 7:22 AM Joachim Breitner <mail at joachim-breitner.de> wrote:
> > Hi,
> > 
> > Am Freitag, den 23.02.2018, 16:15 +0100 schrieb Spiwack, Arnaud:
> > > To be fair, I said "could".
> > 
> > that’s fair :-)
> > 
> > > And the idea is that a proposal contains a lot beyond what the manual
> > > will. The entire specification section must make it to the manual.
> > > However, the motivations will usually be much shortened, and the
> > > alternatives will typically not be in a manual at all. A proposal
> > > also has a link to the github discussion which can give really
> > > insightful historical perspectives on a feature. So giving a link to
> > > the proposal could help someone who, for instance, is considering
> > > contributing an extension to a given feature. It's not something that
> > > should be prominent. But can feature in a "further reading" section,
> > > together with the relevant scientific articles.
> > 
> > True.
> > 
> > 
> > How about this: Out-of-scope proposals of value should be moved to the
> > GHC Wiki, where we already store design documents for future benefit.
> > 
> > Linking to them from the manual _for additional information that normal
> > users do not need_ is encouraged (again, this is something we already
> > do).
> > 
> > 
> > > I would personally go for closing after a while. Certainly with the friendly message!
> > 
> > I just did another round of nudges. I guess I will close when the
> > author does not respond to the nudges.
> > 
> > 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/20180223/d530573c/attachment.sig>

From rae at cs.brynmawr.edu  Fri Feb 23 17:20:21 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 23 Feb 2018 12:20:21 -0500
Subject: [ghc-steering-committee] GHC proposal process: merging and
 closing
In-Reply-To: <1519406367.14939.0.camel@joachim-breitner.de>
References: <CAH6fHQnFfTU_SZHYRPgKo_-Jp82Byufo6D_b+71=+oLpYRRQeQ@mail.gmail.com>
 <1519396619.28221.11.camel@joachim-breitner.de>
 <CAH6fHQn-O6i4WzVNdVryfQmrz2tcYO9iFMVf091NiVfwNLJFcw@mail.gmail.com>
 <1519399361.28221.17.camel@joachim-breitner.de>
 <CAGK9nuoh34TV1Uom=nOYQzA+XgKg2AN=M60jmPvCjVXusdmRoQ@mail.gmail.com>
 <1519406367.14939.0.camel@joachim-breitner.de>
Message-ID: <3E8095F1-EB57-4F2C-AE6F-62F733921528@cs.brynmawr.edu>

I'm in support of this direction.

> On Feb 23, 2018, at 12:19 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> I want to avoid codifying what does not need to be codified, but I get
> the message and will close more aggressively.
> 
> (I.e. when marked as dormant and no action for another month, I’ll
> close.)

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

From mail at joachim-breitner.de  Fri Feb 23 20:14:22 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 23 Feb 2018 15:14:22 -0500
Subject: [ghc-steering-committee] Please Review: Constraint = Type,
	Shepherd: Simon PJ
Message-ID: <1519416862.18234.2.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Constraint = Type was proposed, by Richard
https://github.com/ghc-proposals/ghc-proposals/pull/32

I propose Simon PJ as the shepherd, as he – as far as I know – already
had a close look.

Simon, please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process

I suggest you make a recommendation, in a new e-mail thread, about the
decision, maybe point out debatable points, and assume that anyone who
stays quiet agrees with you.

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/20180223/13fa48e8/attachment.sig>

From mail at joachim-breitner.de  Fri Feb 23 20:15:21 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 23 Feb 2018 15:15:21 -0500
Subject: [ghc-steering-committee] Please Review: Type-level type
	applications, Shepherd: Richard
Message-ID: <1519416921.18234.3.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Type-level type applications were proposed
https://github.com/ghc-proposals/ghc-proposals/pull/80

I propose Richard as the shepherd, as this is clearly up his allay.

Richard, 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, about the
decision, maybe point out debatable points, and assume that anyone who
stays quiet agrees with you.

Thanks,
-- 
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/20180223/f88b6fe8/attachment.sig>

From mail at joachim-breitner.de  Fri Feb 23 20:18:05 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 23 Feb 2018 15:18:05 -0500
Subject: [ghc-steering-committee] Please Review: kind!!,
	Shepherd: Manuel Chakravarty
Message-ID: <1519417085.18234.6.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

the kind!! command ghci was proposed:
https://github.com/ghc-proposals/ghc-proposals/pull/79

I propose Manuel as the shepherd, as he is the the only remaining
committee member who is currently not shepherding anything(!).

Manuel, 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, about the
decision, maybe point out debatable points, and assume that anyone who
stays quiet agrees with you.

Thanks,
-- 
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/20180223/d3b7daeb/attachment.sig>

From ben at well-typed.com  Fri Feb 23 20:26:10 2018
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 23 Feb 2018 15:26:10 -0500
Subject: [ghc-steering-committee] Please review: Int8/Word8,
	Shepherd: Simon Marlow
In-Reply-To: <CANsrgPJ0-V7ZvLfkG7Vam8XYSMsf25pG8_TvQKom2D-xcWccLA@mail.gmail.com>
References: <1518061232.1186.1.camel@joachim-breitner.de>
 <CANsrgPJ0-V7ZvLfkG7Vam8XYSMsf25pG8_TvQKom2D-xcWccLA@mail.gmail.com>
Message-ID: <87zi3zsbab.fsf@smart-cactus.org>

Simon Marlow <marlowsd at gmail.com> writes:

> I recommend that we accept this proposal.
>
Yes, I agree. This seems like something with very few downsides.

Cheers,

- Ben

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

From rae at cs.brynmawr.edu  Fri Feb 23 20:32:22 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 23 Feb 2018 15:32:22 -0500
Subject: [ghc-steering-committee] Type-level type applications (#80):
	Recommend accept
Message-ID: <C5A20EE2-4B2C-4051-836A-94B0E331D6AE@cs.brynmawr.edu>

This proposal (https://github.com/ghc-proposals/ghc-proposals/pull/80 <https://github.com/ghc-proposals/ghc-proposals/pull/80>) introduces type-level type applications, extending the existing TypeApplications syntax to work in types.

- With -XTypeApplications, you will be able to instantiate kind variables in types. For example, you could talk about `Proxy @(Type -> Type) Maybe` and `Category @(TYPE IntRep) (->)` or even `(->) @(TYPE LiftedRep) @(TYPE DoubleRep)`.

And that's it! GHC *already* has the required/specified/inferred distinction in terms, which is unchanged in types.

I believe strongly we should accept. There was no substantive dissenting commentary, just clarifying questions.

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

From simonpj at microsoft.com  Wed Feb 21 15:59:35 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 21 Feb 2018 15:59:35 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
References: <CAGK9nup68EMgntVJWBEYFHqyOVEVv3tz9NRrewZewNZuR5Bhfg@mail.gmail.com>
 <3D2241C3-83E3-4C40-AC8E-05C6427C6859@justtesting.org>
 <1517536698.25075.5.camel@joachim-breitner.de>
 <8C41757D-F21E-42C8-838D-6AC15AC6CC69@cs.brynmawr.edu>
 <CAGK9nuqC=x+ZKtjMzQMUxUU5pc9kfGAPrUfd60tbjk0PDxy5pQ@mail.gmail.com>
 <D3E65683-28FA-4467-8245-3E251981FC8B@cs.brynmawr.edu>
 <VI1PR83MB0174BE3C73F8D59EA8014F46ADF20@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <CAGK9nurZ4MTUA1J2sCRn4U33uomGH=RqX1r1yigfuEs-CE-7Ng@mail.gmail.com>
Message-ID: <AM5PR83MB0163B7281F6CDCEF0A8DF659ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

The issue about ‘*’ seems to be this


  *   We need a way to write down the kind of types.   E.g.    Int :: ???

What is the “???”



·        There are several possibilities

1.      Continue to use * as built in syntax.  It’s a massive wart; you can’t write (*->*) because GHC thinks that’s a single lexeme;  and * is a terrifically useful infix operator, so stealing it is horrible.   I’m sure we would never do this today.

2.      Import a module Data.Type to bring  Type into scope using the normal module scoping mechanism.

        *   Advantage: no new special things
        *   Disadvantage: an extra import; and error messages might say Data.Type.Type fully qualified if you didn’t have the import.

3.      Same, but export Type from Prelude.

        *   Advantage: no need for that special import
        *   Disadvantage: would break existing programs that define Type, and import Prelude, regardless of flags.
I suppose we could say that you only get Type from Prelude if -XTypeInType is also on, but that IS new (and ad hoc) mechanism.

4.      Define Type as a new keyword (with TypeInType).  It does not need to be imported; it cannot be overridden or redefined.  (Just like (->).)

        *   A variant of this (which I quite like) is to use the existing keyword type (lowercase).
        *   Advantage: simple clear story
        *   Note: won’t break existing code; only code that says TypeInType
Is that a fair summary of the design space?
Simon


From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
Sent: 09 February 2018 17:47
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Richard Eisenberg <rae at cs.brynmawr.edu>; ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type

The issue I see is that it is quite common to get a kind error without doing any fancy type level programming---in particular without writing kind signatures or anything like that.  So you'd have no reason to import `Data.Kind(Type)`.    The result would be that GHC would give quite a verbose error message, using the fully qualified name of `Type`.  Unless we did something special.

-Iavor


On Fri, Feb 9, 2018 at 2:41 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I’m not sure I see the problem here.  If ‘Int’ is not in scope then
f :: Int -> Int
won’t work.  What’s different about ‘Type’

Simon

From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>] On Behalf Of Richard Eisenberg
Sent: 09 February 2018 04:26
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type

Thanks, Iavor, for bringing this up.

To clarify the proposal: -XStarIsType is orthogonal to deprecation. The extension is necessary in order to continue to parse existing programs, but if we choose to deprecate *, then we would deprecate even with -XStarIsType is enabled (precisely to avoid the half-deprecation scenario Iavor is worried about).

I envisioned always printing Type unqualified in error messages, even if it's not imported. If a user writes Type and it's out of scope, we could always have a special-case check suggesting they import Data.Kind. I won't argue this is a principled design, though, and is likely a poor choice if some other Type is in scope.

The truth is that I don't have a great way forward here (and haven't for years) and am very hopeful someone on this list can come up with one! :) The proposal has my best idea, but I'm still not thrilled with it.

Thanks,
Richard

On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,

I didn't see any discussion about the third part of this proposal, namely the addition of a new extension called `StarIsKind`.  The idea is that when this is on, `*` will still be treated as a special alpha-numeric name, and it will *always* refer to the kind of inhabited types (i.e., same as know).  The difference is that it cannot be used as another type-level operator (e.g., for multiplication).

Presumably, when this extension is on, there would be no deprecation warning emitted for `*`? We should clarify this in the proposal.

I am not certain if this is a good idea.  It makes the use of `*` sort of "half" deprecated, and leaves us with multiple "standard" ways to refer to the same thing (e.g., in type errors).  Also, if we want people to update their code to use `Type` instead of `*`, then we are just delaying the pain point to whenever `StarIsKind` ends up being not on by default.

OTOH, if we don't have a standard short-hand way to refer to the kind of inhabited types, I imagine GHC will report some very ugly errors.  For example:

    • Expecting one more argument to ‘Maybe’
      Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type -> Data.Kind.Type’

And this is for a fairly simple kind error, they get much longer if, say, monad transformers are involved.

What do others think?

-Iavor






On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:

> On Feb 1, 2018, at 8:58 PM, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
>
> In particular in light of our use of “type” as a explicit namespace
> token – so far in export and import lists and fixity declarations – I
> worry that we will prevent ourselves from using more such explicit
> namespace things in the future.

This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does not want to have separate type-level and term-level namespaces. Of course, Haskell has this.

The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.

If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.

All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type` isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.

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/20180221/0efad63f/attachment-0001.html>

From rrnewton at gmail.com  Fri Feb 23 20:22:55 2018
From: rrnewton at gmail.com (Ryan Newton)
Date: Fri, 23 Feb 2018 15:22:55 -0500
Subject: [ghc-steering-committee] Please review: Mutable constructor
 fields, Shepherd: Ryan Newton
In-Reply-To: <CACYs5AZBPurRJ0xsqOj06TOz6PgET-Zm3nE0FtyH41PwGqPBEg@mail.gmail.com>
References: <1500034660.7133.5.camel@joachim-breitner.de>
 <CACYs5AbW2d7wuYQ5fEyH8Kdtxv3b4srPhn74e8MDQYpSC7=vtw@mail.gmail.com>
 <CAGK9nuq5Jf9GfXSECkAhMCExNMhx9ZsG4N7ZmJMLUi=Ne04Dig@mail.gmail.com>
 <CACYs5AaqzxzQdbkFs+caL8S_PeNdQvNNtcyQ9BxQ=qNAurqFoA@mail.gmail.com>
 <CAGK9nupbOSZ-jTkenYbrRpvO2CMjz-bG8a6Hs3kdsoo9BooG0g@mail.gmail.com>
 <33016754-2802-47E0-87B3-0BBD80C12FFE@cs.brynmawr.edu>
 <CACYs5AZBPurRJ0xsqOj06TOz6PgET-Zm3nE0FtyH41PwGqPBEg@mail.gmail.com>
Message-ID: <CACYs5AZ97U7kjwRQoPM1isxa6D29=8TahNCuLdWJkZRagWbMgQ@mail.gmail.com>

Ok, I'm not hearing any strong objections and over the long course of
discussion in various venues, reactions have been mostly positive.  Since
committee discussion here has died down, I move to go ahead and accept this
proposal if there are no further objections.

Best,
  -Ryan


On Mon, Feb 19, 2018 at 11:53 AM, Ryan Newton <rrnewton at gmail.com> wrote:

> Hi Richard,
>
> My feeling is that "what to allow re: IO/ST/PrimMonad" is can be changed
> later if needed.  From a minimality perspective, yes, IO and ST may be
> subsumed by a more generic form.  But I think they are probably pretty
> important as convenience features.  (And from the perspective of IO being a
> PrimMonad, it's just a specialization of an already valid type, which seems
> pretty reasonable.)
>
> I was also concerned about a syntactic check, e.g. problems with type
> synonyms.  Simon M's response was here:
> https://github.com/ghc-proposals/ghc-proposals/pull/
> 8#issuecomment-315449267
>
>
> -Ryan
>
> On Fri, Feb 16, 2018 at 2:42 PM, Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
>> I have not followed the discussion on this one, but I have a clarifying
>> question:
>>
>> - The proposal describes the shape of the mutable constructors very
>> concretely, offering the PrimMonad formulation separate from IO and ST.
>> However, doesn't the PrimMonad case subsume IO and ST? That is, couldn't we
>> remove the points about IO and ST? Or is the check very syntactic and
>> require one of those concrete syntactic shapes?
>>
>> Otherwise, I'm not very knowledgeable about this end of the operation.
>> I'll go with the consensus opinion on this.
>>
>> Richard
>>
>> On Feb 14, 2018, at 1:49 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>>
>> Perhaps, although I am not sure it is really worth the extra effort.  I
>> think if we agree to accept this (which I hope we do), we can just
>> implement it as intended.   I have some work hours that I've put aside to
>> work on this, once it is properly approved.
>>
>>
>>
>>
>>
>>
>> On Mon, Feb 12, 2018 at 9:29 AM Ryan Newton <rrnewton at gmail.com> wrote:
>>
>>> Ah, I see, does it make sense for it to be implemented "frontend only"
>>> first, with it desugaring into the current MutVar# primitives in the
>>> backend?
>>>
>>>
>>> On Mon, Feb 12, 2018 at 12:24 PM, Iavor Diatchki <
>>> iavor.diatchki at gmail.com> wrote:
>>>
>>>> I support this.
>>>>
>>>> The status of the implementation, at least on my end. is stalled a bit,
>>>> as I've been really busy with work.    Overall though, Ryan has a version
>>>> that works for STM (although it is against an older GHC and mixed up with
>>>> other experiments he is working on).   I also have a branch, where we've
>>>> implemented the basic primitives, and started work on the front-end, but
>>>> there is quite a bit to do still (e.g., we haven't really done code the
>>>> code generation changes).  I'd say there are a bunch of interesting
>>>> implementation questions that we need to answer, but in terms of the
>>>> user-facing language changes, the proposal seems sound to me.
>>>>
>>>> On Mon, Feb 12, 2018 at 9:13 AM Ryan Newton <rrnewton at gmail.com> wrote:
>>>>
>>>>> Reboot!  This has long sat idle, but I propose to now formally start
>>>>> the committee discussion period: mandatory 4 weeks, closing at end of day *March
>>>>> 10th*, or earlier if consensus occurs.  Let's use this email thread
>>>>> for that discussion.  In this mail I summarize public discussion and *argue
>>>>> for "accept"*.
>>>>>
>>>>> In short, the proposal adds a way to have multiple mutable fields
>>>>> within a data-constructor, without the indirection of using IORef.  Second
>>>>> to "linear types"
>>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/91>, this
>>>>> proposal <https://github.com/ghc-proposals/ghc-proposals/pull/8>
>>>>> generated the most total comments during public discussion (107).  This
>>>>> level of discussion was good -- given that accepted GHC proposals so far
>>>>> are mostly syntactic (or API tweaks), this would be the first with major
>>>>> compiler backend & runtime consequences.
>>>>>
>>>>> Ed Kmett and Ryan Yates have demonstrated the applicability of this
>>>>> concept to data-structure implementation.  (Indeed, I think there's a good
>>>>> reason that almost all languages mutation with mutation are implemented so
>>>>> as to allow a single heap object to have multiple mutable fields within
>>>>> it.) During the public discussion, questions were raised about interactions
>>>>> with other features and implementation strategy -- in particularly changes
>>>>> to core.  But I believe that all major concerns were eventually answered.
>>>>>
>>>>>   -Ryan
>>>>>
>>>>> P.S. Iavor, Trevor, and Ryan Yates were all working on implementation
>>>>> of this feature at various points.  Not sure what the current status of
>>>>> implementation efforts are.
>>>>>
>>>>>
>>>>> On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <
>>>>> mail at joachim-breitner.de> wrote:
>>>>>
>>>>>> Dear Committee,
>>>>>>
>>>>>> this is your secretary speaking:
>>>>>>
>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/8
>>>>>> was brought before the committee, by our own Simon Marlow.
>>>>>>
>>>>>> I propose Ryan Newton as the Shepherd, because he asked for it :-)
>>>>>>
>>>>>> Ryan, please reach consensus as described in
>>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>>>
>>>>>> I suggest you make a recommendation about the decision, maybe point
>>>>>> out
>>>>>> debatable points, and assume that anyone who stays quiet agrees with
>>>>>> you.
>>>>>>
>>>>>>
>>>>>> Greetings,
>>>>>> 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-steeri
>>>>> ng-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/20180223/94315367/attachment.html>

From cma at bitemyapp.com  Fri Feb 23 20:57:22 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Fri, 23 Feb 2018 14:57:22 -0600
Subject: [ghc-steering-committee] Please review: Int8/Word8,
 Shepherd: Simon Marlow
In-Reply-To: <87zi3zsbab.fsf@smart-cactus.org>
References: <1518061232.1186.1.camel@joachim-breitner.de>
 <CANsrgPJ0-V7ZvLfkG7Vam8XYSMsf25pG8_TvQKom2D-xcWccLA@mail.gmail.com>
 <87zi3zsbab.fsf@smart-cactus.org>
Message-ID: <CADnndOq4kJSsw-aSXejvxZrHhxFM_4=Hq1H-42yZ-zfhhRPWaQ@mail.gmail.com>

My work has been affected by not having these primitives so I'm
strongly in favor.

On Fri, Feb 23, 2018 at 2:26 PM, Ben Gamari <ben at well-typed.com> wrote:
> Simon Marlow <marlowsd at gmail.com> writes:
>
>> I recommend that we accept this proposal.
>>
> Yes, I agree. This seems like something with very few downsides.
>
> Cheers,
>
> - Ben
>
>
> _______________________________________________
> 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  Fri Feb 23 23:40:33 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 23 Feb 2018 23:40:33 +0000
Subject: [ghc-steering-committee] Type-level type applications (#80):
 Recommend accept
In-Reply-To: <C5A20EE2-4B2C-4051-836A-94B0E331D6AE@cs.brynmawr.edu>
References: <C5A20EE2-4B2C-4051-836A-94B0E331D6AE@cs.brynmawr.edu>
Message-ID: <CAGK9nura7ZBUrphr4z_RURkCx4C-7cd_Cu8-Tb8APffMq+YVDA@mail.gmail.com>

Agreed, if there are not technical issues, I would expect this to work, so
I am +1



On Fri, Feb 23, 2018 at 12:32 PM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> This proposal (https://github.com/ghc-proposals/ghc-proposals/pull/80)
> introduces type-level type applications, extending the existing
> TypeApplications syntax to work in types.
>
> - With -XTypeApplications, you will be able to instantiate kind variables
> in types. For example, you could talk about `Proxy @(Type -> Type) Maybe`
> and `Category @(TYPE IntRep) (->)` or even `(->) @(TYPE LiftedRep) @(TYPE
> DoubleRep)`.
>
> And that's it! GHC *already* has the required/specified/inferred
> distinction in terms, which is unchanged in types.
>
> I believe strongly we should accept. There was no substantive dissenting
> commentary, just clarifying questions.
>
> Thanks,
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180223/d2b0ae58/attachment-0001.html>

From chak at justtesting.org  Sat Feb 24 04:25:00 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Sat, 24 Feb 2018 15:25:00 +1100
Subject: [ghc-steering-committee] Type-level type applications
	(#80):	Recommend accept
In-Reply-To: <C5A20EE2-4B2C-4051-836A-94B0E331D6AE@cs.brynmawr.edu>
References: <C5A20EE2-4B2C-4051-836A-94B0E331D6AE@cs.brynmawr.edu>
Message-ID: <03AB5384-455A-42A1-9166-040754309914@justtesting.org>

Sounds good to me!

> Am 24.02.2018 um 07:32 schrieb Richard Eisenberg <rae at cs.brynmawr.edu>:
> 
> This proposal (https://github.com/ghc-proposals/ghc-proposals/pull/80 <https://github.com/ghc-proposals/ghc-proposals/pull/80>) introduces type-level type applications, extending the existing TypeApplications syntax to work in types.
> 
> - With -XTypeApplications, you will be able to instantiate kind variables in types. For example, you could talk about `Proxy @(Type -> Type) Maybe` and `Category @(TYPE IntRep) (->)` or even `(->) @(TYPE LiftedRep) @(TYPE DoubleRep)`.
> 
> And that's it! GHC *already* has the required/specified/inferred distinction in terms, which is unchanged in types.
> 
> I believe strongly we should accept. There was no substantive dissenting commentary, just clarifying questions.
> 
> Thanks,
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From ben at smart-cactus.org  Sun Feb 25 20:36:04 2018
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 25 Feb 2018 15:36:04 -0500
Subject: [ghc-steering-committee] Plugin recompilation avoidance
Message-ID: <87fu5ost72.fsf@smart-cactus.org>

Hi everyone,

I'm writing you in reference to GHC Proposal #108 [1], which introduces
a mechanism allowing plugins greater control over GHC's recompilation
behavior.

The committee is currently considering this proposal for acceptance and
while most of you have already expressed general support for the
proposal during the discussion period, we wanted to check once more with
you to ensure that no issues have gone unnoticed.

If any of you have any final thoughts regarding the proposal, do let us
know in the next few days. Otherwise we will accept the proposal as-is.

Cheers,

- Ben



[1] https://github.com/ghc-proposals/ghc-proposals/pull/108
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180225/2d4490c9/attachment.sig>

From simonpj at microsoft.com  Mon Feb 26 08:40:08 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 26 Feb 2018 08:40:08 +0000
Subject: [ghc-steering-committee] Type-level type applications
	(#80):	Recommend accept
In-Reply-To: <C5A20EE2-4B2C-4051-836A-94B0E331D6AE@cs.brynmawr.edu>
References: <C5A20EE2-4B2C-4051-836A-94B0E331D6AE@cs.brynmawr.edu>
Message-ID: <AM5PR83MB01631DE2194B96844F78FE6FADC10@AM5PR83MB0163.EURPRD83.prod.outlook.com>

I support this one.

Simon

From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Richard Eisenberg
Sent: 23 February 2018 20:32
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Type-level type applications (#80): Recommend accept

This proposal (https://github.com/ghc-proposals/ghc-proposals/pull/80) introduces type-level type applications, extending the existing TypeApplications syntax to work in types.

- With -XTypeApplications, you will be able to instantiate kind variables in types. For example, you could talk about `Proxy @(Type -> Type) Maybe` and `Category @(TYPE IntRep) (->)` or even `(->) @(TYPE LiftedRep) @(TYPE DoubleRep)`.

And that's it! GHC *already* has the required/specified/inferred distinction in terms, which is unchanged in types.

I believe strongly we should accept. There was no substantive dissenting commentary, just clarifying questions.

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

From marlowsd at gmail.com  Mon Feb 26 09:04:30 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 26 Feb 2018 09:04:30 +0000
Subject: [ghc-steering-committee] Type-level type applications (#80):
 Recommend accept
In-Reply-To: <C5A20EE2-4B2C-4051-836A-94B0E331D6AE@cs.brynmawr.edu>
References: <C5A20EE2-4B2C-4051-836A-94B0E331D6AE@cs.brynmawr.edu>
Message-ID: <CANsrgPKsby0tAuM-sZ-FeV5TYNJX0TN3qGdCM1kvpvJs=TFr7Q@mail.gmail.com>

Agreed.

On 23 February 2018 at 20:32, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:

> This proposal (https://github.com/ghc-proposals/ghc-proposals/pull/80)
> introduces type-level type applications, extending the existing
> TypeApplications syntax to work in types.
>
> - With -XTypeApplications, you will be able to instantiate kind variables
> in types. For example, you could talk about `Proxy @(Type -> Type) Maybe`
> and `Category @(TYPE IntRep) (->)` or even `(->) @(TYPE LiftedRep) @(TYPE
> DoubleRep)`.
>
> And that's it! GHC *already* has the required/specified/inferred
> distinction in terms, which is unchanged in types.
>
> I believe strongly we should accept. There was no substantive dissenting
> commentary, just clarifying questions.
>
> Thanks,
> Richard
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180226/1dd8b318/attachment.html>

From simonpj at microsoft.com  Mon Feb 26 11:14:15 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 26 Feb 2018 11:14:15 +0000
Subject: [ghc-steering-committee] Constraint vs Type: I propose acceptance
Message-ID: <AM5PR83MB016302A378294567BCB5AB96ADC10@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Friends
I propose that we support the GHC proposal "Declare Constraint is not apart from Type<https://github.com/ghc-proposals/ghc-proposals/blob/rae/constraint-vs-type/proposals/0000-constraint-vs-type.rst>"
Currently GHC operates an uneasy compromise:

  *   Constraint and Type are treated as distinct in the type checker (e.g. do not unify)
  *   But they are treated as the same in Core
I have spent ages in discussion with Richard and others for how to fix this wart.  Really, they should be either

  *   completely different (like Int and Bool), or
  *   completely the same (like [Char] and String).
But both these stances have problems, and nothing satisfying has emerged.  So this proposal simply fixes the worst aspect (unsoundness) of the current setup.
So I regard it as a way to stay explicitly non-committal, leaving the main question open.
There are a couple of clarifications I'd like which I've put on the discussion thread.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180226/4e912ddd/attachment-0001.html>

From simonpj at microsoft.com  Tue Feb 27 09:13:38 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 27 Feb 2018 09:13:38 +0000
Subject: [ghc-steering-committee] Section numbering
Message-ID: <AM5PR83MB0163E7B4BF9F281B76EA6BBBADC00@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Joachim
I think it'd be super-helpful to number the sections of a GHC proposal.  So much easier to navigate; and to refer to points in the discussion.
It's easy: just add

.. sectnum::
to the preamble.
Could you do that to the template?
But one other thing.   If you look at
https://github.com/Gertjan423/ghc-proposals/blob/quantified-constraints/proposals/0000-quantified-constraints.rst
where I did that, you'll see that everything is under Section 1.   better to give guidance about how to make a top-level heading that is just a heading, so only the other items have numbers.  Otherwise every section numbers starts "1." which is silly.
Thanks
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180227/d62f6cc8/attachment.html>

From simonpj at microsoft.com  Tue Feb 27 09:42:56 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 27 Feb 2018 09:42:56 +0000
Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals]
	As-pattern synonyms (#94)
In-Reply-To: <ghc-proposals/ghc-proposals/pull/94/c368036545@github.com>
References: <ghc-proposals/ghc-proposals/pull/94@github.com>
 <ghc-proposals/ghc-proposals/pull/94/c368036545@github.com>
Message-ID: <AM5PR83MB016342D2AC3305B0F895013FADC00@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Joachim

I’ve revised the as-pattern proposal and would like to submit it to the committee
https://github.com/ghc-proposals/ghc-proposals/blob/as-pattern-synonyms/AsPatternSynonyms.rst

Simon


From: Joachim Breitner [mailto:notifications at github.com]
Sent: 23 February 2018 15:14
To: ghc-proposals/ghc-proposals <ghc-proposals at noreply.github.com>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; Mention <mention at noreply.github.com>
Subject: Re: [ghc-proposals/ghc-proposals] As-pattern synonyms (#94)


@simonpj<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsimonpj&data=04%7C01%7Csimonpj%40microsoft.com%7Cc404c8a42c714914965608d57ad00ac1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636549956305640021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=tmIuKBGmSOe%2Fe2lvPAIYR%2FfFlWOa4gx4VVsXjwn4zEU%3D&reserved=0>, the discussion ebbed down. Do you want to submit it to the committee? Does the proposal need more work?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F94%23issuecomment-368036545&data=04%7C01%7Csimonpj%40microsoft.com%7Cc404c8a42c714914965608d57ad00ac1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636549956305640021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=NSKObOa2gIDRVLdi%2B5Jxb31ESHxS8JTc%2BpNz2yv%2B8A4%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAjse566WuV3RqnQ8KOMbI8EW5c3-m7gks5tXtWsgaJpZM4Qe5Cz&data=04%7C01%7Csimonpj%40microsoft.com%7Cc404c8a42c714914965608d57ad00ac1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636549956305640021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=8XO%2FjXgXzl3xUHaavhIuknlRHf9bjsXNeMIOoVtOvwk%3D&reserved=0>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180227/a7f5540c/attachment.html>

From mail at joachim-breitner.de  Tue Feb 27 14:17:52 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 27 Feb 2018 09:17:52 -0500
Subject: [ghc-steering-committee] Section numbering
In-Reply-To: <AM5PR83MB0163E7B4BF9F281B76EA6BBBADC00@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <AM5PR83MB0163E7B4BF9F281B76EA6BBBADC00@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <1519741072.1113.9.camel@joachim-breitner.de>

Hi,

I did this, and updated all accepted proposals. The trick to not number
the title is to move the document title to the very top,
before all the “.. foo::” cruft, it is excluded from numbering. See
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/00
05-bidir-constr-sigs.rst
for an example.

Cheers,
Joachim

Am Dienstag, den 27.02.2018, 09:13 +0000 schrieb Simon Peyton Jones:
> Joachim
> I think it’d be super-helpful to number the sections of a GHC proposal.  So much easier to navigate; and to refer to points in the discussion.
> It’s easy: just add
> .. sectnum::
> to the preamble.
> Could you do that to the template?  
> But one other thing.   If you look at
> https://github.com/Gertjan423/ghc-proposals/blob/quantified-constraints/proposals/0000-quantified-constraints.rst
> where I did that, you’ll see that everything is under Section 1.   better to give guidance about how to make a top-level heading that is just a heading, so only the other items have numbers.  Otherwise every section numbers starts “1.” which is silly.
> Thanks
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180227/ff812cb3/attachment.sig>

From mail at joachim-breitner.de  Tue Feb 27 14:19:58 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 27 Feb 2018 09:19:58 -0500
Subject: [ghc-steering-committee] As patterns in pattern synonyms (#94),
	Recommendation: accept
Message-ID: <1519741198.1113.11.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

As patterns in pattern synonyms, by Richard.
https://github.com/ghc-proposals/ghc-proposals/pull/94
rendered at
https://github.com/ghc-proposals/ghc-proposals/blob/as-pattern-synonyms/AsPatternSynonyms.rst

I’ll shepherd that myself.

This proposal removes restrictions on what can be used in
unidirectional pattern synonyms, where @-pattern were previously
disallowed. The restriction would make sense if patterns synonyms are
macros, but they are not. I am always in favor of removing special
cases and restrictions, so I recommend to accept this proposal.

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/20180227/40a12e22/attachment.sig>

From rae at cs.brynmawr.edu  Tue Feb 27 14:36:45 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 27 Feb 2018 09:36:45 -0500
Subject: [ghc-steering-committee] As patterns in pattern synonyms (#94),
 Recommendation: accept
In-Reply-To: <1519741198.1113.11.camel@joachim-breitner.de>
References: <1519741198.1113.11.camel@joachim-breitner.de>
Message-ID: <BAAFD61E-8CDC-4064-A734-DB1A9FAFD8CC@cs.brynmawr.edu>



> On Feb 27, 2018, at 9:19 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> As patterns in pattern synonyms, by Richard.
> https://github.com/ghc-proposals/ghc-proposals/pull/94 <https://github.com/ghc-proposals/ghc-proposals/pull/94>

I've written lots of proposals, but just to correct the record here, this one's by Simon PJ. :)

Yes, I'm happy to accept.

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

From mail at joachim-breitner.de  Tue Feb 27 14:38:40 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 27 Feb 2018 09:38:40 -0500
Subject: [ghc-steering-committee] As patterns in pattern synonyms (#94),
 Recommendation: accept
In-Reply-To: <BAAFD61E-8CDC-4064-A734-DB1A9FAFD8CC@cs.brynmawr.edu>
References: <1519741198.1113.11.camel@joachim-breitner.de>
 <BAAFD61E-8CDC-4064-A734-DB1A9FAFD8CC@cs.brynmawr.edu>
Message-ID: <1519742320.1113.13.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 27.02.2018, 09:36 -0500 schrieb Richard Eisenberg:
> I've written lots of proposals, but just to correct the record here,
> this one's by Simon PJ. :)

yeah, the dangers of copy’n’paste – I guess it is time I script the
“please review” and “recommendation” mails.

But hey, at least I can check if y’all are paying attention!

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/20180227/520ed191/attachment.sig>

From simonpj at microsoft.com  Tue Feb 27 14:57:13 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 27 Feb 2018 14:57:13 +0000
Subject: [ghc-steering-committee] Section numbering
In-Reply-To: <1519741072.1113.9.camel@joachim-breitner.de>
References: <AM5PR83MB0163E7B4BF9F281B76EA6BBBADC00@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1519741072.1113.9.camel@joachim-breitner.de>
Message-ID: <AM5PR83MB0163A0E2A67A58E5D3F6831BADC00@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Lovely thank you.

|  I did this, and updated all accepted proposals. The trick to not
|  number the title is to move the document title to the very top,

You might want to leave enough comments in the template file so that users don’t accidentally mess it up.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Joachim Breitner
|  Sent: 27 February 2018 14:18
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Section numbering
|  
|  Hi,
|  
|  I did this, and updated all accepted proposals. The trick to not
|  number the title is to move the document title to the very top, before
|  all the “.. foo::” cruft, it is excluded from numbering. See
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2Fghc-proposals%2Fghc-
|  proposals%2Fblob%2Fmaster%2Fproposals%2F00&data=04%7C01%7Csimonpj%40mi
|  crosoft.com%7Cfceb5ad58d5a4cc8e75908d57dececd1%7C72f988bf86f141af91ab2
|  d7cd011db47%7C1%7C0%7C636553378894120883%7CUnknown%7CTWFpbGZsb3d8eyJWI
|  joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=p8l7renR8eY421cQpPKVLmKbyInoNOdi%2FDnj5QjPAys%3D&reserved=0
|  05-bidir-constr-sigs.rst
|  for an example.
|  
|  Cheers,
|  Joachim
|  
|  Am Dienstag, den 27.02.2018, 09:13 +0000 schrieb Simon Peyton Jones:
|  > Joachim
|  > I think it’d be super-helpful to number the sections of a GHC
|  proposal.  So much easier to navigate; and to refer to points in the
|  discussion.
|  > It’s easy: just add
|  > .. sectnum::
|  > to the preamble.
|  > Could you do that to the template?
|  > But one other thing.   If you look at
|  >
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2FGertjan423%2Fghc-proposals%2Fblob%2Fquantified-
|  constraints%2Fproposals%2F0000-quantified-
|  constraints.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cfceb5ad58d5a4
|  cc8e75908d57dececd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63655
|  3378894120883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
|  MzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=94EgcxmIi5JhF5zNeR0oyYXmVdZ9KKyKUgYVbu0Aeks%3D&reserved=0
|  > where I did that, you’ll see that everything is under Section 1.
|  better to give guidance about how to make a top-level heading that is
|  just a heading, so only the other items have numbers.  Otherwise every
|  section numbers starts “1.” which is silly.
|  > Thanks
|  > Simon
|  > _______________________________________________
|  > 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.jo
|  achim-
|  breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cfceb5ad58d5a4c
|  c8e75908d57dececd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636553
|  378894120883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
|  zIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=hmWx3AR78Qf1VrFJB%2BykrW8jCXaxuTBmhcY8vhcEYvQ%3D&reserved=0

From mail at joachim-breitner.de  Tue Feb 27 15:50:05 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 27 Feb 2018 10:50:05 -0500
Subject: [ghc-steering-committee] Section numbering
In-Reply-To: <AM5PR83MB0163A0E2A67A58E5D3F6831BADC00@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <AM5PR83MB0163E7B4BF9F281B76EA6BBBADC00@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <1519741072.1113.9.camel@joachim-breitner.de>
 <AM5PR83MB0163A0E2A67A58E5D3F6831BADC00@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <1519746605.1113.14.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 27.02.2018, 14:57 +0000 schrieb Simon Peyton Jones:
> Lovely thank you.
> 
> >  I did this, and updated all accepted proposals. The trick to not
> >  number the title is to move the document title to the very top,
> 
> You might want to leave enough comments in the template file so that
> users don’t accidentally mess it up.

there is already plenty of noise in the beginning of the file – I’ll
consider that if people actually mess it up.

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/20180227/ca620bd3/attachment-0001.sig>

From chak at justtesting.org  Tue Feb 27 23:19:29 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 28 Feb 2018 10:19:29 +1100
Subject: [ghc-steering-committee] As patterns in pattern synonyms (#94),
	Recommendation: accept
In-Reply-To: <1519741198.1113.11.camel@joachim-breitner.de>
References: <1519741198.1113.11.camel@joachim-breitner.de>
Message-ID: <192039E2-DF38-47E6-BEBC-50722ACAF90E@justtesting.org>

+1

> Am 28.02.2018 um 01:19 schrieb Joachim Breitner <mail at joachim-breitner.de>:
> 
> Dear Committee,
> 
> this is your secretary speaking:
> 
> As patterns in pattern synonyms, by Richard.
> https://github.com/ghc-proposals/ghc-proposals/pull/94
> rendered at
> https://github.com/ghc-proposals/ghc-proposals/blob/as-pattern-synonyms/AsPatternSynonyms.rst
> 
> I’ll shepherd that myself.
> 
> This proposal removes restrictions on what can be used in
> unidirectional pattern synonyms, where @-pattern were previously
> disallowed. The restriction would make sense if patterns synonyms are
> macros, but they are not. I am always in favor of removing special
> cases and restrictions, so I recommend to accept this proposal.
> 
> 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


From mail at joachim-breitner.de  Wed Feb 28 01:05:57 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 27 Feb 2018 20:05:57 -0500
Subject: [ghc-steering-committee] Unlifted Newtypes (#98)
In-Reply-To: <D74F9558-A0C6-42B4-82F1-417CC3A888F8@cs.brynmawr.edu>
References: <C4725662-BF52-4770-B2A7-16B2F8547A12@cs.brynmawr.edu>
 <3A79812C-E21D-4D03-B468-F4D29C7723D2@justtesting.org>
 <D74F9558-A0C6-42B4-82F1-417CC3A888F8@cs.brynmawr.edu>
Message-ID: <1519779957.24956.0.camel@joachim-breitner.de>

Hi,

I agree that this is an accept!

Cheers,
Joachim



Am Mittwoch, den 21.02.2018, 23:18 -0500 schrieb Richard Eisenberg:
> Conversation here has ebbed down. I am understanding this to mean
> acceptance, in accordance with my recommendation. In roughly a week,
> I'll conclude that indeed we have accepted this proposal.
> 
> Thanks,
> Richard
> 
> > On Feb 12, 2018, at 9:43 PM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> > 
> > Given that you think the levity polymorphism-related implications are fine, the proposal seems fine to me.
> > 
> > Manuel
> > 
> > > 12.02.2018 11:28 Richard Eisenberg <rae at cs.brynmawr.edu>:
> > > 
> > > I have been assigned as the shepherd for proposal #98: Unlifted Newtypes, https://github.com/ghc-proposals/ghc-proposals/pull/98
> > > 
> > > Summary:
> > > 
> > > This proposal suggests lifting the current restriction that newtype kinds are always Type -- that is, TYPE LiftedRep. At its core, that's the entire proposal; the rest is just motivation (which is quite well-written, if you're feeling unmotivated) and consequences. Here are a few of the twists and turns:
> > > 
> > > - The non-Type kinds should be inferred, based on the kind of the wrapped type. In the event of a trivial recursive newtype (e.g., newtype Void = Void Void), the kind would default to lifted, though the user could override this behavior with a kind signature using GADT syntax. The proposal author conjectures that all inhabited unlifted newtypes will have inferrable kinds; I've not tried hard to prove or refute this claim.
> > > 
> > > - The proposal suggests that the Coercible mechanism be extended to deal with unlifted types. This could be handled by generalizing the type of `coerce` to be levity-polymorphic. Note that doing so does not violate levity polymorphism restrictions, because coerce always inlines to a cast, and casts are erased before code generation. If `coerce` is generalized, GeneralizedNewtypeDeriving will work over the new unlifted newtypes.
> > > 
> > > - The proposal suggests that newtypes can indeed be levity-polymorphic: newtype Id# (r :: RuntimeRep) (a :: TYPE r) = MkId# a. This does not appear to violate levity polymorphism restrictions, either, because the MkId# constructor doesn't appear in Core. Any use of this newtype will have to be specialized to a certain RuntimeRep, but that specialization would already be guaranteed by the existing levity polymorphism restrictions.
> > > 
> > > The main drawback in the proposal is that this is the first way users can create their own unlifted types. Accordingly, a user might unwittingly use an unlifted type where they expect laziness; the strictness that, say, an unlifted-variable pattern binding would induce would be a surprise and hard to find.
> > > 
> > > Opinion & recommendation:
> > > 
> > > I am in support of this proposal and propose acceptance. The motivation section in the proposal is compelling, and this seems a natural generalization of existing structures. There are no concrete syntax ramifications. Given the existing levity polymorphism set-up, this proposal seems like an easy win.
> > > 
> > > If we are concerned about unexpected strictness, we could require that all unlifted newtypes be suffixed with one or more hashes, but I do not recommend doing so, instead encouraging library-writers to be sensitive to this problem, giving those authors the latitude to choose the best name for their types.
> > > 
> > > Thanks,
> > > 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
-- 
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/20180227/9c18013b/attachment.sig>

From marlowsd at gmail.com  Wed Feb 28 09:25:50 2018
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 28 Feb 2018 09:25:50 +0000
Subject: [ghc-steering-committee] As patterns in pattern synonyms (#94),
 Recommendation: accept
In-Reply-To: <1519741198.1113.11.camel@joachim-breitner.de>
References: <1519741198.1113.11.camel@joachim-breitner.de>
Message-ID: <CANsrgP+bpDc0HLHkq8GicEjDTdRvYNyx2neP1WP=HemGYQiq_g@mail.gmail.com>

Looks good to me.

On 27 February 2018 at 14:19, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> As patterns in pattern synonyms, by Richard.
> https://github.com/ghc-proposals/ghc-proposals/pull/94
> rendered at
> https://github.com/ghc-proposals/ghc-proposals/blob/as-pattern-synonyms/
> AsPatternSynonyms.rst
>
> I’ll shepherd that myself.
>
> This proposal removes restrictions on what can be used in
> unidirectional pattern synonyms, where @-pattern were previously
> disallowed. The restriction would make sense if patterns synonyms are
> macros, but they are not. I am always in favor of removing special
> cases and restrictions, so I recommend to accept this proposal.
>
> 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/20180228/42868eeb/attachment.html>