From simonpj at microsoft.com  Mon Apr  2 11:41:41 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 2 Apr 2018 11:41:41 +0000
Subject: [ghc-steering-committee] Quantified constraints
Message-ID: <AM5PR83MB0163D043D58CB347002F62E8ADA60@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Joachim
I'd like submit the Quantified Constraints proposal<https://github.com/ghc-proposals/ghc-proposals/pull/109> (#109) to the committee
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180402/6bb1a8bd/attachment.html>

From mail at joachim-breitner.de  Mon Apr  2 20:06:28 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 02 Apr 2018 16:06:28 -0400
Subject: [ghc-steering-committee] Please Review: Provenance-Qualified
 Package Imports, Shepherd: Ben Gamari
Message-ID: <1522699588.15551.4.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Provenance-Qualified Package Imports by Gershom Bazerman
https://github.com/ghc-proposals/ghc-proposals/pull/115

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, 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/20180402/621d9061/attachment.sig>

From chak at justtesting.org  Mon Apr  2 21:28:47 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 3 Apr 2018 07:28:47 +1000
Subject: [ghc-steering-committee] Treat kind and type vars
	identically	with `forall` #103
In-Reply-To: <F75EF69C-8C57-4391-9315-40795483EA4A@cs.brynmawr.edu>
References: <AM5PR83MB016352A1E70E1B8F8B3DDE08ADA90@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <F75EF69C-8C57-4391-9315-40795483EA4A@cs.brynmawr.edu>
Message-ID: <9EE67167-305C-4CED-8B14-3542D0ADE8CA@justtesting.org>

I must say, I agree with Richard.

Manuel

> Am 23.03.2018 um 02:52 schrieb Richard Eisenberg <rae at cs.brynmawr.edu>:
> 
> 
>> On Mar 22, 2018, at 11:15 AM, Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
>> 
>> Dear GHC steering committee
>> 
>> I strongly propose that we accept
>> 
>>             Treat kind and type vars identically with `forall` #103
>> 
>> 
>> 
> 
> Agreed, unsurprisingly.
> 
>> Moreover, I propose that we adopt it without a 3-release wait after #83 – see under Alternatives.   Any programs that are rejected by #103 can be fixed by adding some extra forall k’s.  And that change will be accepted NOW if you add -XTypeInType.
>> 
> 
> Here I disagree. Enabling -XTypeInType has two unfortunate knock-on effects:
>  - * is no longer available in kinds, without import Data.Kind. Happily, GHC gives a good error message upon a forgotten `import Data.Kind`, so this isn't so bad, but it will bite very widely.
>  - More troublesomely, the CUSK rules are different with -XTypeInType than without. This means that turning on -XTypeInType can turn some CUSKs into non-CUSKs, producing utterly befuddling error messages. Maybe this won't bite so often, but when it does, it will take a developer a long time to sort out the problem.
> 
> After #83, these problems melt away, but I think it will be painful for users to support multiple versions in the meantime.
> 
> Richard
> 
>> Simon
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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/20180403/e32ca7ce/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180403/e32ca7ce/attachment.sig>

From cma at bitemyapp.com  Tue Apr  3 02:16:07 2018
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 2 Apr 2018 21:16:07 -0500
Subject: [ghc-steering-committee] Source plugins (#107),
	Recommendation: accept
Message-ID: <CADnndOrq-JRDOsmqSZ1wiSuTaUp5SToK82cB+M5qpS3-AGnGPg@mail.gmail.com>

Dear Committee,

Chris Allen here!

GHC source plugins were proposed by Boldizsár Németh.

The PR discussing the proposal is here:
https://github.com/ghc-proposals/ghc-proposals/pull/107

Rendered at:
https://github.com/nboldi/ghc-proposals/blob/patch-4/proposal-source-plugins.rst

This proposal suggests the extension of the existing tlugin support in
GHC with plugins that are able to access and modify the representation
of the Haskell syntax tree and its environment. This would allow tool
developers to base their tools on GHC plugins.

A version of the proposal is already implemented at:
https://phabricator.haskell.org/D4342

My present main concern would be the issues with recompilation that
the current patch introduces but that seems like a problem with an
implementation rather than the proposal. That's an issue for the GHC
devs themselves to sort out, as I understand it.

It's not obvious to me that the unresolved questions could be answered
with deliberation rather than implementation and exploration. I am far
from an expert on GHC plugins but from what I've been able to read
about them I don't see any blockers in this proposal as-written.

I reached out to a couple of people that have hacked on or around GHC
in the past and it seemed like they were most keen to find out what
problems of theirs this proposal would solve. I didn't see any actual
objections raised.

I recommend we accept this proposal in the current form or with
further elaboration at the author's option. However, my recommendation
here defers to the experience of others on the committee who know more
about the plugins API and the substance of this proposal.

-- 
Chris Allen

From rae at cs.brynmawr.edu  Tue Apr  3 04:06:14 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 3 Apr 2018 00:06:14 -0400
Subject: [ghc-steering-committee] Source plugins (#107),
 Recommendation: accept
In-Reply-To: <CADnndOrq-JRDOsmqSZ1wiSuTaUp5SToK82cB+M5qpS3-AGnGPg@mail.gmail.com>
References: <CADnndOrq-JRDOsmqSZ1wiSuTaUp5SToK82cB+M5qpS3-AGnGPg@mail.gmail.com>
Message-ID: <54C9D1E2-2554-4DD7-A951-F87821F41A3B@cs.brynmawr.edu>

This looks like a natural extension of what we currently do. I'm in favor.

Richard

> On Apr 2, 2018, at 10:16 PM, Christopher Allen <cma at bitemyapp.com> wrote:
> 
> Dear Committee,
> 
> Chris Allen here!
> 
> GHC source plugins were proposed by Boldizsár Németh.
> 
> The PR discussing the proposal is here:
> https://github.com/ghc-proposals/ghc-proposals/pull/107
> 
> Rendered at:
> https://github.com/nboldi/ghc-proposals/blob/patch-4/proposal-source-plugins.rst
> 
> This proposal suggests the extension of the existing tlugin support in
> GHC with plugins that are able to access and modify the representation
> of the Haskell syntax tree and its environment. This would allow tool
> developers to base their tools on GHC plugins.
> 
> A version of the proposal is already implemented at:
> https://phabricator.haskell.org/D4342
> 
> My present main concern would be the issues with recompilation that
> the current patch introduces but that seems like a problem with an
> implementation rather than the proposal. That's an issue for the GHC
> devs themselves to sort out, as I understand it.
> 
> It's not obvious to me that the unresolved questions could be answered
> with deliberation rather than implementation and exploration. I am far
> from an expert on GHC plugins but from what I've been able to read
> about them I don't see any blockers in this proposal as-written.
> 
> I reached out to a couple of people that have hacked on or around GHC
> in the past and it seemed like they were most keen to find out what
> problems of theirs this proposal would solve. I didn't see any actual
> objections raised.
> 
> I recommend we accept this proposal in the current form or with
> further elaboration at the author's option. However, my recommendation
> here defers to the experience of others on the committee who know more
> about the plugins API and the substance of this proposal.
> 
> -- 
> Chris Allen
> _______________________________________________
> 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 Apr  3 08:30:32 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 3 Apr 2018 08:30:32 +0000
Subject: [ghc-steering-committee] Source plugins (#107),
 Recommendation: accept
In-Reply-To: <CADnndOrq-JRDOsmqSZ1wiSuTaUp5SToK82cB+M5qpS3-AGnGPg@mail.gmail.com>
References: <CADnndOrq-JRDOsmqSZ1wiSuTaUp5SToK82cB+M5qpS3-AGnGPg@mail.gmail.com>
Message-ID: <AM5PR83MB01634C716C1C212C9085EBCCADA50@AM5PR83MB0163.EURPRD83.prod.outlook.com>

I like this in principle.  I've added some comments on the proposal thread itself.

At the moment the renamer and typechecker are run as one, which leads to extra complexity.  Now we have both untyped and typed splices, I think we can separate the two:

- untyped splices run in the renamer
- typed splices run in the typechecker

So we can completely rename the module, including running any untyped splices (of course the code we actually run is typechecked) before typechecking any of it.

But this design complication isn’t the fault of this proposal.  It's just highlighted by it.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Christopher Allen
|  Sent: 03 April 2018 03:16
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Source plugins (#107),
|  Recommendation: accept
|  
|  Dear Committee,
|  
|  Chris Allen here!
|  
|  GHC source plugins were proposed by Boldizsár Németh.
|  
|  The PR discussing the proposal is here:
|  https://github.com/ghc-proposals/ghc-proposals/pull/107
|  
|  Rendered at:
|  https://github.com/nboldi/ghc-proposals/blob/patch-4/proposal-source-
|  plugins.rst
|  
|  This proposal suggests the extension of the existing tlugin support in
|  GHC with plugins that are able to access and modify the representation
|  of the Haskell syntax tree and its environment. This would allow tool
|  developers to base their tools on GHC plugins.
|  
|  A version of the proposal is already implemented at:
|  https://phabricator.haskell.org/D4342
|  
|  My present main concern would be the issues with recompilation that
|  the current patch introduces but that seems like a problem with an
|  implementation rather than the proposal. That's an issue for the GHC
|  devs themselves to sort out, as I understand it.
|  
|  It's not obvious to me that the unresolved questions could be answered
|  with deliberation rather than implementation and exploration. I am far
|  from an expert on GHC plugins but from what I've been able to read
|  about them I don't see any blockers in this proposal as-written.
|  
|  I reached out to a couple of people that have hacked on or around GHC
|  in the past and it seemed like they were most keen to find out what
|  problems of theirs this proposal would solve. I didn't see any actual
|  objections raised.
|  
|  I recommend we accept this proposal in the current form or with
|  further elaboration at the author's option. However, my recommendation
|  here defers to the experience of others on the committee who know more
|  about the plugins API and the substance of this proposal.
|  
|  --
|  Chris Allen
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committee

From mail at joachim-breitner.de  Fri Apr  6 12:51:20 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 06 Apr 2018 08:51:20 -0400
Subject: [ghc-steering-committee] Please Review: Qualified Constraints,
	Shepherd: Richard Eisenberg
Message-ID: <1523019080.17083.2.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Qualified Constraints by Gert-Jan Bottu and SPJ
https://github.com/ghc-proposals/ghc-proposals/pull/109

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, 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/20180406/d96e1d19/attachment.sig>

From rae at cs.brynmawr.edu  Mon Apr  9 16:39:21 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 9 Apr 2018 12:39:21 -0400
Subject: [ghc-steering-committee] Quantified Constraints (#109).
	Recommendation: accept
Message-ID: <EF024DAE-E10D-4E1A-AB25-2C88FCF64D2D@cs.brynmawr.edu>

The proposal for quantified constraints, #109, has been submitted for a decision.

This proposal generalizes the syntax for constraints to include forall-quantification and premise constraints. For example:

> data Rose f a = Branch a (f (Rose f a))
> 
> instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where
>   Branch x1 c1 == Branch x2 c2 = x1 == x2 && c1 == c2

Note the `forall b. Eq b =>` in the constraint for this instance, which is necessary in order for the instance to be obviously terminating. There are *many* other motivations for this feature, dating back over a decade. Particularly pressing might be the fact that this feature will allow us to put `join` in the Monad type class, currently impossible due to the way roles work. See https://ryanglscott.github.io/2018/03/04/how-quantifiedconstraints-can-let-us-put-join-back-in-monad/ for the details (which are not necessary in order to evaluate this proposal -- merely good motivation).

The proposal introduces -XQuantfiedConstraints, which will enable the new feature, though -XExplicitForAll will also be necessary if you wish to write a `forall` explicitly (as you likely will). There are some subtleties of the typing rules, but it all basically behaves as you would expect. Quantified constraints may induce a situation where GHC must choose one of two potential routes toward proving a goal; when this happens, the program is rejected (even if one or more of the routes would have been successful). Note that quantified constraints cannot introduce incoherence, as they do not create new instances.

Simon has already implemented this feature on a branch, and as I understand it, it's working swimmingly.

Recommendation: accept.

This feature has been wanted for a long time, is a natural extension of features GHC already has (roles, higher-rank types), and has been implemented cleanly.

As usual, I will take silence as agreement. I look forward to reading your comments.

Thanks,
Richard

From mail at joachim-breitner.de  Mon Apr  9 16:54:51 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 09 Apr 2018 12:54:51 -0400
Subject: [ghc-steering-committee] Quantified Constraints (#109).
 Recommendation: accept
In-Reply-To: <EF024DAE-E10D-4E1A-AB25-2C88FCF64D2D@cs.brynmawr.edu>
References: <EF024DAE-E10D-4E1A-AB25-2C88FCF64D2D@cs.brynmawr.edu>
Message-ID: <1523292891.1069.3.camel@joachim-breitner.de>

Hi,

incidentially, just last week I had this interaction:

me: “I’d like feature X” 
icelandjack: “Quantified Constraints can do that”
me: “Yay!”

https://ghc.haskell.org/trac/ghc/ticket/15008

Hence in favor,
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/20180409/afbe8354/attachment.sig>

From chak at justtesting.org  Mon Apr  9 23:00:57 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 10 Apr 2018 09:00:57 +1000
Subject: [ghc-steering-committee] Quantified Constraints (#109).
	Recommendation: accept
In-Reply-To: <EF024DAE-E10D-4E1A-AB25-2C88FCF64D2D@cs.brynmawr.edu>
References: <EF024DAE-E10D-4E1A-AB25-2C88FCF64D2D@cs.brynmawr.edu>
Message-ID: <3D1EB36D-69E3-42CE-A6CC-56F4E5E7C573@justtesting.org>

+1

> Am 10.04.2018 um 02:39 schrieb Richard Eisenberg <rae at cs.brynmawr.edu>:
> 
> The proposal for quantified constraints, #109, has been submitted for a decision.
> 
> This proposal generalizes the syntax for constraints to include forall-quantification and premise constraints. For example:
> 
>> data Rose f a = Branch a (f (Rose f a))
>> 
>> instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where
>>  Branch x1 c1 == Branch x2 c2 = x1 == x2 && c1 == c2
> 
> Note the `forall b. Eq b =>` in the constraint for this instance, which is necessary in order for the instance to be obviously terminating. There are *many* other motivations for this feature, dating back over a decade. Particularly pressing might be the fact that this feature will allow us to put `join` in the Monad type class, currently impossible due to the way roles work. See https://ryanglscott.github.io/2018/03/04/how-quantifiedconstraints-can-let-us-put-join-back-in-monad/ for the details (which are not necessary in order to evaluate this proposal -- merely good motivation).
> 
> The proposal introduces -XQuantfiedConstraints, which will enable the new feature, though -XExplicitForAll will also be necessary if you wish to write a `forall` explicitly (as you likely will). There are some subtleties of the typing rules, but it all basically behaves as you would expect. Quantified constraints may induce a situation where GHC must choose one of two potential routes toward proving a goal; when this happens, the program is rejected (even if one or more of the routes would have been successful). Note that quantified constraints cannot introduce incoherence, as they do not create new instances.
> 
> Simon has already implemented this feature on a branch, and as I understand it, it's working swimmingly.
> 
> Recommendation: accept.
> 
> This feature has been wanted for a long time, is a natural extension of features GHC already has (roles, higher-rank types), and has been implemented cleanly.
> 
> As usual, I will take silence as agreement. I look forward to reading your comments.
> 
> 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 chak at justtesting.org  Mon Apr  9 23:08:28 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 10 Apr 2018 09:08:28 +1000
Subject: [ghc-steering-committee]
 =?utf-8?q?Proposal_=2379_=22Add_a_=3Akin?=
 =?utf-8?q?d!!_command_to_ghci=22_=E2=80=94_propose_yes?=
In-Reply-To: <AM5PR83MB0163B8229A9D2CFB1B747815ADA90@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <1A21C65F-1761-47F1-B922-E70BFFE12CAB@justtesting.org>
 <AM5PR83MB0163B8229A9D2CFB1B747815ADA90@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <CE79926E-95FE-497A-9954-A675A3642187@justtesting.org>

Ok, so it looks like we should bounce this back to the author to improve the syntax and address Richard’s comment. This what I will do unless I hear otherwise by the end of the week. 

Cheers,
Manuel 

> Am 22.03.2018 um 23:26 schrieb Simon Peyton Jones <simonpj at microsoft.com>:
> 
> Like Richard
> 
> * I like the goal
> * I hate the proposed command :kind!
> 
> I suppose we could add
>   :eval <expression>
> as a way to evaluate <expression>; a long-form of
>   <expression>
> and then
>   :eval type <type>
> for this proposal.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Manuel M T Chakravarty
> |  Sent: 21 March 2018 02:43
> |  To: ghc-steering-committee at haskell.org
> |  Subject: [ghc-steering-committee] Proposal #79 "Add a :kind!! command
> |  to ghci" — propose yes
> |  
> |  We need to decide on the Proposal #79 ”Add a :kind!! command to ghci,
> |  to expand type families and type synonyms”:
> |  
> |    (rendered)
> |  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> |  b.com%2Falpmestan%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0000-
> |  kind-bang-
> |  bang.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc5767d25630244346d5a
> |  08d58ed5770e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636571969830
> |  865127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> |  BTiI6Ik1haWwifQ%3D%3D%7C-
> |  1&sdata=TiBF9Hg1BxieAB2B6Naez9FWiX53Hhfg0BP%2B%2F3MKjHs%3D&reserved=0
> |    (discussion)
> |  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> |  b.com%2Fghc-proposals%2Fghc-
> |  proposals%2Fpull%2F79&data=04%7C01%7Csimonpj%40microsoft.com%7Cc5767d2
> |  5630244346d5a08d58ed5770e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
> |  C636571969830865127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> |  oiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
> |  1&sdata=VhEDSDfQQM19L3sY1yyuT5cHJ24jroBSdVg19DVWZiE%3D&reserved=0
> |  
> |  I agree that this is useful functionality and it is a simple change to
> |  GHCi. There has been some discussion about the naming of this command,
> |  but TBH I didn’t find any of the alternatives more convincing than
> |  ”:kind!!”, so I’d suggest to stick with that.
> |  
> |  I favour accepting this proposal. Are there any dissenting opinions?
> |  
> |  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 mail at joachim-breitner.de  Tue Apr 10 17:31:02 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 10 Apr 2018 13:31:02 -0400
Subject: [ghc-steering-committee] Please Review: Kinds Without Promotion,
	Shepherd: Ryan Newton
Message-ID: <597ac8a627675358f27c8faafc96e5b4044078a5.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Kinds Without Promotion by Yavor
https://github.com/ghc-proposals/ghc-proposals/pull/106

I propose Ryan Newton as the shepherd.

Ryan, 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
-- 
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/20180410/8d601ea7/attachment.sig>

From mail at joachim-breitner.de  Fri Apr 13 23:48:33 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 13 Apr 2018 16:48:33 -0700
Subject: [ghc-steering-committee] Treat kind and type vars identically
 with `forall` #103
In-Reply-To: <F75EF69C-8C57-4391-9315-40795483EA4A@cs.brynmawr.edu>
References: <AM5PR83MB016352A1E70E1B8F8B3DDE08ADA90@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <F75EF69C-8C57-4391-9315-40795483EA4A@cs.brynmawr.edu>
Message-ID: <dc18ac6b5e75c2fe6de745159f719476b79ba0c4.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 22.03.2018, 11:52 -0400 schrieb Richard Eisenberg:
> > On Mar 22, 2018, at 11:15 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> > 
> > Dear GHC steering committee
> > I strongly propose that we accept
> >             Treat kind and type vars identically with `forall` #103
> 
> Agreed, unsurprisingly.

there seems to be consensus.


> > Moreover, I propose that we adopt it without a 3-release wait after
> > #83 – see under Alternatives.   Any programs that are rejected by
> > #103 can be fixed by adding some extra forall k’s.  And that change
> > will be accepted NOW if you add -XTypeInType. 
> 
> Here I disagree. Enabling -XTypeInType has two unfortunate knock-on
> effects:
>  - * is no longer available in kinds, without import Data.Kind.
> Happily, GHC gives a good error message upon a forgotten `import
> Data.Kind`, so this isn't so bad, but it will bite very widely.
>  - More troublesomely, the CUSK rules are different with -XTypeInType
> than without. This means that turning on -XTypeInType can turn some
> CUSKs into non-CUSKs, producing utterly befuddling error messages.
> Maybe this won't bite so often, but when it does, it will take a
> developer a long time to sort out the problem.
> 
> After #83, these problems melt away, but I think it will be painful
> for users to support multiple versions in the meantime.
> 
> Richard

what does this mean for this proposal? Is there disagreement over
quickly the proposal will be implemented?

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/20180413/3f7cbd69/attachment.sig>

From mail at joachim-breitner.de  Fri Apr 13 23:51:59 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 13 Apr 2018 16:51:59 -0700
Subject: [ghc-steering-committee] Source plugins (#107),
 Recommendation: accept
In-Reply-To: <CADnndOrq-JRDOsmqSZ1wiSuTaUp5SToK82cB+M5qpS3-AGnGPg@mail.gmail.com>
References: <CADnndOrq-JRDOsmqSZ1wiSuTaUp5SToK82cB+M5qpS3-AGnGPg@mail.gmail.com>
Message-ID: <b3f78be224ac703f313278c581a33aa5e3f9c1f0.camel@joachim-breitner.de>

Hi,

Am Montag, den 02.04.2018, 21:16 -0500 schrieb Christopher Allen:
> I recommend we accept this proposal in the current form or with
> further elaboration at the author's option.

we only got positive responses here, so accepted as the 17ths 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/20180413/5eca9c2e/attachment.sig>

From mail at joachim-breitner.de  Fri Apr 13 23:53:51 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 13 Apr 2018 16:53:51 -0700
Subject: [ghc-steering-committee] DH quantifiers (#102),
 Recommendation: accept
In-Reply-To: <4C756BA3-D25A-4387-99D4-DEBDA7D5FB32@cs.brynmawr.edu>
References: <1519400339.28221.25.camel@joachim-breitner.de>
 <CAGK9nuoHsajv_SFnMTea1nxpdivMaSEPOSuXkRUBu3a_0rsCbw@mail.gmail.com>
 <32A4865D-5D1A-4B90-9FD3-7BB1356E0626@cs.brynmawr.edu>
 <AM5PR83MB0163E24C5743B35C51EFC09CADAC0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <4C756BA3-D25A-4387-99D4-DEBDA7D5FB32@cs.brynmawr.edu>
Message-ID: <6e77f3eba4ad1302c6d2e37c35a1a1ebaf19f7e3.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 28.03.2018, 13:10 -0400 schrieb Richard Eisenberg:
> Agreed with all points Simon makes below -- including on punting on
> #102 with a personal hope to return some day not too distant from
> now. I'll update the proposal with my analysis from the email.

did you do this update? If so, you can change the label of the proposal
to “Needs revision” or “dormant” or something similar.


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/20180413/360f79db/attachment.sig>

From mail at joachim-breitner.de  Fri Apr 13 23:54:50 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 13 Apr 2018 16:54:50 -0700
Subject: [ghc-steering-committee] Plugin recompilation avoidance
 interface (#108)
In-Reply-To: <87tvt7k6gj.fsf@smart-cactus.org>
References: <87a7w4uzt8.fsf@smart-cactus.org> <87tvtypfw2.fsf@smart-cactus.org>
 <CAGK9nuqV=ncbsmJ1zcexoGXR4MR9=snKAuSt-kLt+pQ-wv2Dqw@mail.gmail.com>
 <CANsrgPJtqknPmQruTsGHOTxOhz-OWq7wDVC=fFYonY=1aymZXA@mail.gmail.com>
 <1520259286.1311.10.camel@joachim-breitner.de>
 <87ina2z74g.fsf@smart-cactus.org> <87tvt7k6gj.fsf@smart-cactus.org>
Message-ID: <ddfe4881e8369146ced97256ee0413bf8e940b2d.camel@joachim-breitner.de>

Hi Ben,

Am Donnerstag, den 22.03.2018, 19:59 -0400 schrieb Ben Gamari:
> Does anyone object to accepting the simple approach as suggested by
> Joachim?

I think you can go ahead with this one.

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/20180413/70b003eb/attachment.sig>

From ben at well-typed.com  Sat Apr 14 16:42:15 2018
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 14 Apr 2018 12:42:15 -0400
Subject: [ghc-steering-committee] Plugin recompilation avoidance
	interface (#108)
In-Reply-To: <ddfe4881e8369146ced97256ee0413bf8e940b2d.camel@joachim-breitner.de>
References: <87a7w4uzt8.fsf@smart-cactus.org> <87tvtypfw2.fsf@smart-cactus.org>
 <CAGK9nuqV=ncbsmJ1zcexoGXR4MR9=snKAuSt-kLt+pQ-wv2Dqw@mail.gmail.com>
 <CANsrgPJtqknPmQruTsGHOTxOhz-OWq7wDVC=fFYonY=1aymZXA@mail.gmail.com>
 <1520259286.1311.10.camel@joachim-breitner.de>
 <87ina2z74g.fsf@smart-cactus.org> <87tvt7k6gj.fsf@smart-cactus.org>
 <ddfe4881e8369146ced97256ee0413bf8e940b2d.camel@joachim-breitner.de>
Message-ID: <874lkdg2ot.fsf@smart-cactus.org>

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

> Hi Ben,
>
> Am Donnerstag, den 22.03.2018, 19:59 -0400 schrieb Ben Gamari:
>> Does anyone object to accepting the simple approach as suggested by
>> Joachim?
>
> I think you can go ahead with this one.
>
Sounds good. Let's accept.

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/20180414/ea0c1cec/attachment.sig>

From rae at cs.brynmawr.edu  Mon Apr 16 03:07:26 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 15 Apr 2018 23:07:26 -0400
Subject: [ghc-steering-committee] DH quantifiers (#102),
 Recommendation: accept
In-Reply-To: <6e77f3eba4ad1302c6d2e37c35a1a1ebaf19f7e3.camel@joachim-breitner.de>
References: <1519400339.28221.25.camel@joachim-breitner.de>
 <CAGK9nuoHsajv_SFnMTea1nxpdivMaSEPOSuXkRUBu3a_0rsCbw@mail.gmail.com>
 <32A4865D-5D1A-4B90-9FD3-7BB1356E0626@cs.brynmawr.edu>
 <AM5PR83MB0163E24C5743B35C51EFC09CADAC0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <4C756BA3-D25A-4387-99D4-DEBDA7D5FB32@cs.brynmawr.edu>
 <6e77f3eba4ad1302c6d2e37c35a1a1ebaf19f7e3.camel@joachim-breitner.de>
Message-ID: <0F424E6F-D887-4D53-8EBE-68C6B8F756B3@cs.brynmawr.edu>

Done. Proposal marked as dormant.

> On Apr 13, 2018, at 7:53 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Mittwoch, den 28.03.2018, 13:10 -0400 schrieb Richard Eisenberg:
>> Agreed with all points Simon makes below -- including on punting on
>> #102 with a personal hope to return some day not too distant from
>> now. I'll update the proposal with my analysis from the email.
> 
> did you do this update? If so, you can change the label of the proposal
> to “Needs revision” or “dormant” or something similar.
> 
> 
> Cheers,
> Joachim
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From rae at cs.brynmawr.edu  Mon Apr 16 03:09:13 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 15 Apr 2018 23:09:13 -0400
Subject: [ghc-steering-committee] Proposal: Syntax for visible dependent
 quantification (#81)
In-Reply-To: <88AAAB4F-4C45-43EF-B4A4-D095982FCBDF@cs.brynmawr.edu>
References: <CAADqg9bZktCwGik=4G9DJh0jb5VDPrWdSPE1U4_C4MXZoHmHbw@mail.gmail.com>
 <30B357D6-E03C-4A03-8D6C-F5BF22BF0E13@cs.brynmawr.edu>
 <88AAAB4F-4C45-43EF-B4A4-D095982FCBDF@cs.brynmawr.edu>
Message-ID: <4704D092-353A-4113-9B2F-482FD3F7D1AF@cs.brynmawr.edu>

Hi committee,

I'd like to reboot this discussion, now that #102 has been written, debated, and tabled. As a reminder, this proposal is blocking #54, which will cure real bugs GHC is plagued by.

Thanks!
Richard

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

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

From rae at cs.brynmawr.edu  Mon Apr 16 03:11:49 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 15 Apr 2018 23:11:49 -0400
Subject: [ghc-steering-committee] Treat kind and type vars identically
 with `forall` #103
In-Reply-To: <dc18ac6b5e75c2fe6de745159f719476b79ba0c4.camel@joachim-breitner.de>
References: <AM5PR83MB016352A1E70E1B8F8B3DDE08ADA90@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <F75EF69C-8C57-4391-9315-40795483EA4A@cs.brynmawr.edu>
 <dc18ac6b5e75c2fe6de745159f719476b79ba0c4.camel@joachim-breitner.de>
Message-ID: <720B3F27-9A49-4F31-BE42-B35AD5A73531@cs.brynmawr.edu>



> On Apr 13, 2018, at 7:48 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> what does this mean for this proposal? Is there disagreement over
> quickly the proposal will be implemented?

Yes, I believe there has been disagreement here, with Simon advocating for a sooner implementation, and Manuel and I arguing for a more delayed implementation (specifically, 2 releases after #83 is implemented).

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

From mail at joachim-breitner.de  Mon Apr 16 04:33:29 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 15 Apr 2018 21:33:29 -0700
Subject: [ghc-steering-committee] Plugin recompilation avoidance
 interface (#108)
In-Reply-To: <874lkdg2ot.fsf@smart-cactus.org>
References: <87a7w4uzt8.fsf@smart-cactus.org> <87tvtypfw2.fsf@smart-cactus.org>
 <CAGK9nuqV=ncbsmJ1zcexoGXR4MR9=snKAuSt-kLt+pQ-wv2Dqw@mail.gmail.com>
 <CANsrgPJtqknPmQruTsGHOTxOhz-OWq7wDVC=fFYonY=1aymZXA@mail.gmail.com>
 <1520259286.1311.10.camel@joachim-breitner.de>
 <87ina2z74g.fsf@smart-cactus.org> <87tvt7k6gj.fsf@smart-cactus.org>
 <ddfe4881e8369146ced97256ee0413bf8e940b2d.camel@joachim-breitner.de>
 <874lkdg2ot.fsf@smart-cactus.org>
Message-ID: <68f2bae22cf2db39e3ac83fa36aa977453c0f671.camel@joachim-breitner.de>

Hi,

Am Samstag, den 14.04.2018, 12:42 -0400 schrieb Ben Gamari:
> Joachim Breitner <mail at joachim-breitner.de> writes:
> 
> > Hi Ben,
> > 
> > Am Donnerstag, den 22.03.2018, 19:59 -0400 schrieb Ben Gamari:
> > > Does anyone object to accepting the simple approach as suggested by
> > > Joachim?
> > 
> > I think you can go ahead with this one.
> > 
> 
> Sounds good. Let's accept.

I guess someone (maybe you as the shepherd) needs to either update the
proposal with the results from this discussion before you merge it, or
you need to request this from the author.

Cheers,
Joachim

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

From simonpj at microsoft.com  Mon Apr 16 14:42:51 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 16 Apr 2018 14:42:51 +0000
Subject: [ghc-steering-committee] DH quantifiers (#102),
 Recommendation: accept
In-Reply-To: <AM5PR83MB0163E24C5743B35C51EFC09CADAC0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <1519400339.28221.25.camel@joachim-breitner.de>
 <CAGK9nuoHsajv_SFnMTea1nxpdivMaSEPOSuXkRUBu3a_0rsCbw@mail.gmail.com>
 <32A4865D-5D1A-4B90-9FD3-7BB1356E0626@cs.brynmawr.edu>
 <AM5PR83MB0163E24C5743B35C51EFC09CADAC0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <AM5PR83MB016327A016523110BFAEFB4EADB00@AM5PR83MB0163.EURPRD83.prod.outlook.com>

I said three weeks ago:

|  So I suggest that we accept #54 and #81, and simply punt on #102.

Richard agreed to punt on #102.

Are we agreed to accept these two?
 * #54 https://github.com/ghc-proposals/ghc-proposals/pull/54
 * #81 https://github.com/ghc-proposals/ghc-proposals/pull/81

RSVP.  I'd really like to unglue this log-jam!

Simon

PS: Richard hasn't yet formally submitted #54, but will do so later today


|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Simon Peyton Jones
|  Sent: 27 March 2018 23:11
|  To: Richard Eisenberg <rae at cs.brynmawr.edu>; 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] DH quantifiers (#102),
|  Recommendation: accept
|  
|  I'm on a train, and don't have access to the proposals, but here's are
|  some thoughts:
|  
|  * #54 is about letting users write kind signatures for type
|  constructors,
|    just as they can write type signatures for term variables.  It's
|    amazing we have lasted so long without this ability, but it's really
|    really hurting us.   I feel strongly that we should fix this: we
|  need
|    SOME way to write a kind signature for a type constructor.
|  
|  * To write such a kind signature we need something like the
|      T :: forall a b -> blah syntax, to indicate which of T's
|    arguments should be written positionally (like the Int in Proxy Int)
|    and which are hidden (like the * in Proxy Int).  By hook or by
|    crook we must be able to express this.  And that's #81.
|  
|  * The worry with #81 was whether it would be painting us into a
|    corner.  Hence #102.  But I regard #102 as an existence proof that
|    the corner has an exit, not as something we should espouse now.
|    (Tell me if you disagree Richard.)  It is far off our radar, and
|    premature to make a commitment.
|  
|    Richard: you could add the analysis in your email about "why 12"
|    to the proposal.
|  
|  So I suggest that we accept #54 and #81, and simply punt on #102.
|  
|  Simon
|  
|  | -----Original Message-----
|  | From: ghc-steering-committee <ghc-steering-committee-
|  | bounces at haskell.org> On Behalf Of Richard Eisenberg
|  | Sent: 27 March 2018 04:36
|  | 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] DH quantifiers (#102),
|  | Recommendation: accept
|  |
|  | I'd like to restart this thread, both as the Grand Poobah of
|  Dependent
|  | Haskell and because Proposal #102 (this one) is holding up #81 (the
|  | `forall x y z ->` syntax), which is, in turn, holding up #54 (a plan
|  | to eliminate the need for CUSKs), which is implicated in quite a few
|  bugs.
|  |
|  | I think Iavor makes some good criticisms below, which I'll address
|  | individually:
|  |
|  | > On Feb 23, 2018, at 12:12 PM, Iavor Diatchki
|  | <iavor.diatchki at gmail.com> wrote:
|  | >
|  | >     * it is premature to "reserve" syntax for a future extension
|  |
|  | This is a hard one. The full implementation of dependent types in
|  | Haskell is still years away. But decisions we make now may affect
|  the
|  | eventual concrete syntax. While a ghc-proposal is ill-fitted with
|  | reserving syntax, I think Roman was right to request that #81 be
|  | considered in the context of the larger syntactic changes. Maybe the
|  | "right" answer here is for the committee to conclude that the
|  proposed
|  | syntax is generally plausible, paving the way for #81 but without
|  | making a solid commitment. On the other hand, if we can identify a
|  | better syntax for the overall design of dependent types in Haskell,
|  | that might affect the syntax used in #81/#54.
|  |
|  | >     * I am not convinced that a design with 12 quantifiers is what
|  | > I'd
|  | want to use
|  |
|  | Neither am I!
|  |
|  | For a moment, let's take the desire for dependent types to be a
|  given.
|  | (I'll address this more below.) GHC currently has 3 quantifiers
|  | (`forall a.`, `ty ->`, and `ty =>`). To preserve type erasure, we
|  need
|  | to distinguish between arguments needed at runtime and those that
|  can
|  | be erased.
|  |
|  | Coq does this through its Set-vs-Prop mechanism, where erased
|  | arguments live in their own sort. Such a route is viable for
|  Haskell,
|  | I think, but I've never been much enamored of it, personally. For
|  | example, the Nat in a vector type really can be erased, while Nats
|  in
|  | many other places can't be, and it seems a shame to need two
|  different
|  | Nat types to pull off this dichotomy.
|  |
|  | Agda uses the term "irrelevant" to describe type indices that are
|  | ignored during type equality checks. This is related to the type
|  | erasure property, but it's not quite the same thing. It's unclear to
|  | me what types Agda can erase, and I don't think Agda gives any solid
|  | guarantees as to erasure. (As a language aiming for performance,
|  | Haskell needs to provide such a guarantee.)
|  |
|  | Idris does whole-program analysis to determine erasability. I can't
|  | imagine this scales well.
|  |
|  | The choice I've made in the design of Dependent Haskell is to have
|  the
|  | user choose whether to keep an argument or not, leading to the
|  | forall/foreach distinction. This brings us from 3 quantifiers to 4.
|  In
|  | truth, 4 is enough to power dependent types! But read on.
|  |
|  | All dependently typed languages give a facility for the user to
|  | control the visibility of arguments. If we want to do the same, we
|  go
|  | from 4 quantifiers to 6. (We don't go to 8 because the original ->
|  and
|  | => already differ in visibility.) Note, though, that Coq doesn't
|  | consider visibility as a feature of a type, instead using,
|  | essentially, pragmas to control visibility. This has some benefits
|  | (higher-order usages of functions can't fall over based on
|  | visibility), but it doesn't seem well-suited for Haskell.
|  |
|  | Quite separately, we also will likely want to allow currying in
|  type-
|  | level operations. Partially-applied type families are currently
|  | forbidden because doing so would wreak havoc with type inference.
|  | (Imagine if we're unifying `m a` with `Maybe Int` but that `m` might
|  | unify with a type family `Id`!) The solution I've proposed here is a
|  | notion of *matchability*, described in Section 4.2.4 of my thesis
|  | (which can be read independently of the rest of it). A function is
|  | *matchable* iff it is generative and injective -- in other words, if
|  | equalities over function applications can be decomposed. When some
|  | functions (like Maybe and Either Int) are matchable and some (like
|  Id
|  | and any other type
|  | family) are not, then type inference can decompose matchable things
|  | and not decompose unmatchable things. It turns out that all previous
|  6
|  | quantifiers are useful in both the matchable and unmatchable
|  | varieties, bringing us to 12.
|  |
|  | Note that other dependently typed languages don't have a notion of
|  | matchability. They generally also don't have injective type
|  | constructors (you can't derive (a ~ b) from (Maybe a ~ Maybe b)) and
|  | don't have the guess-free type inference Haskell has. Instead, those
|  | languages generally rely on higher-order unification, which is a
|  | best-guess algorithm (as I understand it). GHC has stayed away from
|  | guessing. We might imagine a future for GHC that allows
|  | partially-applied type functions without using matchability, but I
|  | conjecture that any such future would also have to offer weaker
|  | guarantees for the predictability and stability of type inference.
|  It
|  | might be a fruitful debate to see which is better -- stable type
|  inference or fewer quantifiers.
|  |
|  | My bottom line: I don't like the 12 quantifiers either. And
|  dependent
|  | types require really only 1 new one. Two more come along for the
|  | convenience of invisible arguments. And then we have to double for
|  | matchability. (Note that matchability can be considered quite
|  | orthogonally to dependent types -- it has even been proposed
|  | separately in #52.) Perhaps I've overshot in the design here and
|  some
|  | healthy debate here can whittle the number down.
|  |
|  | >     * I am not convinced about the utility of the "dependent
|  haskell"
|  | extension in the first place.
|  |
|  | This is the bigger question. Chapter 3 of my thesis lays out some
|  | motivation for dependent types, as does Chapter 8 of Adam Gundry's.
|  | Historically, every feature (fundeps, type families, GADTs, kind
|  | polymorphism, higher-rank types, type applications) that has moved
|  GHC
|  | closer to having dependent types has been eagerly adopted. I've
|  heard
|  | some push-back over the years about this, but the biggest complaint
|  | I've gotten is around termination: people don't want GHC to reject
|  | non- terminating functions. When I explain that doing so has never
|  | been part of the plan, then generally the objection is retracted.
|  |
|  | What are the downsides of adding dependent types?
|  |
|  | - The language becomes more complicated. Haskell already has a
|  | reputation of being impossible to learn, and if dependent types
|  appear
|  | everywhere, this reputation will be reinforced, to the language's
|  | detriment. I am indeed worried about this. Care will have to be
|  taken
|  | by library authors to make dependent types an opt-in experience.
|  |
|  | - Error messages might worsen. I'm actually not terribly worried
|  about
|  | this, as I believe clever engineering can avoid it. Other than
|  #11198
|  | (which is now fixed), there has not been a degradation in error
|  | messages from -XTypeInType. Errors still use the words "kind" and
|  | "type" to mean different things! Even forgetting about dependent
|  | types, I think GHC's error messages need an overhaul, basically to
|  become more like Idris's.
|  | (That is, interactive.) Especially if we have interactivity in error
|  | messages, then there are even more ways to mitigate the potential
|  | trouble of dependent types. Note that Haskell's tradition of
|  language
|  | extensions help us here: if a user makes a type error in simple code
|  | -- but that code might have a meaning in a dependently typed setting
|  | -- then we can use the presence or absence of language extensions to
|  | tailor the message. (In particular, we might want to be conservative
|  | in recommending that the user enable -XDependentTypes.)
|  |
|  | - The abstraction will sometimes leak. The most glaring example of
|  | this is when the type of ($) started muttering about levity
|  polymorphism.
|  | That was terrible! I do think that, with care, we can avoid this, by
|  | continuing to use compiler flags to tailor output and/or adding
|  | interactivity to GHC's output.
|  |
|  | - The implementation becomes more complicated. Well, yes, though
|  | perhaps we'll lose some duplication once GHC no longer has separate
|  | Expr and Type types.
|  |
|  | -----------------------------------------
|  |
|  | What to do next? If others on the committee are worried about the
|  | desire/utility of dependent types, it might be good to seek input
|  from
|  | the community. Beyond that, I'll reiterate 4 possible actions we
|  might
|  | take on #102, specifically:
|  |
|  | 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.
|  |
|  | Looking forward to seeing your thoughts on this, Richard
|  | _______________________________________________
|  | 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 rae at cs.brynmawr.edu  Mon Apr 16 15:55:22 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 16 Apr 2018 11:55:22 -0400
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <1519235522.1437.7.camel@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>
 <AM5PR83MB0163B7281F6CDCEF0A8DF659ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nupKg49otamTV2nUrnoPg4MiF4uzy4=jefiywn+5O6A+wg@mail.gmail.com>
 <1519235522.1437.7.camel@joachim-breitner.de>
Message-ID: <0DF70AB5-BC42-4C0E-BBEC-7EF2635F269E@cs.brynmawr.edu>

I'd like to get this conversation going again so that we can have some closure here.

To remind everyone: this is about proposal #83, where -XTypeInType is folded into -XPolyKinds and -XDataKinds. The only point of contention (both on GitHub and here in committee) is what to do about *.

The proposal currently describes a mechanism, -XStarIsType, for how to deal with this. Briefly, when the extension is on (as it is by default), * means Type. When it's off, * is parsed as a normal binary infix operator. That mechanism has not gotten rave reviews in this thread, but no alternative has, either.

One slightly separate question is what to print. The proposal currently suggests to print Type. There was concern in this thread that it would be printed fully-qualified, but I like Joachim's suggestion in the last known email in this thread to special-case printing of Type; even if it's not imported, it would print as Type, not Data.Kind.Type. (Unless some other Type were in scope.) It is also easy to teach GHC to print a bespoke warning when a user writes Type when it is out of scope, telling them to import Data.Kind.

An alternative that hasn't been suggested so far is to have -XStarIsType control the pretty-printer as well as the parser. Simon PJ and I discussed this this morning, thinking it was a good idea. Upon further consideration, my preference would be to bite the bullet and just switch to printing Type always, but I'm not really against the print-*-with-XStarIsType idea.

Regardless, it would be nice to have this settled so we can get on with implementing.

Thanks!
Richard

> On Feb 21, 2018, at 12:52 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> 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/
> _______________________________________________
> 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 Apr 16 17:39:27 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 16 Apr 2018 10:39:27 -0700
Subject: [ghc-steering-committee] Please Review: Top-level kind signatures,
 Shepherd: Roman Leshchinskiy
Message-ID: <c31107d1f8f1c73ace721564c84fe86907d4fd12.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Top-level kind signatures by Richard has been proposed:
https://github.com/ghc-proposals/ghc-proposals/pull/54

I propose Roman Leshchinskiy as the shepherd, who is already
shepherding the closely related proposal #81. 

Roman, 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/20180416/8245ceb1/attachment.sig>

From mail at joachim-breitner.de  Mon Apr 16 17:46:14 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 16 Apr 2018 10:46:14 -0700
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <0DF70AB5-BC42-4C0E-BBEC-7EF2635F269E@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>
 <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>
 <1519235522.1437.7.camel@joachim-breitner.de>
 <0DF70AB5-BC42-4C0E-BBEC-7EF2635F269E@cs.brynmawr.edu>
Message-ID: <91b822a52cbdc00a80206df137fd8436781b8ee8.camel@joachim-breitner.de>

Hi,

Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:
> An alternative that hasn't been suggested so far is to have
> -XStarIsType control the pretty-printer as well as the parser. Simon
> PJ and I discussed this this morning, thinking it was a good idea.
> Upon further consideration, my preference would be to bite the bullet
> and just switch to printing Type always, but I'm not really against
> the print-*-with-XStarIsType idea.

I’m with Simon here. We have, I believe, precedence where error
messages are affected by the language extension in scope, so this might
satisfy the principle of least surprise, and also cause the least
contention among our users.

We can still apply this rule when `-XNoStarIsType`:

> One slightly separate question is what to print. The proposal
> currently suggests to print Type. There was concern in this thread
> that it would be printed fully-qualified, but I like Joachim's
> suggestion in the last known email in this thread to special-case
> printing of Type; even if it's not imported, it would print as Type,
> not Data.Kind.Type. (Unless some other Type were in scope.) It is
> also easy to teach GHC to print a bespoke warning when a user writes
> Type when it is out of scope, telling them to import Data.Kind.

The proposal currently does not state which modules export Type. I can
infer from the text that it is Data.Kind, but this could be made
explicit. Also, the proposal should state whether it is re-exported
from Prelude or not (I assume it is not).

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/20180416/91316910/attachment.sig>

From mail at joachim-breitner.de  Mon Apr 16 17:55:53 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 16 Apr 2018 10:55:53 -0700
Subject: [ghc-steering-committee] Please Review: Resurrect PatternSignatures,
 Shepherd: Christopher Allen
Message-ID: <bfb1ec4366694153905a7f2f320fe4328267757e.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Resurrect PatternSignatures has been proposed by me:
https://github.com/ghc-proposals/ghc-proposals/pull/119

I propose Chris Allen as the shepherd.

Chris, 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/20180416/f669a6a9/attachment.sig>

From simonpj at microsoft.com  Tue Apr 17 08:08:28 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 17 Apr 2018 08:08:28 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type (#83)
Message-ID: <VI1PR83MB01740E4971B2BBAF2BAB2323ADB70@VI1PR83MB0174.EURPRD83.prod.outlook.com>

I think we all agree that we should collapse -XPolyKinds and -XTypeInType.  The only issue is what to do about *.  No solution is perfect: let's get this decided!

The status quo is terrible!

* With -XTypeInType,
    - '*' means Type iff '*' is imported from Data.Kind
    - '*' has no special meaning otherwise; that is, it's an
      ordinary infix operator, and is used as such in TypeLits
    - Ambiguity error if it is in scope two ways)

* Without -XTypeInType
    - '*' means Type iff it is used in a context that syntactically
      means "this is a kind"
    - '*' has no special meaning otherwise

That is, the meaning of '*' depends both on the extension flags -- and moreover on a flag whose primary purpose is quite separate -- AND depends (in some cases) on lexical scope or (in other cases) on syntactic context.  This is a ridiculous design.


The simplest thing to do is to say
  * The meaning of '*' is controlled by a flag, -XStarIsType, that has no
    other purpose
  * -XStarIsType is on by default.  (Perhaps: switched off by -XTypeOperators.)
  * 'Type' is exported by Data.Type (or whatever) and is always available
    as an alternative to '*'.
  * When -XStarIsType is on, we print '*' in error messages whenever possible.

That is simple and explicable.  Moreover the on-by-default rule means that most existing prams that use PolyKinds will continue to work unchanged.  In effect -XStarIsType is roughly the delta between -XPolyKinds and -XTypeInType. 

Once that is in place we can think about future policy. For example

- Leave it alone
- Announce that -XStarIsType will move to off-by-default in a
  specified future GHC XX.YY,
  and emit deprecation messages for three previous releases

But let's get this done, one way or another.

Simon


|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 16 April 2018 18:46
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type
|  
|  Hi,
|  
|  Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:
|  > An alternative that hasn't been suggested so far is to have
|  > -XStarIsType control the pretty-printer as well as the parser. Simon
|  > PJ and I discussed this this morning, thinking it was a good idea.
|  > Upon further consideration, my preference would be to bite the
|  bullet
|  > and just switch to printing Type always, but I'm not really against
|  > the print-*-with-XStarIsType idea.
|  
|  I’m with Simon here. We have, I believe, precedence where error
|  messages are affected by the language extension in scope, so this
|  might satisfy the principle of least surprise, and also cause the
|  least contention among our users.
|  
|  We can still apply this rule when `-XNoStarIsType`:
|  
|  > One slightly separate question is what to print. The proposal
|  > currently suggests to print Type. There was concern in this thread
|  > that it would be printed fully-qualified, but I like Joachim's
|  > suggestion in the last known email in this thread to special-case
|  > printing of Type; even if it's not imported, it would print as Type,
|  > not Data.Kind.Type. (Unless some other Type were in scope.) It is
|  also
|  > easy to teach GHC to print a bespoke warning when a user writes Type
|  > when it is out of scope, telling them to import Data.Kind.
|  
|  The proposal currently does not state which modules export Type. I can
|  infer from the text that it is Data.Kind, but this could be made
|  explicit. Also, the proposal should state whether it is re-exported
|  from Prelude or not (I assume it is not).
|  
|  Cheers,
|  Joachim
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|    http://www.joachim-breitner.de/

From iavor.diatchki at gmail.com  Tue Apr 17 18:23:37 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 17 Apr 2018 18:23:37 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <91b822a52cbdc00a80206df137fd8436781b8ee8.camel@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>
 <AM5PR83MB0163B7281F6CDCEF0A8DF659ADCE0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <CAGK9nupKg49otamTV2nUrnoPg4MiF4uzy4=jefiywn+5O6A+wg@mail.gmail.com>
 <1519235522.1437.7.camel@joachim-breitner.de>
 <0DF70AB5-BC42-4C0E-BBEC-7EF2635F269E@cs.brynmawr.edu>
 <91b822a52cbdc00a80206df137fd8436781b8ee8.camel@joachim-breitner.de>
Message-ID: <CAGK9nuqoaGino2s-_sHj5Xw-nL7LWwGqyn-LRYAVgx5-+n+CSg@mail.gmail.com>

Hello,

I have a couple of pragmatic questions:

1.  To "fix" my code so that it is compatible with this change I need to do
the following:
    1. Whenever I have kind signatures mentioning `*`, replace `*` with
`Type`
    2. Import `Data.Kind(Type)`
    3. Resolve conflicts involving existing datatypes named `Type`.

2. If my code has all of the properties below, then it will break as soon
as this change is adopted, so I have to fix it in some way straight away:
     1. uses `*` is a binary type operator, and
     2. uses `*` in kind signatures, and
     3. uses the `PolyKinds` language extension.

3. If my code does not have the properties in (2) but uses `*` in kind
signatures, it will continue to work for 2 GHC releases, but then it will
break, so I should do (1) sometime before.

Is my understanding correct?

-Iavor









On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:
> > An alternative that hasn't been suggested so far is to have
> > -XStarIsType control the pretty-printer as well as the parser. Simon
> > PJ and I discussed this this morning, thinking it was a good idea.
> > Upon further consideration, my preference would be to bite the bullet
> > and just switch to printing Type always, but I'm not really against
> > the print-*-with-XStarIsType idea.
>
> I’m with Simon here. We have, I believe, precedence where error
> messages are affected by the language extension in scope, so this might
> satisfy the principle of least surprise, and also cause the least
> contention among our users.
>
> We can still apply this rule when `-XNoStarIsType`:
>
> > One slightly separate question is what to print. The proposal
> > currently suggests to print Type. There was concern in this thread
> > that it would be printed fully-qualified, but I like Joachim's
> > suggestion in the last known email in this thread to special-case
> > printing of Type; even if it's not imported, it would print as Type,
> > not Data.Kind.Type. (Unless some other Type were in scope.) It is
> > also easy to teach GHC to print a bespoke warning when a user writes
> > Type when it is out of scope, telling them to import Data.Kind.
>
> The proposal currently does not state which modules export Type. I can
> infer from the text that it is Data.Kind, but this could be made
> explicit. Also, the proposal should state whether it is re-exported
> from Prelude or not (I assume it is not).
>
> 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/20180417/13b1e8a1/attachment.html>

From rae at cs.brynmawr.edu  Tue Apr 17 19:21:34 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 17 Apr 2018 15:21:34 -0400
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CAGK9nuqoaGino2s-_sHj5Xw-nL7LWwGqyn-LRYAVgx5-+n+CSg@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>
 <1519235522.1437.7.camel@joachim-breitner.de>
 <0DF70AB5-BC42-4C0E-BBEC-7EF2635F269E@cs.brynmawr.edu>
 <91b822a52cbdc00a80206df137fd8436781b8ee8.camel@joachim-breitner.de>
 <CAGK9nuqoaGino2s-_sHj5Xw-nL7LWwGqyn-LRYAVgx5-+n+CSg@mail.gmail.com>
Message-ID: <07C5FD0A-3146-4CC0-B58B-904ED5B533B5@cs.brynmawr.edu>

Hi Iavor,

See my answers below.

> On Apr 17, 2018, at 2:23 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello,
> 
> I have a couple of pragmatic questions:
> 
> 1.  To "fix" my code so that it is compatible with this change I need to do the following:
>     1. Whenever I have kind signatures mentioning `*`, replace `*` with `Type`
>     2. Import `Data.Kind(Type)`
>     3. Resolve conflicts involving existing datatypes named `Type`.
> 
> 2. If my code has all of the properties below, then it will break as soon as this change is adopted, so I have to fix it in some way straight away:
>      1. uses `*` is a binary type operator, and
>      2. uses `*` in kind signatures, and
>      3. uses the `PolyKinds` language extension.
> 
> 3. If my code does not have the properties in (2) but uses `*` in kind signatures, it will continue to work for 2 GHC releases, but then it will break, so I should do (1) sometime before.
> 
> Is my understanding correct?

Not quite.

First off, this proposal *does not* propose deprecating *. Earlier versions may have, but that's no longer the case. There is no concrete plan to remove * at any point in the future. Any movement to do so would be years in the future, I imagine.

In point (1), "compatible" is unclear. I think you mean "compatible forever" as opposed to "compatible today". The changes you suggest in (1) are what you would have to do if we ever decide to deprecate *.

For point (2), the conditions are slightly different than what you write. They should be
 a. enables -XTypeOperators
 b. uses `*` in kind signatures
Modules that have these features will have to make an immediate change. They could either do the changes under your point (1) or enable -XStarIsType.

The only part of this proposal that mentions something that will happen in 2 releases is that -XTypeOperators will stop implying -XNoStarIsType in two releases. That particular aspect of this is up for debate, of course.

Richard


> 
> -Iavor
>        
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:
> > An alternative that hasn't been suggested so far is to have
> > -XStarIsType control the pretty-printer as well as the parser. Simon
> > PJ and I discussed this this morning, thinking it was a good idea.
> > Upon further consideration, my preference would be to bite the bullet
> > and just switch to printing Type always, but I'm not really against
> > the print-*-with-XStarIsType idea.
> 
> I’m with Simon here. We have, I believe, precedence where error
> messages are affected by the language extension in scope, so this might
> satisfy the principle of least surprise, and also cause the least
> contention among our users.
> 
> We can still apply this rule when `-XNoStarIsType`:
> 
> > One slightly separate question is what to print. The proposal
> > currently suggests to print Type. There was concern in this thread
> > that it would be printed fully-qualified, but I like Joachim's
> > suggestion in the last known email in this thread to special-case
> > printing of Type; even if it's not imported, it would print as Type,
> > not Data.Kind.Type. (Unless some other Type were in scope.) It is
> > also easy to teach GHC to print a bespoke warning when a user writes
> > Type when it is out of scope, telling them to import Data.Kind.
> 
> The proposal currently does not state which modules export Type. I can
> infer from the text that it is Data.Kind, but this could be made
> explicit. Also, the proposal should state whether it is re-exported
> from Prelude or not (I assume it is not).
> 
> Cheers,
> Joachim
> 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> _______________________________________________
> 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/20180417/3adbe57d/attachment.html>

From simonpj at microsoft.com  Tue Apr 17 23:09:11 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 17 Apr 2018 23:09:11 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <07C5FD0A-3146-4CC0-B58B-904ED5B533B5@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>
 <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>
 <1519235522.1437.7.camel@joachim-breitner.de>
 <0DF70AB5-BC42-4C0E-BBEC-7EF2635F269E@cs.brynmawr.edu>
 <91b822a52cbdc00a80206df137fd8436781b8ee8.camel@joachim-breitner.de>
 <CAGK9nuqoaGino2s-_sHj5Xw-nL7LWwGqyn-LRYAVgx5-+n+CSg@mail.gmail.com>
 <07C5FD0A-3146-4CC0-B58B-904ED5B533B5@cs.brynmawr.edu>
Message-ID: <AM5PR83MB016392D1303C4DAE3A45DBE7ADB70@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Would it be worth revising the proposal to incorporate the thinking in this thread, including the answers to Iavor’s questions?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 17 April 2018 20:22
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

Hi Iavor,

See my answers below.


On Apr 17, 2018, at 2:23 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,

I have a couple of pragmatic questions:

1.  To "fix" my code so that it is compatible with this change I need to do the following:
    1. Whenever I have kind signatures mentioning `*`, replace `*` with `Type`
    2. Import `Data.Kind(Type)`
    3. Resolve conflicts involving existing datatypes named `Type`.

2. If my code has all of the properties below, then it will break as soon as this change is adopted, so I have to fix it in some way straight away:
     1. uses `*` is a binary type operator, and
     2. uses `*` in kind signatures, and
     3. uses the `PolyKinds` language extension.

3. If my code does not have the properties in (2) but uses `*` in kind signatures, it will continue to work for 2 GHC releases, but then it will break, so I should do (1) sometime before.

Is my understanding correct?

Not quite.

First off, this proposal *does not* propose deprecating *. Earlier versions may have, but that's no longer the case. There is no concrete plan to remove * at any point in the future. Any movement to do so would be years in the future, I imagine.

In point (1), "compatible" is unclear. I think you mean "compatible forever" as opposed to "compatible today". The changes you suggest in (1) are what you would have to do if we ever decide to deprecate *.

For point (2), the conditions are slightly different than what you write. They should be
 a. enables -XTypeOperators
 b. uses `*` in kind signatures
Modules that have these features will have to make an immediate change. They could either do the changes under your point (1) or enable -XStarIsType.

The only part of this proposal that mentions something that will happen in 2 releases is that -XTypeOperators will stop implying -XNoStarIsType in two releases. That particular aspect of this is up for debate, of course.

Richard




-Iavor









On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:
> An alternative that hasn't been suggested so far is to have
> -XStarIsType control the pretty-printer as well as the parser. Simon
> PJ and I discussed this this morning, thinking it was a good idea.
> Upon further consideration, my preference would be to bite the bullet
> and just switch to printing Type always, but I'm not really against
> the print-*-with-XStarIsType idea.

I’m with Simon here. We have, I believe, precedence where error
messages are affected by the language extension in scope, so this might
satisfy the principle of least surprise, and also cause the least
contention among our users.

We can still apply this rule when `-XNoStarIsType`:

> One slightly separate question is what to print. The proposal
> currently suggests to print Type. There was concern in this thread
> that it would be printed fully-qualified, but I like Joachim's
> suggestion in the last known email in this thread to special-case
> printing of Type; even if it's not imported, it would print as Type,
> not Data.Kind.Type. (Unless some other Type were in scope.) It is
> also easy to teach GHC to print a bespoke warning when a user writes
> Type when it is out of scope, telling them to import Data.Kind.

The proposal currently does not state which modules export Type. I can
infer from the text that it is Data.Kind, but this could be made
explicit. Also, the proposal should state whether it is re-exported
from Prelude or not (I assume it is not).

Cheers,
Joachim

--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at 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
_______________________________________________
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/20180417/b00367aa/attachment-0001.html>

From rae at cs.brynmawr.edu  Wed Apr 18 01:57:53 2018
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Tue, 17 Apr 2018 21:57:53 -0400
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <AM5PR83MB016392D1303C4DAE3A45DBE7ADB70@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>
 <CAGK9nupKg49otamTV2nUrnoPg4MiF4uzy4=jefiywn+5O6A+wg@mail.gmail.com>
 <1519235522.1437.7.camel@joachim-breitner.de>
 <0DF70AB5-BC42-4C0E-BBEC-7EF2635F269E@cs.brynmawr.edu>
 <91b822a52cbdc00a80206df137fd8436781b8ee8.camel@joachim-breitner.de>
 <CAGK9nuqoaGino2s-_sHj5Xw-nL7LWwGqyn-LRYAVgx5-+n+CSg@mail.gmail.com>
 <07C5FD0A-3146-4CC0-B58B-904ED5B533B5@cs.brynmawr.edu>
 <AM5PR83MB016392D1303C4DAE3A45DBE7ADB70@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <C8FE4BC9-ADC0-46FE-B868-55C80B5E5FC2@cs.brynmawr.edu>

Done.

> On Apr 17, 2018, at 7:09 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> Would it be worth revising the proposal to incorporate the thinking in this thread, including the answers to Iavor’s questions?
>  
> Simon
>  
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
> Sent: 17 April 2018 20:22
> 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
>  
> Hi Iavor,
>  
> See my answers below.
> 
> 
> On Apr 17, 2018, at 2:23 PM, Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
>  
> Hello,
>  
> I have a couple of pragmatic questions:
>  
> 1.  To "fix" my code so that it is compatible with this change I need to do the following:
>     1. Whenever I have kind signatures mentioning `*`, replace `*` with `Type`
>     2. Import `Data.Kind(Type)`
>     3. Resolve conflicts involving existing datatypes named `Type`.
>  
> 2. If my code has all of the properties below, then it will break as soon as this change is adopted, so I have to fix it in some way straight away:
>      1. uses `*` is a binary type operator, and
>      2. uses `*` in kind signatures, and
>      3. uses the `PolyKinds` language extension.
>  
> 3. If my code does not have the properties in (2) but uses `*` in kind signatures, it will continue to work for 2 GHC releases, but then it will break, so I should do (1) sometime before.
>  
> Is my understanding correct?
>  
> Not quite.
>  
> First off, this proposal *does not* propose deprecating *. Earlier versions may have, but that's no longer the case. There is no concrete plan to remove * at any point in the future. Any movement to do so would be years in the future, I imagine.
>  
> In point (1), "compatible" is unclear. I think you mean "compatible forever" as opposed to "compatible today". The changes you suggest in (1) are what you would have to do if we ever decide to deprecate *.
>  
> For point (2), the conditions are slightly different than what you write. They should be
>  a. enables -XTypeOperators
>  b. uses `*` in kind signatures
> Modules that have these features will have to make an immediate change. They could either do the changes under your point (1) or enable -XStarIsType.
>  
> The only part of this proposal that mentions something that will happen in 2 releases is that -XTypeOperators will stop implying -XNoStarIsType in two releases. That particular aspect of this is up for debate, of course.
>  
> Richard
>  
> 
> 
>  
> -Iavor
>        
>  
>  
>  
>  
>  
>  
>  
>  
> On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:
> > An alternative that hasn't been suggested so far is to have
> > -XStarIsType control the pretty-printer as well as the parser. Simon
> > PJ and I discussed this this morning, thinking it was a good idea.
> > Upon further consideration, my preference would be to bite the bullet
> > and just switch to printing Type always, but I'm not really against
> > the print-*-with-XStarIsType idea.
> 
> I’m with Simon here. We have, I believe, precedence where error
> messages are affected by the language extension in scope, so this might
> satisfy the principle of least surprise, and also cause the least
> contention among our users.
> 
> We can still apply this rule when `-XNoStarIsType`:
> 
> > One slightly separate question is what to print. The proposal
> > currently suggests to print Type. There was concern in this thread
> > that it would be printed fully-qualified, but I like Joachim's
> > suggestion in the last known email in this thread to special-case
> > printing of Type; even if it's not imported, it would print as Type,
> > not Data.Kind.Type. (Unless some other Type were in scope.) It is
> > also easy to teach GHC to print a bespoke warning when a user writes
> > Type when it is out of scope, telling them to import Data.Kind.
> 
> The proposal currently does not state which modules export Type. I can
> infer from the text that it is Data.Kind, but this could be made
> explicit. Also, the proposal should state whether it is re-exported
> from Prelude or not (I assume it is not).
> 
> Cheers,
> Joachim
> 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> _______________________________________________
> 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/20180417/b009b6c3/attachment.html>

From mail at joachim-breitner.de  Wed Apr 18 17:26:50 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 18 Apr 2018 10:26:50 -0700
Subject: [ghc-steering-committee]  Please Review: forall {k},
 Shepherd: Iavor Diatchki
Message-ID: <3c62f8a96e8ef20b2c762639b0074653aea883d4.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Explicit specificity (forall {k},) has been proposed by Richard:
https://github.com/ghc-proposals/ghc-proposals/pull/99

I propose Iavor Diatchki as the shepherd.

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

I suggest you make a recommendation, in a new e-mail thread, 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/20180418/975a74e7/attachment.sig>

From mail at joachim-breitner.de  Tue Apr 24 02:19:45 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Apr 2018 22:19:45 -0400
Subject: [ghc-steering-committee] Deriving via (#120), Recommendation: accept
Message-ID: <b009873da7627da212ce0be8b4fe8f5eb2fdd504.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Deriving via was proposed, by Ryan, Icelandjack and Andres,
https://github.com/ghc-proposals/ghc-proposals/pull/120
rendered at
https://github.com/Icelandjack/ghc-proposals/blob/patch-3/proposals/0000-deriving-via.rst

I’ll shepherd that myself.

The proposal adds a new deriving strategy that works like GND, but
explicitly names the other, representationally equal type whose
instance should be copied.

The proposal comes with a paper and an implementation, has been met
with great enthusiasm in the community, and I expect that our users
will do many great things with it, and all that with relatively little
theoretical and implemntational overhead.

I therefore wholeheartedly recomment that we 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/20180423/f06c342c/attachment.sig>

From mail at joachim-breitner.de  Tue Apr 24 02:27:54 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Apr 2018 22:27:54 -0400
Subject: [ghc-steering-committee] Quantified Constraints (#109).
 Recommendation: accept
In-Reply-To: <EF024DAE-E10D-4E1A-AB25-2C88FCF64D2D@cs.brynmawr.edu>
References: <EF024DAE-E10D-4E1A-AB25-2C88FCF64D2D@cs.brynmawr.edu>
Message-ID: <82db84e82f947ac13a6795075cb9a382123ad834.camel@joachim-breitner.de>

Hi,

Am Montag, den 09.04.2018, 12:39 -0400 schrieb Richard Eisenberg:
> As usual, I will take silence as agreement. I look forward to reading your comments.

we have to disappoint you; no comments. But two +1 and otherwise silent
agreement. I conclude that we have reached positive consensus.

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/20180423/101c31b0/attachment.sig>

From mail at joachim-breitner.de  Tue Apr 24 02:45:10 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Apr 2018 22:45:10 -0400
Subject: [ghc-steering-committee] Constraint vs Type: I propose
 acceptance
In-Reply-To: <AM5PR83MB016302A378294567BCB5AB96ADC10@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <AM5PR83MB016302A378294567BCB5AB96ADC10@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <5b850a83bd8d08e5effb5a08e8331213329fe61e.camel@joachim-breitner.de>

Hi,

nobody responds to this in two months. I assume that we all simply
trust Simon here?

Simon, did you get the clarifications that you wanted? Can we go ahead
and accept this?

Cheers,
Joachim

Am Montag, den 26.02.2018, 11:14 +0000 schrieb Simon Peyton Jones:
> Friends
> I propose that we support the GHC proposal “Declare Constraint is not apart from Type”
> 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
> _______________________________________________
> 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/20180423/9d70f76d/attachment.sig>

From mail at joachim-breitner.de  Tue Apr 24 02:46:38 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Apr 2018 22:46:38 -0400
Subject: [ghc-steering-committee]  Status
Message-ID: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>

Hi committee,

the proposal process has become pretty popular, and it seems we are
having trouble keeping up. There are a few proposals that needs
shepherding … so please check if you are expected to make a
recommendation or, if you have, if the discussion needs more guidance
or can be closed.

Since the last status update, we
 * were asked to review these proposals:
   - Provenance-Qualified Package Imports (Shepherd: Ben)
   - Quantified Constraints (Shepherd: Richard)
   - Kinds Without Promotion (Shepherd: Ryan)
   - DH quantifiers (Shepherd: me)
   - Top-level kind signatures (Shepherd: Roman)
   - Resurrect PatternSignatures (Shepherd: Chis)
   - forall {k} (Shepherd: Iavor)
 * got a recommendation from shepherds about:
   - :kind!! (accept)
   - Treat kind and type vars identically with `forall` (accept)
   - Binding existential type variables (reject)
   - Quantified Constraints (accept)
 * decided about the following proposals
   - :kind!! (needs revision)
   - Quantified Constraints (accept)
   - Source plugins (accept)
   - plugin recompilation avoidance
     (accepted, but proposal needs to be updated)
   - DH quantifiers (punted, now dormant)


We currently have to act on the following 14 proposals, which is
2 more than a the time of the last the last status mail.

Deriving Via
https://github.com/ghc-proposals/ghc-proposals/pull/120
Shepherd: Joachim
Status: Acceptance recommended

Resurrect PatternSignatures
https://github.com/ghc-proposals/ghc-proposals/pull/119
Shepherd: Chris
Status: Waiting for recommendation.

Provenance-Qualified Package Imports
https://github.com/ghc-proposals/ghc-proposals/pull/115
Shepherd: Ben
Status: Waiting for recommendation.

Define Kinds Without Promotion
https://github.com/ghc-proposals/ghc-proposals/pull/106
Shepherd: Ryan
Status: Waiting for recommendation.

kind and type vars
https://github.com/ghc-proposals/ghc-proposals/pull/103
Shepherd: SPJ
Status: Discussion ongoing

forall {x},
https://github.com/ghc-proposals/ghc-proposals/pull/99
Shepherd: Iavor
Status: Waiting for recommendation.

Binding existential variables
https://github.com/ghc-proposals/ghc-proposals/pull/96
Shepherd: Roman
Status: Roman recommends to reject. Very active discussion going on,
with an alternative proposal in #126.

Embrace Type-In-Type
https://github.com/ghc-proposals/ghc-proposals/pull/83
Shepherd: Iavor
Status: We made progress. Iavor, Richard, do we have consensus now?

Visible dependent quantification (TL;DR: forall k -> k -> *)
https://github.com/ghc-proposals/ghc-proposals/pull/81
Shepherd: Roman Leshchinskiy
Status: With #102 punted, discussion can and should start again.

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

Or-Patterns
https://github.com/ghc-proposals/ghc-proposals/pull/43
Shepherd: Manuel
Status: Waiting for Manuel to make a recommendation

Lazy unboxed tuples
https://github.com/ghc-proposals/ghc-proposals/pull/35
Shepherd: Ryan
Status: This is lingering since last July!

Constraint vs. Type
https://github.com/ghc-proposals/ghc-proposals/pull/32
Shepherd: Simon PJS (proposed acceptance)
Status: Simon’s proposal was met with silence. Ergo accept?

Mutable constructor fields
https://github.com/ghc-proposals/ghc-proposals/pull/8
Shepherd: Ryan Newton
Status: Inconclusive discussion that fell silent, but
not the clear consensus that I’d like. Ryan, what is the status here?


Cheers,
Joachim

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

From chak at justtesting.org  Tue Apr 24 03:42:49 2018
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 24 Apr 2018 13:42:49 +1000
Subject: [ghc-steering-committee] Constraint vs Type: I propose
	acceptance
In-Reply-To: <5b850a83bd8d08e5effb5a08e8331213329fe61e.camel@joachim-breitner.de>
References: <AM5PR83MB016302A378294567BCB5AB96ADC10@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <5b850a83bd8d08e5effb5a08e8331213329fe61e.camel@joachim-breitner.de>
Message-ID: <D372A8FC-C13D-498A-B3AA-F7BA9137EB57@justtesting.org>

Yes, that sounds right to me.

Manuel

> Am 24.04.2018 um 12:45 schrieb Joachim Breitner <mail at joachim-breitner.de>:
> 
> Hi,
> 
> nobody responds to this in two months. I assume that we all simply
> trust Simon here?
> 
> Simon, did you get the clarifications that you wanted? Can we go ahead
> and accept this?
> 
> Cheers,
> Joachim
> 
> Am Montag, den 26.02.2018, 11:14 +0000 schrieb Simon Peyton Jones:
>> Friends
>> I propose that we support the GHC proposal “Declare Constraint is not apart from Type”
>> 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
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> --
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180424/f0bbee07/attachment.sig>

From simonpj at microsoft.com  Tue Apr 24 20:41:12 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 24 Apr 2018 20:41:12 +0000
Subject: [ghc-steering-committee] Deriving via (#120),
 Recommendation: accept
In-Reply-To: <b009873da7627da212ce0be8b4fe8f5eb2fdd504.camel@joachim-breitner.de>
References: <b009873da7627da212ce0be8b4fe8f5eb2fdd504.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB01741E31C164DC895C5D0DD3AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>

I support this. It's a great proposal -- I wish I'd thought of it.

But I have added a comment to the main thread asking for some changes to the presentation.  And an open question about syntax.

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-
| bounces at haskell.org> On Behalf Of Joachim Breitner
| Sent: 24 April 2018 03:20
| To: ghc-steering-committee at haskell.org
| Subject: [ghc-steering-committee] Deriving via (#120), Recommendation:
| accept
| 
| Dear Committee,
| 
| this is your secretary speaking:
| 
| Deriving via was proposed, by Ryan, Icelandjack and Andres,
| https://github.com/ghc-proposals/ghc-proposals/pull/120
| rendered at
| https://github.com/Icelandjack/ghc-proposals/blob/patch-
| 3/proposals/0000-deriving-via.rst
| 
| I’ll shepherd that myself.
| 
| The proposal adds a new deriving strategy that works like GND, but
| explicitly names the other, representationally equal type whose
| instance should be copied.
| 
| The proposal comes with a paper and an implementation, has been met
| with great enthusiasm in the community, and I expect that our users
| will do many great things with it, and all that with relatively little
| theoretical and implemntational overhead.
| 
| I therefore wholeheartedly recomment that we accept this proposal.
| 
| 
| Thanks,
| Joachim
| --
| Joachim Breitner
|   mail at joachim-breitner.de
|   http://www.joachim-breitner.de/

From simonpj at microsoft.com  Tue Apr 24 20:48:12 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 24 Apr 2018 20:48:12 +0000
Subject: [ghc-steering-committee] Constraint vs Type: I propose
	acceptance
In-Reply-To: <5b850a83bd8d08e5effb5a08e8331213329fe61e.camel@joachim-breitner.de>
References: <AM5PR83MB016302A378294567BCB5AB96ADC10@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <5b850a83bd8d08e5effb5a08e8331213329fe61e.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB017436D042C325B522796729AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>

| Simon, did you get the clarifications that you wanted? Can we go ahead
| and accept this?

Yes -- let's just accept and move on.

It's a small proposal that rejects a few programs that are currently accepted, but should not be.   After discussion Richard moved a much more elaborate proposal to a historical appendix; it wasn't "obviously right" enough to pay its way.  But we may hope that in the future we will see more clearly, and so this proposal is deliberately a minimal holding position.

But the present situation is outright wrong, so there's a net step forward.

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-
| bounces at haskell.org> On Behalf Of Joachim Breitner
| Sent: 24 April 2018 03:45
| To: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] Constraint vs Type: I propose
| acceptance
| 
| Hi,
| 
| nobody responds to this in two months. I assume that we all simply
| trust Simon here?
| 
| Simon, did you get the clarifications that you wanted? Can we go ahead
| and accept this?
| 
| Cheers,
| Joachim
| 
| Am Montag, den 26.02.2018, 11:14 +0000 schrieb Simon Peyton Jones:
| > Friends
| > I propose that we support the GHC proposal “Declare Constraint is not
| apart from Type”
| > 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
| > _______________________________________________
| > 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/

From simonpj at microsoft.com  Tue Apr 24 20:53:56 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 24 Apr 2018 20:53:56 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>

What about #83: Embrace Type:Type

I proposed acceptance in my email of 17th April (attached), but no one has responded.

I've added the payload of the email to the Github trail as well.

Let's get this done.  Do we even have a shepherd?

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-
| bounces at haskell.org> On Behalf Of Joachim Breitner
| Sent: 24 April 2018 03:47
| To: ghc-steering-committee at haskell.org
| Subject: [ghc-steering-committee] Status
| 
| Hi committee,
| 
| the proposal process has become pretty popular, and it seems we are
| having trouble keeping up. There are a few proposals that needs
| shepherding … so please check if you are expected to make a
| recommendation or, if you have, if the discussion needs more guidance
| or can be closed.
| 
| Since the last status update, we
|  * were asked to review these proposals:
|    - Provenance-Qualified Package Imports (Shepherd: Ben)
|    - Quantified Constraints (Shepherd: Richard)
|    - Kinds Without Promotion (Shepherd: Ryan)
|    - DH quantifiers (Shepherd: me)
|    - Top-level kind signatures (Shepherd: Roman)
|    - Resurrect PatternSignatures (Shepherd: Chis)
|    - forall {k} (Shepherd: Iavor)
|  * got a recommendation from shepherds about:
|    - :kind!! (accept)
|    - Treat kind and type vars identically with `forall` (accept)
|    - Binding existential type variables (reject)
|    - Quantified Constraints (accept)
|  * decided about the following proposals
|    - :kind!! (needs revision)
|    - Quantified Constraints (accept)
|    - Source plugins (accept)
|    - plugin recompilation avoidance
|      (accepted, but proposal needs to be updated)
|    - DH quantifiers (punted, now dormant)
| 
| 
| We currently have to act on the following 14 proposals, which is
| 2 more than a the time of the last the last status mail.
| 
| Deriving Via
| https://github.com/ghc-proposals/ghc-proposals/pull/120
| Shepherd: Joachim
| Status: Acceptance recommended
| 
| Resurrect PatternSignatures
| https://github.com/ghc-proposals/ghc-proposals/pull/119
| Shepherd: Chris
| Status: Waiting for recommendation.
| 
| Provenance-Qualified Package Imports
| https://github.com/ghc-proposals/ghc-proposals/pull/115
| Shepherd: Ben
| Status: Waiting for recommendation.
| 
| Define Kinds Without Promotion
| https://github.com/ghc-proposals/ghc-proposals/pull/106
| Shepherd: Ryan
| Status: Waiting for recommendation.
| 
| kind and type vars
| https://github.com/ghc-proposals/ghc-proposals/pull/103
| Shepherd: SPJ
| Status: Discussion ongoing
| 
| forall {x},
| https://github.com/ghc-proposals/ghc-proposals/pull/99
| Shepherd: Iavor
| Status: Waiting for recommendation.
| 
| Binding existential variables
| https://github.com/ghc-proposals/ghc-proposals/pull/96
| Shepherd: Roman
| Status: Roman recommends to reject. Very active discussion going on,
| with an alternative proposal in #126.
| 
| Embrace Type-In-Type
| https://github.com/ghc-proposals/ghc-proposals/pull/83
| Shepherd: Iavor
| Status: We made progress. Iavor, Richard, do we have consensus now?
| 
| Visible dependent quantification (TL;DR: forall k -> k -> *)
| https://github.com/ghc-proposals/ghc-proposals/pull/81
| Shepherd: Roman Leshchinskiy
| Status: With #102 punted, discussion can and should start again.
| 
| Top-level kinds signatures
| https://github.com/ghc-proposals/ghc-proposals/pull/54
| Shepherd: Roman Leshchinskiy
| Status: Waiting for recommendation.
| 
| Or-Patterns
| https://github.com/ghc-proposals/ghc-proposals/pull/43
| Shepherd: Manuel
| Status: Waiting for Manuel to make a recommendation
| 
| Lazy unboxed tuples
| https://github.com/ghc-proposals/ghc-proposals/pull/35
| Shepherd: Ryan
| Status: This is lingering since last July!
| 
| Constraint vs. Type
| https://github.com/ghc-proposals/ghc-proposals/pull/32
| Shepherd: Simon PJS (proposed acceptance)
| Status: Simon’s proposal was met with silence. Ergo accept?
| 
| Mutable constructor fields
| https://github.com/ghc-proposals/ghc-proposals/pull/8
| Shepherd: Ryan Newton
| Status: Inconclusive discussion that fell silent, but
| not the clear consensus that I’d like. Ryan, what is the status here?
| 
| 
| Cheers,
| Joachim
| 
| --
| Joachim Breitner
|   mail at joachim-breitner.de
|   http://www.joachim-breitner.de/
-------------- next part --------------
An embedded message was scrubbed...
From: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type (#83)
Date: Tue, 17 Apr 2018 08:08:28 +0000
Size: 12414
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180424/0295fb96/attachment-0001.mht>

From simonpj at microsoft.com  Tue Apr 24 20:58:12 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 24 Apr 2018 20:58:12 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB017460F0DA23AC89AE4DBB06AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>

What about

 * #54 https://github.com/ghc-proposals/ghc-proposals/pull/54
   Top-level kind signatures (instead of CUSKs)

 * #81 https://github.com/ghc-proposals/ghc-proposals/pull/81
   Syntax for visible dependent quantification

I have twice proposed acceptance, but no one has replied.

I think Roman is shepherd for #54, but #81 seems to be lost. Who is shepherding that?

I'd love to get these two done.

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-
| bounces at haskell.org> On Behalf Of Joachim Breitner
| Sent: 24 April 2018 03:47
| To: ghc-steering-committee at haskell.org
| Subject: [ghc-steering-committee] Status
| 
| Hi committee,
| 
| the proposal process has become pretty popular, and it seems we are
| having trouble keeping up. There are a few proposals that needs
| shepherding … so please check if you are expected to make a
| recommendation or, if you have, if the discussion needs more guidance
| or can be closed.
| 
| Since the last status update, we
|  * were asked to review these proposals:
|    - Provenance-Qualified Package Imports (Shepherd: Ben)
|    - Quantified Constraints (Shepherd: Richard)
|    - Kinds Without Promotion (Shepherd: Ryan)
|    - DH quantifiers (Shepherd: me)
|    - Top-level kind signatures (Shepherd: Roman)
|    - Resurrect PatternSignatures (Shepherd: Chis)
|    - forall {k} (Shepherd: Iavor)
|  * got a recommendation from shepherds about:
|    - :kind!! (accept)
|    - Treat kind and type vars identically with `forall` (accept)
|    - Binding existential type variables (reject)
|    - Quantified Constraints (accept)
|  * decided about the following proposals
|    - :kind!! (needs revision)
|    - Quantified Constraints (accept)
|    - Source plugins (accept)
|    - plugin recompilation avoidance
|      (accepted, but proposal needs to be updated)
|    - DH quantifiers (punted, now dormant)
| 
| 
| We currently have to act on the following 14 proposals, which is
| 2 more than a the time of the last the last status mail.
| 
| Deriving Via
| https://github.com/ghc-proposals/ghc-proposals/pull/120
| Shepherd: Joachim
| Status: Acceptance recommended
| 
| Resurrect PatternSignatures
| https://github.com/ghc-proposals/ghc-proposals/pull/119
| Shepherd: Chris
| Status: Waiting for recommendation.
| 
| Provenance-Qualified Package Imports
| https://github.com/ghc-proposals/ghc-proposals/pull/115
| Shepherd: Ben
| Status: Waiting for recommendation.
| 
| Define Kinds Without Promotion
| https://github.com/ghc-proposals/ghc-proposals/pull/106
| Shepherd: Ryan
| Status: Waiting for recommendation.
| 
| kind and type vars
| https://github.com/ghc-proposals/ghc-proposals/pull/103
| Shepherd: SPJ
| Status: Discussion ongoing
| 
| forall {x},
| https://github.com/ghc-proposals/ghc-proposals/pull/99
| Shepherd: Iavor
| Status: Waiting for recommendation.
| 
| Binding existential variables
| https://github.com/ghc-proposals/ghc-proposals/pull/96
| Shepherd: Roman
| Status: Roman recommends to reject. Very active discussion going on,
| with an alternative proposal in #126.
| 
| Embrace Type-In-Type
| https://github.com/ghc-proposals/ghc-proposals/pull/83
| Shepherd: Iavor
| Status: We made progress. Iavor, Richard, do we have consensus now?
| 
| Visible dependent quantification (TL;DR: forall k -> k -> *)
| https://github.com/ghc-proposals/ghc-proposals/pull/81
| Shepherd: Roman Leshchinskiy
| Status: With #102 punted, discussion can and should start again.
| 
| Top-level kinds signatures
| https://github.com/ghc-proposals/ghc-proposals/pull/54
| Shepherd: Roman Leshchinskiy
| Status: Waiting for recommendation.
| 
| Or-Patterns
| https://github.com/ghc-proposals/ghc-proposals/pull/43
| Shepherd: Manuel
| Status: Waiting for Manuel to make a recommendation
| 
| Lazy unboxed tuples
| https://github.com/ghc-proposals/ghc-proposals/pull/35
| Shepherd: Ryan
| Status: This is lingering since last July!
| 
| Constraint vs. Type
| https://github.com/ghc-proposals/ghc-proposals/pull/32
| Shepherd: Simon PJS (proposed acceptance)
| Status: Simon’s proposal was met with silence. Ergo accept?
| 
| Mutable constructor fields
| https://github.com/ghc-proposals/ghc-proposals/pull/8
| Shepherd: Ryan Newton
| Status: Inconclusive discussion that fell silent, but
| not the clear consensus that I’d like. Ryan, what is the status here?
| 
| 
| Cheers,
| Joachim
| 
| --
| Joachim Breitner
|   mail at joachim-breitner.de
|   http://www.joachim-breitner.de/
-------------- next part --------------
An embedded message was scrubbed...
From: Simon Peyton Jones <simonpj at microsoft.com>
Subject: RE: [ghc-steering-committee] DH quantifiers (#102), Recommendation: accept
Date: Mon, 16 Apr 2018 14:42:51 +0000
Size: 20376
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180424/8bb2c6b0/attachment-0001.mht>

From mail at joachim-breitner.de  Tue Apr 24 21:09:21 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Apr 2018 17:09:21 -0400
Subject: [ghc-steering-committee] Status
In-Reply-To: <VI1PR83MB017460F0DA23AC89AE4DBB06AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB017460F0DA23AC89AE4DBB06AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
Message-ID: <83cbace60e828c2c80a759e3b23ab0cbcec97e2d.camel@joachim-breitner.de>

Hi,

if you scroll down my mail you’ll see that #54 is waiting for a
recommendation by Roman, and #81 was stalled due to #102, and we can
now pick that one up again.

Cheers,
Joachim

Am Dienstag, den 24.04.2018, 20:58 +0000 schrieb Simon Peyton Jones:
> What about
> 
>  * #54 https://github.com/ghc-proposals/ghc-proposals/pull/54
>    Top-level kind signatures (instead of CUSKs)
> 
>  * #81 https://github.com/ghc-proposals/ghc-proposals/pull/81
>    Syntax for visible dependent quantification
> 
> I have twice proposed acceptance, but no one has replied.
> 
> I think Roman is shepherd for #54, but #81 seems to be lost. Who is shepherding that?
> 
> I'd love to get these two done.
> 
> Simon
> 
> > -----Original Message-----
> > From: ghc-steering-committee <ghc-steering-committee-
> > bounces at haskell.org> On Behalf Of Joachim Breitner
> > Sent: 24 April 2018 03:47
> > To: ghc-steering-committee at haskell.org
> > Subject: [ghc-steering-committee] Status
> > 
> > Hi committee,
> > 
> > the proposal process has become pretty popular, and it seems we are
> > having trouble keeping up. There are a few proposals that needs
> > shepherding … so please check if you are expected to make a
> > recommendation or, if you have, if the discussion needs more guidance
> > or can be closed.
> > 
> > Since the last status update, we
> >  * were asked to review these proposals:
> >    - Provenance-Qualified Package Imports (Shepherd: Ben)
> >    - Quantified Constraints (Shepherd: Richard)
> >    - Kinds Without Promotion (Shepherd: Ryan)
> >    - DH quantifiers (Shepherd: me)
> >    - Top-level kind signatures (Shepherd: Roman)
> >    - Resurrect PatternSignatures (Shepherd: Chis)
> >    - forall {k} (Shepherd: Iavor)
> >  * got a recommendation from shepherds about:
> >    - :kind!! (accept)
> >    - Treat kind and type vars identically with `forall` (accept)
> >    - Binding existential type variables (reject)
> >    - Quantified Constraints (accept)
> >  * decided about the following proposals
> >    - :kind!! (needs revision)
> >    - Quantified Constraints (accept)
> >    - Source plugins (accept)
> >    - plugin recompilation avoidance
> >      (accepted, but proposal needs to be updated)
> >    - DH quantifiers (punted, now dormant)
> > 
> > 
> > We currently have to act on the following 14 proposals, which is
> > 2 more than a the time of the last the last status mail.
> > 
> > Deriving Via
> > https://github.com/ghc-proposals/ghc-proposals/pull/120
> > Shepherd: Joachim
> > Status: Acceptance recommended
> > 
> > Resurrect PatternSignatures
> > https://github.com/ghc-proposals/ghc-proposals/pull/119
> > Shepherd: Chris
> > Status: Waiting for recommendation.
> > 
> > Provenance-Qualified Package Imports
> > https://github.com/ghc-proposals/ghc-proposals/pull/115
> > Shepherd: Ben
> > Status: Waiting for recommendation.
> > 
> > Define Kinds Without Promotion
> > https://github.com/ghc-proposals/ghc-proposals/pull/106
> > Shepherd: Ryan
> > Status: Waiting for recommendation.
> > 
> > kind and type vars
> > https://github.com/ghc-proposals/ghc-proposals/pull/103
> > Shepherd: SPJ
> > Status: Discussion ongoing
> > 
> > forall {x},
> > https://github.com/ghc-proposals/ghc-proposals/pull/99
> > Shepherd: Iavor
> > Status: Waiting for recommendation.
> > 
> > Binding existential variables
> > https://github.com/ghc-proposals/ghc-proposals/pull/96
> > Shepherd: Roman
> > Status: Roman recommends to reject. Very active discussion going on,
> > with an alternative proposal in #126.
> > 
> > Embrace Type-In-Type
> > https://github.com/ghc-proposals/ghc-proposals/pull/83
> > Shepherd: Iavor
> > Status: We made progress. Iavor, Richard, do we have consensus now?
> > 
> > Visible dependent quantification (TL;DR: forall k -> k -> *)
> > https://github.com/ghc-proposals/ghc-proposals/pull/81
> > Shepherd: Roman Leshchinskiy
> > Status: With #102 punted, discussion can and should start again.
> > 
> > Top-level kinds signatures
> > https://github.com/ghc-proposals/ghc-proposals/pull/54
> > Shepherd: Roman Leshchinskiy
> > Status: Waiting for recommendation.
> > 
> > Or-Patterns
> > https://github.com/ghc-proposals/ghc-proposals/pull/43
> > Shepherd: Manuel
> > Status: Waiting for Manuel to make a recommendation
> > 
> > Lazy unboxed tuples
> > https://github.com/ghc-proposals/ghc-proposals/pull/35
> > Shepherd: Ryan
> > Status: This is lingering since last July!
> > 
> > Constraint vs. Type
> > https://github.com/ghc-proposals/ghc-proposals/pull/32
> > Shepherd: Simon PJS (proposed acceptance)
> > Status: Simon’s proposal was met with silence. Ergo accept?
> > 
> > Mutable constructor fields
> > https://github.com/ghc-proposals/ghc-proposals/pull/8
> > Shepherd: Ryan Newton
> > Status: Inconclusive discussion that fell silent, but
> > not the clear consensus that I’d like. Ryan, what is the status here?
> > 
> > 
> > Cheers,
> > Joachim
> > 
> > --
> > Joachim Breitner
> >   mail at joachim-breitner.de
> >   http://www.joachim-breitner.de/
-- 
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/20180424/4d859f56/attachment.sig>

From mail at joachim-breitner.de  Tue Apr 24 21:12:02 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Apr 2018 17:12:02 -0400
Subject: [ghc-steering-committee] Status
In-Reply-To: <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
Message-ID: <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 24.04.2018, 20:53 +0000 schrieb Simon Peyton Jones:
> What about #83: Embrace Type:Type
> 
> I proposed acceptance in my email of 17th April (attached), but no one has responded.

that proposal saw some active discussion as recently as last Tuesday.

> Let's get this done.  Do we even have a shepherd?

Of course we do. If you scroll down the list in the status mail, I
wrote.

   Embrace Type-In-Type
   https://github.com/ghc-proposals/ghc-proposals/pull/83
Shepherd: Iavor
Status: We made progress. Iavor, Richard, do we have consensus now?


Clearly we need to wrap up a few proposals, when the status mail
becomes so large that it fails to give the overview it should give…

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/20180424/c3347688/attachment.sig>

From simonpj at microsoft.com  Tue Apr 24 21:20:46 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 24 Apr 2018 21:20:46 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB01746A5E2CFB82E9951E1FFAAD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>

| Of course we do. If you scroll down the list in the status mail, I
| wrote.

Oh, sorry, my fault... I became fixated on the initial compact list, and failed to scroll further.

I wonder if it'd be worth recording who the shepherd is somewhere easy to consult?

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-
| bounces at haskell.org> On Behalf Of Joachim Breitner
| Sent: 24 April 2018 22:12
| To: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] Status
| 
| Hi,
| 
| Am Dienstag, den 24.04.2018, 20:53 +0000 schrieb Simon Peyton Jones:
| > What about #83: Embrace Type:Type
| >
| > I proposed acceptance in my email of 17th April (attached), but no one
| has responded.
| 
| that proposal saw some active discussion as recently as last Tuesday.
| 
| > Let's get this done.  Do we even have a shepherd?
| 
| Of course we do. If you scroll down the list in the status mail, I
| wrote.
| 
|    Embrace Type-In-Type
|    https://github.com/ghc-proposals/ghc-proposals/pull/83
| Shepherd: Iavor
| Status: We made progress. Iavor, Richard, do we have consensus now?
| 
| 
| Clearly we need to wrap up a few proposals, when the status mail
| becomes so large that it fails to give the overview it should give…
| 
| Cheers,
| Joachim
| 
| --
| Joachim Breitner
|   mail at joachim-breitner.de
|   http://www.joachim-breitner.de/

From mail at joachim-breitner.de  Tue Apr 24 21:28:12 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Apr 2018 17:28:12 -0400
Subject: [ghc-steering-committee] Constraint vs Type: I propose
 acceptance
In-Reply-To: <VI1PR83MB017436D042C325B522796729AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
References: <AM5PR83MB016302A378294567BCB5AB96ADC10@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <5b850a83bd8d08e5effb5a08e8331213329fe61e.camel@joachim-breitner.de>
 <VI1PR83MB017436D042C325B522796729AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
Message-ID: <e4a48e92008c9526d2b0ab67d8a40c2b0732b9f2.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 24.04.2018, 20:48 +0000 schrieb Simon Peyton Jones:
> Yes -- let's just accept and move on.

done!

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/20180424/a2a7c1b0/attachment.sig>

From mail at joachim-breitner.de  Tue Apr 24 21:30:12 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Apr 2018 17:30:12 -0400
Subject: [ghc-steering-committee] Status
In-Reply-To: <VI1PR83MB01746A5E2CFB82E9951E1FFAAD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>
 <VI1PR83MB01746A5E2CFB82E9951E1FFAAD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
Message-ID: <0f819608b3935735af9cff43009f8c6244b795a0.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 24.04.2018, 21:20 +0000 schrieb Simon Peyton Jones:
> > Of course we do. If you scroll down the list in the status mail, I
> > wrote.
> 
> Oh, sorry, my fault... I became fixated on the initial compact list, and failed to scroll further.
> 
> I wonder if it'd be worth recording who the shepherd is somewhere easy to consult?

the shepherd is also always the assignee of the github issue, so if you
look at the top-right corner of
https://github.com/ghc-proposals/ghc-proposals/pull/83
it lists yav as the assigneee. If the Github username is unknown to you
 you can click on it to see the profile with the full name.

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/20180424/7c6ade2c/attachment.sig>

From simonpj at microsoft.com  Tue Apr 24 21:38:02 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 24 Apr 2018 21:38:02 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <0f819608b3935735af9cff43009f8c6244b795a0.camel@joachim-breitner.de>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>
 <VI1PR83MB01746A5E2CFB82E9951E1FFAAD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <0f819608b3935735af9cff43009f8c6244b795a0.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB017449175706BD36617E59F5AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>

| the shepherd is also always the assignee of the github issue, so if you
| look at the top-right corner of
| https://github.com/ghc-proposals/ghc-proposals/pull/83
| it lists yav as the assigneee. If the Github username is unknown to you
|  you can click on it to see the profile with the full name.

I didn't know that -- cool.  

Is it easy to show that info on the "list of propsoals under review" page?
https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22

Simon	

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-
| bounces at haskell.org> On Behalf Of Joachim Breitner
| Sent: 24 April 2018 22:30
| To: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] Status
| 
| Hi,
| 
| Am Dienstag, den 24.04.2018, 21:20 +0000 schrieb Simon Peyton Jones:
| > > Of course we do. If you scroll down the list in the status mail, I
| > > wrote.
| >
| > Oh, sorry, my fault... I became fixated on the initial compact list,
| and failed to scroll further.
| >
| > I wonder if it'd be worth recording who the shepherd is somewhere easy
| to consult?
| 
| the shepherd is also always the assignee of the github issue, so if you
| look at the top-right corner of
| https://github.com/ghc-proposals/ghc-proposals/pull/83
| it lists yav as the assigneee. If the Github username is unknown to you
|  you can click on it to see the profile with the full name.
| 
| Cheers,
| Joachim
| 
| --
| Joachim Breitner
|   mail at joachim-breitner.de
|   http://www.joachim-breitner.de/

From mail at joachim-breitner.de  Tue Apr 24 23:27:50 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Apr 2018 19:27:50 -0400
Subject: [ghc-steering-committee] Status
In-Reply-To: <VI1PR83MB017449175706BD36617E59F5AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>
 <VI1PR83MB01746A5E2CFB82E9951E1FFAAD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <0f819608b3935735af9cff43009f8c6244b795a0.camel@joachim-breitner.de>
 <VI1PR83MB017449175706BD36617E59F5AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
Message-ID: <FFE271D2-477E-427D-AEA2-4E127F8482CC@joachim-breitner.de>

Hi Simon,

we cannot change that table, but as it happens the picture on the far right off each row is the avatar of the assignee, i.e. the shepherd. Less useful than a name, but after a while one recognizes the usual suspects :-)

Joachim


Am 24. April 2018 17:38:02 GMT-04:00 schrieb Simon Peyton Jones <simonpj at microsoft.com>:
>| the shepherd is also always the assignee of the github issue, so if
>you
>| look at the top-right corner of
>| https://github.com/ghc-proposals/ghc-proposals/pull/83
>| it lists yav as the assigneee. If the Github username is unknown to
>you
>|  you can click on it to see the profile with the full name.
>
>I didn't know that -- cool.  
>
>Is it easy to show that info on the "list of propsoals under review"
>page?
>https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22
>
>Simon	
>
>| -----Original Message-----
>| From: ghc-steering-committee <ghc-steering-committee-
>| bounces at haskell.org> On Behalf Of Joachim Breitner
>| Sent: 24 April 2018 22:30
>| To: ghc-steering-committee at haskell.org
>| Subject: Re: [ghc-steering-committee] Status
>| 
>| Hi,
>| 
>| Am Dienstag, den 24.04.2018, 21:20 +0000 schrieb Simon Peyton Jones:
>| > > Of course we do. If you scroll down the list in the status mail,
>I
>| > > wrote.
>| >
>| > Oh, sorry, my fault... I became fixated on the initial compact
>list,
>| and failed to scroll further.
>| >
>| > I wonder if it'd be worth recording who the shepherd is somewhere
>easy
>| to consult?
>| 
>| the shepherd is also always the assignee of the github issue, so if
>you
>| look at the top-right corner of
>| https://github.com/ghc-proposals/ghc-proposals/pull/83
>| it lists yav as the assigneee. If the Github username is unknown to
>you
>|  you can click on it to see the profile with the full name.
>| 
>| Cheers,
>| Joachim
>| 
>| --
>| Joachim Breitner
>|   mail at joachim-breitner.de
>|   http://www.joachim-breitner.de/

From iavor.diatchki at gmail.com  Wed Apr 25 00:20:40 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 25 Apr 2018 00:20:40 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <C8FE4BC9-ADC0-46FE-B868-55C80B5E5FC2@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>
 <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>
 <1519235522.1437.7.camel@joachim-breitner.de>
 <0DF70AB5-BC42-4C0E-BBEC-7EF2635F269E@cs.brynmawr.edu>
 <91b822a52cbdc00a80206df137fd8436781b8ee8.camel@joachim-breitner.de>
 <CAGK9nuqoaGino2s-_sHj5Xw-nL7LWwGqyn-LRYAVgx5-+n+CSg@mail.gmail.com>
 <07C5FD0A-3146-4CC0-B58B-904ED5B533B5@cs.brynmawr.edu>
 <AM5PR83MB016392D1303C4DAE3A45DBE7ADB70@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <C8FE4BC9-ADC0-46FE-B868-55C80B5E5FC2@cs.brynmawr.edu>
Message-ID: <CAGK9nureXZNV6D8Y_Mj7sR1BHOd1mbmpfD0ptaEWUqSF8F9LbQ@mail.gmail.com>

OK, I guess we should just accept this.



On Tue, Apr 17, 2018 at 6:57 PM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> Done.
>
>
> On Apr 17, 2018, at 7:09 PM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> Would it be worth revising the proposal to incorporate the thinking in
> this thread, including the answers to Iavor’s questions?
>
> Simon
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org
> > *On Behalf Of *Richard Eisenberg
> *Sent:* 17 April 2018 20:22
> *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
>
> Hi Iavor,
>
> See my answers below.
>
>
> On Apr 17, 2018, at 2:23 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> Hello,
>
> I have a couple of pragmatic questions:
>
> 1.  To "fix" my code so that it is compatible with this change I need to
> do the following:
>     1. Whenever I have kind signatures mentioning `*`, replace `*` with
> `Type`
>     2. Import `Data.Kind(Type)`
>     3. Resolve conflicts involving existing datatypes named `Type`.
>
> 2. If my code has all of the properties below, then it will break as soon
> as this change is adopted, so I have to fix it in some way straight away:
>      1. uses `*` is a binary type operator, and
>      2. uses `*` in kind signatures, and
>      3. uses the `PolyKinds` language extension.
>
> 3. If my code does not have the properties in (2) but uses `*` in kind
> signatures, it will continue to work for 2 GHC releases, but then it will
> break, so I should do (1) sometime before.
>
> Is my understanding correct?
>
>
> Not quite.
>
> First off, this proposal *does not* propose deprecating *. Earlier
> versions may have, but that's no longer the case. There is no concrete plan
> to remove * at any point in the future. Any movement to do so would be
> years in the future, I imagine.
>
> In point (1), "compatible" is unclear. I think you mean "compatible
> forever" as opposed to "compatible today". The changes you suggest in (1)
> are what you would have to do if we ever decide to deprecate *.
>
> For point (2), the conditions are slightly different than what you write.
> They should be
>  a. enables -XTypeOperators
>  b. uses `*` in kind signatures
> Modules that have these features will have to make an immediate change.
> They could either do the changes under your point (1) or enable
> -XStarIsType.
>
> The only part of this proposal that mentions something that will happen in
> 2 releases is that -XTypeOperators will stop implying -XNoStarIsType in two
> releases. That particular aspect of this is up for debate, of course.
>
> Richard
>
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
> On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
> Hi,
>
> Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:
> > An alternative that hasn't been suggested so far is to have
> > -XStarIsType control the pretty-printer as well as the parser. Simon
> > PJ and I discussed this this morning, thinking it was a good idea.
> > Upon further consideration, my preference would be to bite the bullet
> > and just switch to printing Type always, but I'm not really against
> > the print-*-with-XStarIsType idea.
>
> I’m with Simon here. We have, I believe, precedence where error
> messages are affected by the language extension in scope, so this might
> satisfy the principle of least surprise, and also cause the least
> contention among our users.
>
> We can still apply this rule when `-XNoStarIsType`:
>
> > One slightly separate question is what to print. The proposal
> > currently suggests to print Type. There was concern in this thread
> > that it would be printed fully-qualified, but I like Joachim's
> > suggestion in the last known email in this thread to special-case
> > printing of Type; even if it's not imported, it would print as Type,
> > not Data.Kind.Type. (Unless some other Type were in scope.) It is
> > also easy to teach GHC to print a bespoke warning when a user writes
> > Type when it is out of scope, telling them to import Data.Kind.
>
> The proposal currently does not state which modules export Type. I can
> infer from the text that it is Data.Kind, but this could be made
> explicit. Also, the proposal should state whether it is re-exported
> from Prelude or not (I assume it is not).
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180425/fc7d9926/attachment-0001.html>

From iavor.diatchki at gmail.com  Wed Apr 25 00:30:07 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 25 Apr 2018 00:30:07 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <FFE271D2-477E-427D-AEA2-4E127F8482CC@joachim-breitner.de>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>
 <VI1PR83MB01746A5E2CFB82E9951E1FFAAD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <0f819608b3935735af9cff43009f8c6244b795a0.camel@joachim-breitner.de>
 <VI1PR83MB017449175706BD36617E59F5AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <FFE271D2-477E-427D-AEA2-4E127F8482CC@joachim-breitner.de>
Message-ID: <CAGK9nuph7vbz7Dn0eoKLU-m8by6qFBpPBp3XKeG4dCNQPQ6YHA@mail.gmail.com>

Hi all,

I was just trying to catch up on the GHC proposals, and I am afraid that
I've gotten a bit lost among all the e-mails in my inbox.   Given that we
have quite a bit of traffic, perhaps we should have the committee
discussions somewhere online (e.g., git-hub), as it would be quite a bit
easier to catch up if everything is one place.  Thoughts?  Perhaps, I
should be better at organizing my inbox, but I guess I'm not :-)

-Iavor



On Tue, Apr 24, 2018 at 4:28 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi Simon,
>
> we cannot change that table, but as it happens the picture on the far
> right off each row is the avatar of the assignee, i.e. the shepherd. Less
> useful than a name, but after a while one recognizes the usual suspects :-)
>
> Joachim
>
>
> Am 24. April 2018 17:38:02 GMT-04:00 schrieb Simon Peyton Jones <
> simonpj at microsoft.com>:
> >| the shepherd is also always the assignee of the github issue, so if
> >you
> >| look at the top-right corner of
> >| https://github.com/ghc-proposals/ghc-proposals/pull/83
> >| it lists yav as the assigneee. If the Github username is unknown to
> >you
> >|  you can click on it to see the profile with the full name.
> >
> >I didn't know that -- cool.
> >
> >Is it easy to show that info on the "list of propsoals under review"
> >page?
> >
> https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22
> >
> >Simon
> >
> >| -----Original Message-----
> >| From: ghc-steering-committee <ghc-steering-committee-
> >| bounces at haskell.org> On Behalf Of Joachim Breitner
> >| Sent: 24 April 2018 22:30
> >| To: ghc-steering-committee at haskell.org
> >| Subject: Re: [ghc-steering-committee] Status
> >|
> >| Hi,
> >|
> >| Am Dienstag, den 24.04.2018, 21:20 +0000 schrieb Simon Peyton Jones:
> >| > > Of course we do. If you scroll down the list in the status mail,
> >I
> >| > > wrote.
> >| >
> >| > Oh, sorry, my fault... I became fixated on the initial compact
> >list,
> >| and failed to scroll further.
> >| >
> >| > I wonder if it'd be worth recording who the shepherd is somewhere
> >easy
> >| to consult?
> >|
> >| the shepherd is also always the assignee of the github issue, so if
> >you
> >| look at the top-right corner of
> >| https://github.com/ghc-proposals/ghc-proposals/pull/83
> >| it lists yav as the assigneee. If the Github username is unknown to
> >you
> >|  you can click on it to see the profile with the full name.
> >|
> >| 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/20180425/d540a1c7/attachment.html>

From mail at joachim-breitner.de  Wed Apr 25 01:19:59 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Apr 2018 21:19:59 -0400
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CAGK9nureXZNV6D8Y_Mj7sR1BHOd1mbmpfD0ptaEWUqSF8F9LbQ@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>
 <1519235522.1437.7.camel@joachim-breitner.de>
 <0DF70AB5-BC42-4C0E-BBEC-7EF2635F269E@cs.brynmawr.edu>
 <91b822a52cbdc00a80206df137fd8436781b8ee8.camel@joachim-breitner.de>
 <CAGK9nuqoaGino2s-_sHj5Xw-nL7LWwGqyn-LRYAVgx5-+n+CSg@mail.gmail.com>
 <07C5FD0A-3146-4CC0-B58B-904ED5B533B5@cs.brynmawr.edu>
 <AM5PR83MB016392D1303C4DAE3A45DBE7ADB70@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <C8FE4BC9-ADC0-46FE-B868-55C80B5E5FC2@cs.brynmawr.edu>
 <CAGK9nureXZNV6D8Y_Mj7sR1BHOd1mbmpfD0ptaEWUqSF8F9LbQ@mail.gmail.com>
Message-ID: <a4beeb62091b1acda683b598de0d79733c7cb626.camel@joachim-breitner.de>

Am Mittwoch, den 25.04.2018, 00:20 +0000 schrieb Iavor Diatchki:
> OK, I guess we should just accept this. 

done!

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/20180424/a8a1bb6e/attachment.sig>

From mail at joachim-breitner.de  Wed Apr 25 01:24:20 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Apr 2018 21:24:20 -0400
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nuph7vbz7Dn0eoKLU-m8by6qFBpPBp3XKeG4dCNQPQ6YHA@mail.gmail.com>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>
 <VI1PR83MB01746A5E2CFB82E9951E1FFAAD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <0f819608b3935735af9cff43009f8c6244b795a0.camel@joachim-breitner.de>
 <VI1PR83MB017449175706BD36617E59F5AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <FFE271D2-477E-427D-AEA2-4E127F8482CC@joachim-breitner.de>
 <CAGK9nuph7vbz7Dn0eoKLU-m8by6qFBpPBp3XKeG4dCNQPQ6YHA@mail.gmail.com>
Message-ID: <6c04cf30e8d4226696c4cc38c128817f911b8ae8.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 25.04.2018, 00:30 +0000 schrieb Iavor Diatchki:
> I was just trying to catch up on the GHC proposals, and I am afraid
> that I've gotten a bit lost among all the e-mails in my inbox. 
>  Given that we have quite a bit of traffic, perhaps we should have
> the committee discussions somewhere online (e.g., git-hub), as it
> would be quite a bit easier to catch up if everything is one place. 
> Thoughts?  Perhaps, I should be better at organizing my inbox, but I
> guess I'm not :-)

if you just need to catch up and your mail client is not helpful
enough, then the threaded view on 
https://mail.haskell.org/pipermail/ghc-steering-committee/2018-April/thread.html
might provide a good alternative.

There was a discussion of switching from email to Github earlier this
year; see this thread:
https://mail.haskell.org/pipermail/ghc-steering-committee/2018-February/000349.html
but the conclusion of that thread is to stay with email.

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/20180424/33ef4b35/attachment.sig>

From simonpj at microsoft.com  Wed Apr 25 07:33:44 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 25 Apr 2018 07:33:44 +0000
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type
In-Reply-To: <CAGK9nureXZNV6D8Y_Mj7sR1BHOd1mbmpfD0ptaEWUqSF8F9LbQ@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>
 <1519235522.1437.7.camel@joachim-breitner.de>
 <0DF70AB5-BC42-4C0E-BBEC-7EF2635F269E@cs.brynmawr.edu>
 <91b822a52cbdc00a80206df137fd8436781b8ee8.camel@joachim-breitner.de>
 <CAGK9nuqoaGino2s-_sHj5Xw-nL7LWwGqyn-LRYAVgx5-+n+CSg@mail.gmail.com>
 <07C5FD0A-3146-4CC0-B58B-904ED5B533B5@cs.brynmawr.edu>
 <AM5PR83MB016392D1303C4DAE3A45DBE7ADB70@AM5PR83MB0163.EURPRD83.prod.outlook.com>
 <C8FE4BC9-ADC0-46FE-B868-55C80B5E5FC2@cs.brynmawr.edu>
 <CAGK9nureXZNV6D8Y_Mj7sR1BHOd1mbmpfD0ptaEWUqSF8F9LbQ@mail.gmail.com>
Message-ID: <AM5PR83MB01635E18F94B9AAFCECC6A10AD8F0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

You sound reluctant, Iavor.  ?

The point of the process is to get broad consensus for changes, and to debug them.  It is not to allow vocal people like Richard and me to push through changes that others think are misguided.

Or maybe I’m over-interpreting your short utterance 😊.

Simon

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

OK, I guess we should just accept this.



On Tue, Apr 17, 2018 at 6:57 PM Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
Done.



On Apr 17, 2018, at 7:09 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

Would it be worth revising the proposal to incorporate the thinking in this thread, including the answers to Iavor’s questions?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Richard Eisenberg
Sent: 17 April 2018 20:22
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

Hi Iavor,

See my answers below.

On Apr 17, 2018, at 2:23 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>> wrote:

Hello,

I have a couple of pragmatic questions:

1.  To "fix" my code so that it is compatible with this change I need to do the following:
    1. Whenever I have kind signatures mentioning `*`, replace `*` with `Type`
    2. Import `Data.Kind(Type)`
    3. Resolve conflicts involving existing datatypes named `Type`.

2. If my code has all of the properties below, then it will break as soon as this change is adopted, so I have to fix it in some way straight away:
     1. uses `*` is a binary type operator, and
     2. uses `*` in kind signatures, and
     3. uses the `PolyKinds` language extension.

3. If my code does not have the properties in (2) but uses `*` in kind signatures, it will continue to work for 2 GHC releases, but then it will break, so I should do (1) sometime before.

Is my understanding correct?

Not quite.

First off, this proposal *does not* propose deprecating *. Earlier versions may have, but that's no longer the case. There is no concrete plan to remove * at any point in the future. Any movement to do so would be years in the future, I imagine.

In point (1), "compatible" is unclear. I think you mean "compatible forever" as opposed to "compatible today". The changes you suggest in (1) are what you would have to do if we ever decide to deprecate *.

For point (2), the conditions are slightly different than what you write. They should be
 a. enables -XTypeOperators
 b. uses `*` in kind signatures
Modules that have these features will have to make an immediate change. They could either do the changes under your point (1) or enable -XStarIsType.

The only part of this proposal that mentions something that will happen in 2 releases is that -XTypeOperators will stop implying -XNoStarIsType in two releases. That particular aspect of this is up for debate, of course.

Richard



-Iavor









On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi,

Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:
> An alternative that hasn't been suggested so far is to have
> -XStarIsType control the pretty-printer as well as the parser. Simon
> PJ and I discussed this this morning, thinking it was a good idea.
> Upon further consideration, my preference would be to bite the bullet
> and just switch to printing Type always, but I'm not really against
> the print-*-with-XStarIsType idea.

I’m with Simon here. We have, I believe, precedence where error
messages are affected by the language extension in scope, so this might
satisfy the principle of least surprise, and also cause the least
contention among our users.

We can still apply this rule when `-XNoStarIsType`:

> One slightly separate question is what to print. The proposal
> currently suggests to print Type. There was concern in this thread
> that it would be printed fully-qualified, but I like Joachim's
> suggestion in the last known email in this thread to special-case
> printing of Type; even if it's not imported, it would print as Type,
> not Data.Kind.Type. (Unless some other Type were in scope.) It is
> also easy to teach GHC to print a bespoke warning when a user writes
> Type when it is out of scope, telling them to import Data.Kind.

The proposal currently does not state which modules export Type. I can
infer from the text that it is Data.Kind, but this could be made
explicit. Also, the proposal should state whether it is re-exported
from Prelude or not (I assume it is not).

Cheers,
Joachim

--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc3fbc3ccb9a34e49a2d808d5aa42671e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636602124533998677&sdata=jHw8yU8qzlu2KphFVYPy%2BabkbsbYmYwfzj529S8SIrI%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From simonpj at microsoft.com  Wed Apr 25 07:41:06 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 25 Apr 2018 07:41:06 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <6c04cf30e8d4226696c4cc38c128817f911b8ae8.camel@joachim-breitner.de>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>
 <VI1PR83MB01746A5E2CFB82E9951E1FFAAD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <0f819608b3935735af9cff43009f8c6244b795a0.camel@joachim-breitner.de>
 <VI1PR83MB017449175706BD36617E59F5AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <FFE271D2-477E-427D-AEA2-4E127F8482CC@joachim-breitner.de>
 <CAGK9nuph7vbz7Dn0eoKLU-m8by6qFBpPBp3XKeG4dCNQPQ6YHA@mail.gmail.com>
 <6c04cf30e8d4226696c4cc38c128817f911b8ae8.camel@joachim-breitner.de>
Message-ID: <AM5PR83MB016394878D830461C9FBD779AD8F0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Perhaps the proposal could somehow point to the committee thread (once it starts)? So that it was easy to start from one point and get to 
* The rendered proposal
* The Github thread
* The committee discussion

?

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 25 April 2018 02:24
|  To: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Status
|  
|  Hi,
|  
|  Am Mittwoch, den 25.04.2018, 00:30 +0000 schrieb Iavor Diatchki:
|  > I was just trying to catch up on the GHC proposals, and I am afraid
|  > that I've gotten a bit lost among all the e-mails in my inbox.
|  >  Given that we have quite a bit of traffic, perhaps we should have
|  the
|  > committee discussions somewhere online (e.g., git-hub), as it would
|  be
|  > quite a bit easier to catch up if everything is one place.
|  > Thoughts?  Perhaps, I should be better at organizing my inbox, but I
|  > guess I'm not :-)
|  
|  if you just need to catch up and your mail client is not helpful
|  enough, then the threaded view on
|  https://mail.haskell.org/pipermail/ghc-steering-committee/2018-
|  April/thread.html
|  might provide a good alternative.
|  
|  There was a discussion of switching from email to Github earlier this
|  year; see this thread:
|  https://mail.haskell.org/pipermail/ghc-steering-committee/2018-
|  February/000349.html
|  but the conclusion of that thread is to stay with email.
|  
|  Cheers,
|  Joachim
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|    http://www.joachim-breitner.de/

From mail at joachim-breitner.de  Wed Apr 25 14:13:40 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 25 Apr 2018 10:13:40 -0400
Subject: [ghc-steering-committee] Status
In-Reply-To: <AM5PR83MB016394878D830461C9FBD779AD8F0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>
 <VI1PR83MB01746A5E2CFB82E9951E1FFAAD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <0f819608b3935735af9cff43009f8c6244b795a0.camel@joachim-breitner.de>
 <VI1PR83MB017449175706BD36617E59F5AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <FFE271D2-477E-427D-AEA2-4E127F8482CC@joachim-breitner.de>
 <CAGK9nuph7vbz7Dn0eoKLU-m8by6qFBpPBp3XKeG4dCNQPQ6YHA@mail.gmail.com>
 <6c04cf30e8d4226696c4cc38c128817f911b8ae8.camel@joachim-breitner.de>
 <AM5PR83MB016394878D830461C9FBD779AD8F0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <8ed66c928a42378049270e33ae5c4e855e8cef21.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 25.04.2018, 07:41 +0000 schrieb Simon Peyton Jones:
> Perhaps the proposal could somehow point to the committee thread (once it starts)? So that it was easy to start from one point and get to 
> * The rendered proposal
> * The Github thread
> * The committee discussion

sure, the Shepherd (or anyone) is free to add a link to the committee
thread. All of us, as “members” of the Github repository, can edit the
text of the pull request. I am reluctant to commit to doing that
everytime and always until it is clear that there is a persistent
problem for us that is fixed that way.

A smaller improvement might be to consistently include the pull request
number in the subject of the thread that discusses it. That would
certainly make my job of aggregating the status mails easier. I will
add a note about that to the “Please review” mails. 

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/20180425/be4146f5/attachment.sig>

From simonpj at microsoft.com  Wed Apr 25 15:11:41 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 25 Apr 2018 15:11:41 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
Message-ID: <AM5PR83MB0163D80317507CE1491707A1AD8F0@AM5PR83MB0163.EURPRD83.prod.outlook.com>

Joachim

Could you possibly turn this email into a status report for the GHC-proposals process, here
https://ghc.haskell.org/trac/ghc/wiki/Status/Apr18

We produce this status report every 6 months (here they are, going back 12 year https://ghc.haskell.org/trac/ghc/wiki/Status), and it'd be the perfect place for a status report on GHC proposals.

I've started a section for that purpose; might you fill it in?

I think a lot of people would be interested.

Thanks!

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 24 April 2018 03:47
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Status
|  
|  Hi committee,
|  
|  the proposal process has become pretty popular, and it seems we are
|  having trouble keeping up. There are a few proposals that needs
|  shepherding … so please check if you are expected to make a
|  recommendation or, if you have, if the discussion needs more guidance
|  or can be closed.
|  
|  Since the last status update, we
|   * were asked to review these proposals:
|     - Provenance-Qualified Package Imports (Shepherd: Ben)
|     - Quantified Constraints (Shepherd: Richard)
|     - Kinds Without Promotion (Shepherd: Ryan)
|     - DH quantifiers (Shepherd: me)
|     - Top-level kind signatures (Shepherd: Roman)
|     - Resurrect PatternSignatures (Shepherd: Chis)
|     - forall {k} (Shepherd: Iavor)
|   * got a recommendation from shepherds about:
|     - :kind!! (accept)
|     - Treat kind and type vars identically with `forall` (accept)
|     - Binding existential type variables (reject)
|     - Quantified Constraints (accept)
|   * decided about the following proposals
|     - :kind!! (needs revision)
|     - Quantified Constraints (accept)
|     - Source plugins (accept)
|     - plugin recompilation avoidance
|       (accepted, but proposal needs to be updated)
|     - DH quantifiers (punted, now dormant)
|  
|  
|  We currently have to act on the following 14 proposals, which is
|  2 more than a the time of the last the last status mail.
|  
|  Deriving Via
|  https://github.com/ghc-proposals/ghc-proposals/pull/120
|  Shepherd: Joachim
|  Status: Acceptance recommended
|  
|  Resurrect PatternSignatures
|  https://github.com/ghc-proposals/ghc-proposals/pull/119
|  Shepherd: Chris
|  Status: Waiting for recommendation.
|  
|  Provenance-Qualified Package Imports
|  https://github.com/ghc-proposals/ghc-proposals/pull/115
|  Shepherd: Ben
|  Status: Waiting for recommendation.
|  
|  Define Kinds Without Promotion
|  https://github.com/ghc-proposals/ghc-proposals/pull/106
|  Shepherd: Ryan
|  Status: Waiting for recommendation.
|  
|  kind and type vars
|  https://github.com/ghc-proposals/ghc-proposals/pull/103
|  Shepherd: SPJ
|  Status: Discussion ongoing
|  
|  forall {x},
|  https://github.com/ghc-proposals/ghc-proposals/pull/99
|  Shepherd: Iavor
|  Status: Waiting for recommendation.
|  
|  Binding existential variables
|  https://github.com/ghc-proposals/ghc-proposals/pull/96
|  Shepherd: Roman
|  Status: Roman recommends to reject. Very active discussion going on,
|  with an alternative proposal in #126.
|  
|  Embrace Type-In-Type
|  https://github.com/ghc-proposals/ghc-proposals/pull/83
|  Shepherd: Iavor
|  Status: We made progress. Iavor, Richard, do we have consensus now?
|  
|  Visible dependent quantification (TL;DR: forall k -> k -> *)
|  https://github.com/ghc-proposals/ghc-proposals/pull/81
|  Shepherd: Roman Leshchinskiy
|  Status: With #102 punted, discussion can and should start again.
|  
|  Top-level kinds signatures
|  https://github.com/ghc-proposals/ghc-proposals/pull/54
|  Shepherd: Roman Leshchinskiy
|  Status: Waiting for recommendation.
|  
|  Or-Patterns
|  https://github.com/ghc-proposals/ghc-proposals/pull/43
|  Shepherd: Manuel
|  Status: Waiting for Manuel to make a recommendation
|  
|  Lazy unboxed tuples
|  https://github.com/ghc-proposals/ghc-proposals/pull/35
|  Shepherd: Ryan
|  Status: This is lingering since last July!
|  
|  Constraint vs. Type
|  https://github.com/ghc-proposals/ghc-proposals/pull/32
|  Shepherd: Simon PJS (proposed acceptance)
|  Status: Simon’s proposal was met with silence. Ergo accept?
|  
|  Mutable constructor fields
|  https://github.com/ghc-proposals/ghc-proposals/pull/8
|  Shepherd: Ryan Newton
|  Status: Inconclusive discussion that fell silent, but not the clear
|  consensus that I’d like. Ryan, what is the status here?
|  
|  
|  Cheers,
|  Joachim
|  
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|    http://www.joachim-breitner.de/

From mail at joachim-breitner.de  Wed Apr 25 15:42:08 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 25 Apr 2018 11:42:08 -0400
Subject: [ghc-steering-committee] Status
In-Reply-To: <AM5PR83MB0163D80317507CE1491707A1AD8F0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <AM5PR83MB0163D80317507CE1491707A1AD8F0@AM5PR83MB0163.EURPRD83.prod.outlook.com>
Message-ID: <efe341e5ff1bc2bc54ca1078cd3d47fd0ca27051.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 25.04.2018, 15:11 +0000 schrieb Simon Peyton Jones:
> Could you possibly turn this email into a status report for the GHC-proposals process, here
> https://ghc.haskell.org/trac/ghc/wiki/Status/Apr18
> 
> We produce this status report every 6 months (here they are, going back 12 year https://ghc.haskell.org/trac/ghc/wiki/Status), and it'd be the perfect place for a status report on GHC proposals.
> 
> I've started a section for that purpose; might you fill it in?
> 
> I think a lot of people would be interested.

done. I am listing all accepted for now, since this is the first report
there; in 6 months I will try to produce a useful delta.

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/20180425/f36f1cc2/attachment.sig>

From iavor.diatchki at gmail.com  Wed Apr 25 16:44:09 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 25 Apr 2018 16:44:09 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <6c04cf30e8d4226696c4cc38c128817f911b8ae8.camel@joachim-breitner.de>
References: <19a1e53900182a978587faee78cb6b74cd9d69d6.camel@joachim-breitner.de>
 <VI1PR83MB0174CDA3ECB0A5BE9B2ACF73AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <388b9e565b193ab590e5a88e624f436d48001531.camel@joachim-breitner.de>
 <VI1PR83MB01746A5E2CFB82E9951E1FFAAD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <0f819608b3935735af9cff43009f8c6244b795a0.camel@joachim-breitner.de>
 <VI1PR83MB017449175706BD36617E59F5AD880@VI1PR83MB0174.EURPRD83.prod.outlook.com>
 <FFE271D2-477E-427D-AEA2-4E127F8482CC@joachim-breitner.de>
 <CAGK9nuph7vbz7Dn0eoKLU-m8by6qFBpPBp3XKeG4dCNQPQ6YHA@mail.gmail.com>
 <6c04cf30e8d4226696c4cc38c128817f911b8ae8.camel@joachim-breitner.de>
Message-ID: <CAGK9nupxSSJ099OfA9VDxS0=XBgVqSAh16i7T_W5v9A7z-f29w@mail.gmail.com>

Hi,

yes, I remember the thread, and at the time I also thought that e-mail
works well enough, but it seems that lately there's been a lot of activity
and I thought that it might be nice if there is a single place to read and
discuss things.

-Iavor


On Tue, Apr 24, 2018 at 6:24 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Mittwoch, den 25.04.2018, 00:30 +0000 schrieb Iavor Diatchki:
> > I was just trying to catch up on the GHC proposals, and I am afraid
> > that I've gotten a bit lost among all the e-mails in my inbox.
> >  Given that we have quite a bit of traffic, perhaps we should have
> > the committee discussions somewhere online (e.g., git-hub), as it
> > would be quite a bit easier to catch up if everything is one place.
> > Thoughts?  Perhaps, I should be better at organizing my inbox, but I
> > guess I'm not :-)
>
> if you just need to catch up and your mail client is not helpful
> enough, then the threaded view on
>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2018-April/thread.html
> might provide a good alternative.
>
> There was a discussion of switching from email to Github earlier this
> year; see this thread:
>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2018-February/000349.html
> but the conclusion of that thread is to stay with email.
>
> 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/20180425/fa20dcad/attachment-0001.html>

From mail at joachim-breitner.de  Sat Apr 28 22:59:31 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 28 Apr 2018 18:59:31 -0400
Subject: [ghc-steering-committee] Please Review: UnliftedArray# (#112),
	Shepherd: Simon Marlow
Message-ID: <0f97dad2d79bbcdb8020c744f86b37372f00cbdb.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

UnliftedArray# has been proposed by Andrew Martin:
https://github.com/ghc-proposals/ghc-proposals/pull/112

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, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who
stays quiet agrees with you.

Thanks,
-- 
Joachim 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/20180428/6a567399/attachment.sig>

From iavor.diatchki at gmail.com  Mon Apr 30 16:31:30 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 30 Apr 2018 16:31:30 +0000
Subject: [ghc-steering-committee] Deriving via (#120),
	Recommendation: accept
In-Reply-To: <b009873da7627da212ce0be8b4fe8f5eb2fdd504.camel@joachim-breitner.de>
References: <b009873da7627da212ce0be8b4fe8f5eb2fdd504.camel@joachim-breitner.de>
Message-ID: <CAGK9nur1Wz5XgU4PehY=CD6Y5ji83TWbLNc8A69+of-3vhYTLw@mail.gmail.com>

Seems like a good idea.

On Mon, Apr 23, 2018 at 7:20 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> Deriving via was proposed, by Ryan, Icelandjack and Andres,
> https://github.com/ghc-proposals/ghc-proposals/pull/120
> rendered at
>
> https://github.com/Icelandjack/ghc-proposals/blob/patch-3/proposals/0000-deriving-via.rst
>
> I’ll shepherd that myself.
>
> The proposal adds a new deriving strategy that works like GND, but
> explicitly names the other, representationally equal type whose
> instance should be copied.
>
> The proposal comes with a paper and an implementation, has been met
> with great enthusiasm in the community, and I expect that our users
> will do many great things with it, and all that with relatively little
> theoretical and implemntational overhead.
>
> I therefore wholeheartedly recomment that we 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/20180430/fd789ae5/attachment.html>

From mail at joachim-breitner.de  Mon Apr 30 17:26:01 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 30 Apr 2018 13:26:01 -0400
Subject: [ghc-steering-committee] Please Review: ExtraCommas (#87),
	Shepherd: Chris Allen
Message-ID: <0532d811e50fa43ecdc01ea486f7f67edff80db9.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

ExtraCommas has been proposed by Andrew Martin:
https://github.com/ghc-proposals/ghc-proposals/pull/112

I propose Chris Allen as the shepherd.

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

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

Thanks,
-- 
Joachim 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/20180430/9a75e758/attachment.sig>

From iavor.diatchki at gmail.com  Mon Apr 30 18:27:47 2018
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 30 Apr 2018 18:27:47 +0000
Subject: [ghc-steering-committee] Please Review: ExtraCommas (#87),
 Shepherd: Chris Allen
In-Reply-To: <0532d811e50fa43ecdc01ea486f7f67edff80db9.camel@joachim-breitner.de>
References: <0532d811e50fa43ecdc01ea486f7f67edff80db9.camel@joachim-breitner.de>
Message-ID: <CAGK9nurSbMukRO=Y611b0BKcCx5JqEKAO16-cwzqMdoZtsGhog@mail.gmail.com>

This is the correct link to this proposal:
https://github.com/ghc-proposals/ghc-proposals/pull/87

On Mon, Apr 30, 2018 at 10:26 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> this is your secretary speaking:
>
> ExtraCommas has been proposed by Andrew Martin:
> https://github.com/ghc-proposals/ghc-proposals/pull/112
>
> I propose Chris Allen as the shepherd.
>
> Chris, please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> I suggest you make a recommendation, in a new e-mail thread with the
> proposal number in the subject, about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
>
> Thanks,
> --
> Joachim 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/20180430/b6ce22ea/attachment.html>

From simonpj at microsoft.com  Mon Apr 30 21:38:11 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 30 Apr 2018 21:38:11 +0000
Subject: [ghc-steering-committee] Please Review: ExtraCommas (#87),
 Shepherd: Chris Allen
In-Reply-To: <CAGK9nurSbMukRO=Y611b0BKcCx5JqEKAO16-cwzqMdoZtsGhog@mail.gmail.com>
References: <0532d811e50fa43ecdc01ea486f7f67edff80db9.camel@joachim-breitner.de>
 <CAGK9nurSbMukRO=Y611b0BKcCx5JqEKAO16-cwzqMdoZtsGhog@mail.gmail.com>
Message-ID: <VI1PR83MB01749CFE2734E4D7619DE566AD820@VI1PR83MB0174.EURPRD83.prod.outlook.com>

I’ve commented at
https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-385536587

Generally in favour, with some caveats.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 30 April 2018 19:28
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] Please Review: ExtraCommas (#87), Shepherd: Chris Allen

This is the correct link to this proposal:  https://github.com/ghc-proposals/ghc-proposals/pull/87

On Mon, Apr 30, 2018 at 10:26 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

ExtraCommas has been proposed by Andrew Martin:
https://github.com/ghc-proposals/ghc-proposals/pull/112

I propose Chris Allen as the shepherd.

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

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

Thanks,
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180430/81f9711b/attachment-0001.html>