Please review #265: Unlifted Datatypes, Shepherd: Simon Marlow

Joachim Breitner

28 Nov 2019 28 Nov '19

5:06 a.m.

Dear Committee, this is your secretary speaking: Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... I propose Simon Marlow as the shepherd, as the expert on low-level stuff. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Show replies by date

Simon Marlow

2 Dec 2 Dec

5:06 a.m.

New subject: #265: Unlifted Datatypes, recommendation: accept

I recommend that we *accept* proposal #265 (Unlifted Datatypes) https://github.com/ghc-proposals/ghc-proposals/pull/265 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it. There are considerable performance benefits to be had for performance-critical code, for instance the containers package. A couple of minor issues remain: - Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be. - It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. See https://gitlab.haskell.org/ghc/ghc/issues/17521 Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view. Cheers Simon On Thu, 28 Nov 2019 at 10:06, Joachim Breitner wrote:

...

Dear Committee,

this is your secretary speaking:

Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265

https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-...

I propose Simon Marlow as the shepherd, as the expert on low-level stuff.

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

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard Eisenberg

7:54 a.m.

New subject: #265: Unlifted Datatypes, recommendation: accept

I’m generally in support of this idea, but I’ve suggested a few tweaks on the GitHub thread.

...

On Dec 2, 2019, at 10:06 AM, Simon Marlow wrote:

I recommend that we accept proposal #265 (Unlifted Datatypes)

https://github.com/ghc-proposals/ghc-proposals/pull/265 https://github.com/ghc-proposals/ghc-proposals/pull/265 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-...

It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it.

There are considerable performance benefits to be had for performance-critical code, for instance the containers package.

A couple of minor issues remain: Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be. It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. See https://gitlab.haskell.org/ghc/ghc/issues/17521 https://gitlab.haskell.org/ghc/ghc/issues/17521 Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view.

Cheers Simon

On Thu, 28 Nov 2019 at 10:06, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee,

this is your secretary speaking:

Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265 https://github.com/ghc-proposals/ghc-proposals/pull/265 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-...

I propose Simon Marlow as the shepherd, as the expert on low-level stuff.

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

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Sandy Maguire

8:39 p.m.

New subject: #265: Unlifted Datatypes, recommendation: accept

I am generally out of my depth on this one, but I am swayed by the proposal being conservative and useful. This is a weak yea from me! On Mon, Dec 2, 2019 at 7:54 PM Richard Eisenberg wrote:

...

I’m generally in support of this idea, but I’ve suggested a few tweaks on the GitHub thread.

On Dec 2, 2019, at 10:06 AM, Simon Marlow wrote:

I recommend that we *accept* proposal #265 (Unlifted Datatypes)

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

https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-...

It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it.

There are considerable performance benefits to be had for performance-critical code, for instance the containers package.

A couple of minor issues remain:

- Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be. - It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. See https://gitlab.haskell.org/ghc/ghc/issues/17521

Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view.

Cheers Simon

On Thu, 28 Nov 2019 at 10:06, Joachim Breitner wrote:

...
Dear Committee,

this is your secretary speaking:

Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265

https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-...

I propose Simon Marlow as the shepherd, as the expert on low-level stuff.

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

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

5 Dec 5 Dec

8:20 a.m.

New subject: [EXTERNAL] #265: Unlifted Datatypes, recommendation: accept

I’m in support here. I’ve commented on the discussion thread. Simon From: ghc-steering-committee On Behalf Of Simon Marlow Sent: 02 December 2019 10:06 To: Joachim Breitner Cc: ghc-steering-committee@haskell.org Subject: [EXTERNAL] [ghc-steering-committee] #265: Unlifted Datatypes, recommendation: accept I recommend that we accept proposal #265 (Unlifted Datatypes) https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029253857&sdata=aEWC0cJAxCRJ973miRTP%2F6JtGVp%2F4FG6qqmKjjfKywE%3D&reserved=0 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=JCfBIUeVfDO0f6CElwzpmPY9xyYj7pp%2FoojID59kkCo%3D&reserved=0 It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it. There are considerable performance benefits to be had for performance-critical code, for instance the containers package. A couple of minor issues remain: * Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be. * It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. See https://gitlab.haskell.org/ghc/ghc/issues/17521 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F17521&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=dgDbIe9AhhI%2FIsnPDPxX7EAoVVkjaKthu%2FNGcyEBOTU%3D&reserved=0 Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view. Cheers Simon On Thu, 28 Nov 2019 at 10:06, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee, this is your secretary speaking: Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=sbtvm3eM43ihY%2FPoTeS4Sp%2BDE2AJUBSqgGOv6HymoKg%3D&reserved=0 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=PeFWonpeS4vYeanypRBMEWgLFy9CgVeue3OhHrZa7aM%3D&reserved=0 I propose Simon Marlow as the shepherd, as the expert on low-level stuff. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=9V5KT%2F6kDmUNU5xMMKByR4egiSf61TMdq6yoHMviGcg%3D&reserved=0 I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=CSR%2BQeNk7k5o6bjo%2Fv2Ke5Yu6h2hEwqR2gIcu0XMU5U%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=taRsN3Xgue2y426KtNoZGzYtwdviS2%2BwyKmnww8yEAs%3D&reserved=0

Spiwack, Arnaud

9 Dec 9 Dec

2:41 a.m.

New subject: [EXTERNAL] #265: Unlifted Datatypes, recommendation: accept

There is a bit of a discussion on the thread (which I only got time to briefly skim) about whether the proposal should mark unlifted newtypes with a special keyword, or simply by fixing the return kind of the type constructor to `TYPE 'UnliftedRep`. I'm rather on the side of using the return kind, it makes more sense to me. SImon PJ also brings a pretty strong argument in support of this view: https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-5621250... . Either way, The proposal should at least discuss this view in the alternatives before it gets to be accepted or not. But aside from that, I am absolutely in support of the general idea, and the proposal itself is good. On Thu, Dec 5, 2019 at 2:20 PM Simon Peyton Jones via ghc-steering-committee wrote:

...

I’m in support here. I’ve commented on the discussion thread.

Simon

*From:* ghc-steering-committee *On Behalf Of *Simon Marlow *Sent:* 02 December 2019 10:06 *To:* Joachim Breitner *Cc:* ghc-steering-committee@haskell.org *Subject:* [EXTERNAL] [ghc-steering-committee] #265: Unlifted Datatypes, recommendation: accept

I recommend that we *accept* proposal #265 (Unlifted Datatypes)

https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029253857&sdata=aEWC0cJAxCRJ973miRTP%2F6JtGVp%2F4FG6qqmKjjfKywE%3D&reserved=0

https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=JCfBIUeVfDO0f6CElwzpmPY9xyYj7pp%2FoojID59kkCo%3D&reserved=0

It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it.

There are considerable performance benefits to be had for performance-critical code, for instance the containers package.

A couple of minor issues remain:

- Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be. - It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. See https://gitlab.haskell.org/ghc/ghc/issues/17521 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F17521&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=dgDbIe9AhhI%2FIsnPDPxX7EAoVVkjaKthu%2FNGcyEBOTU%3D&reserved=0

Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view.

Cheers

Simon

On Thu, 28 Nov 2019 at 10:06, Joachim Breitner wrote:

Dear Committee,

this is your secretary speaking:

Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=sbtvm3eM43ihY%2FPoTeS4Sp%2BDE2AJUBSqgGOv6HymoKg%3D&reserved=0

https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=PeFWonpeS4vYeanypRBMEWgLFy9CgVeue3OhHrZa7aM%3D&reserved=0

I propose Simon Marlow as the shepherd, as the expert on low-level stuff.

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

Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=CSR%2BQeNk7k5o6bjo%2Fv2Ke5Yu6h2hEwqR2gIcu0XMU5U%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=taRsN3Xgue2y426KtNoZGzYtwdviS2%2BwyKmnww8yEAs%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Marlow

2:58 a.m.

New subject: [EXTERNAL] #265: Unlifted Datatypes, recommendation: accept

Shall we put the proposal back into the needs revision state while this is discussed and the proposal updated? On Mon, 9 Dec 2019 at 07:42, Spiwack, Arnaud wrote:

...

There is a bit of a discussion on the thread (which I only got time to briefly skim) about whether the proposal should mark unlifted newtypes with a special keyword, or simply by fixing the return kind of the type constructor to `TYPE 'UnliftedRep`. I'm rather on the side of using the return kind, it makes more sense to me. SImon PJ also brings a pretty strong argument in support of this view: https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-5621250... .

Either way, The proposal should at least discuss this view in the alternatives before it gets to be accepted or not.

But aside from that, I am absolutely in support of the general idea, and the proposal itself is good.

On Thu, Dec 5, 2019 at 2:20 PM Simon Peyton Jones via ghc-steering-committee wrote:

...
I’m in support here. I’ve commented on the discussion thread.

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Simon Marlow *Sent:* 02 December 2019 10:06 *To:* Joachim Breitner *Cc:* ghc-steering-committee@haskell.org *Subject:* [EXTERNAL] [ghc-steering-committee] #265: Unlifted Datatypes, recommendation: accept

I recommend that we *accept* proposal #265 (Unlifted Datatypes)

https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029253857&sdata=aEWC0cJAxCRJ973miRTP%2F6JtGVp%2F4FG6qqmKjjfKywE%3D&reserved=0

https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=JCfBIUeVfDO0f6CElwzpmPY9xyYj7pp%2FoojID59kkCo%3D&reserved=0

It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it.

There are considerable performance benefits to be had for performance-critical code, for instance the containers package.

A couple of minor issues remain:

- Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be. - It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. See https://gitlab.haskell.org/ghc/ghc/issues/17521 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F17521&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=dgDbIe9AhhI%2FIsnPDPxX7EAoVVkjaKthu%2FNGcyEBOTU%3D&reserved=0

Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view.

Cheers

Simon

On Thu, 28 Nov 2019 at 10:06, Joachim Breitner wrote:

Dear Committee,

this is your secretary speaking:

Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=sbtvm3eM43ihY%2FPoTeS4Sp%2BDE2AJUBSqgGOv6HymoKg%3D&reserved=0

https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=PeFWonpeS4vYeanypRBMEWgLFy9CgVeue3OhHrZa7aM%3D&reserved=0

I propose Simon Marlow as the shepherd, as the expert on low-level stuff.

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

Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=CSR%2BQeNk7k5o6bjo%2Fv2Ke5Yu6h2hEwqR2gIcu0XMU5U%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=taRsN3Xgue2y426KtNoZGzYtwdviS2%2BwyKmnww8yEAs%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard Eisenberg

5:24 a.m.

New subject: [EXTERNAL] #265: Unlifted Datatypes, recommendation: accept

I think that is our stated policy, yes.

...

On Dec 9, 2019, at 7:58 AM, Simon Marlow wrote:

Shall we put the proposal back into the needs revision state while this is discussed and the proposal updated?

On Mon, 9 Dec 2019 at 07:42, Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> wrote: There is a bit of a discussion on the thread (which I only got time to briefly skim) about whether the proposal should mark unlifted newtypes with a special keyword, or simply by fixing the return kind of the type constructor to `TYPE 'UnliftedRep`. I'm rather on the side of using the return kind, it makes more sense to me. SImon PJ also brings a pretty strong argument in support of this view: https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-5621250... https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-5621250... .

Either way, The proposal should at least discuss this view in the alternatives before it gets to be accepted or not.

But aside from that, I am absolutely in support of the general idea, and the proposal itself is good.

On Thu, Dec 5, 2019 at 2:20 PM Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote: I’m in support here. I’ve commented on the discussion thread.

Simon

From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Simon Marlow Sent: 02 December 2019 10:06 To: Joachim Breitner mailto:mail@joachim-breitner.de> Cc: ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org Subject: [EXTERNAL] [ghc-steering-committee] #265: Unlifted Datatypes, recommendation: accept

I recommend that we accept proposal #265 (Unlifted Datatypes)

https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029253857&sdata=aEWC0cJAxCRJ973miRTP%2F6JtGVp%2F4FG6qqmKjjfKywE%3D&reserved=0 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=JCfBIUeVfDO0f6CElwzpmPY9xyYj7pp%2FoojID59kkCo%3D&reserved=0

It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it.

There are considerable performance benefits to be had for performance-critical code, for instance the containers package.

A couple of minor issues remain:

Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be. It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. Seehttps://gitlab.haskell.org/ghc/ghc/issues/17521 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F17521&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=dgDbIe9AhhI%2FIsnPDPxX7EAoVVkjaKthu%2FNGcyEBOTU%3D&reserved=0 Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view.

Cheers

Simon

On Thu, 28 Nov 2019 at 10:06, Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

Dear Committee,

this is your secretary speaking:

Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=sbtvm3eM43ihY%2FPoTeS4Sp%2BDE2AJUBSqgGOv6HymoKg%3D&reserved=0 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=PeFWonpeS4vYeanypRBMEWgLFy9CgVeue3OhHrZa7aM%3D&reserved=0

I propose Simon Marlow as the shepherd, as the expert on low-level stuff.

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

Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=CSR%2BQeNk7k5o6bjo%2Fv2Ke5Yu6h2hEwqR2gIcu0XMU5U%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=taRsN3Xgue2y426KtNoZGzYtwdviS2%2BwyKmnww8yEAs%3D&reserved=0_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Marlow

30 Jan 30 Jan

3:52 a.m.

New subject: [EXTERNAL] #265: Unlifted Datatypes, recommendation: accept

Following a round of suggestions and revisions, I've now marked this proposal as accepted. On Mon, 9 Dec 2019 at 10:24, Richard Eisenberg wrote:

...

I think that is our stated policy, yes.

On Dec 9, 2019, at 7:58 AM, Simon Marlow wrote:

Shall we put the proposal back into the needs revision state while this is discussed and the proposal updated?

On Mon, 9 Dec 2019 at 07:42, Spiwack, Arnaud wrote:

...
There is a bit of a discussion on the thread (which I only got time to briefly skim) about whether the proposal should mark unlifted newtypes with a special keyword, or simply by fixing the return kind of the type constructor to `TYPE 'UnliftedRep`. I'm rather on the side of using the return kind, it makes more sense to me. SImon PJ also brings a pretty strong argument in support of this view: https://github.com/ghc-proposals/ghc-proposals/pull/265#issuecomment-5621250... .

Either way, The proposal should at least discuss this view in the alternatives before it gets to be accepted or not.

But aside from that, I am absolutely in support of the general idea, and the proposal itself is good.

On Thu, Dec 5, 2019 at 2:20 PM Simon Peyton Jones via ghc-steering-committee wrote:

...
I’m in support here. I’ve commented on the discussion thread.

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Simon Marlow *Sent:* 02 December 2019 10:06 *To:* Joachim Breitner *Cc:* ghc-steering-committee@haskell.org *Subject:* [EXTERNAL] [ghc-steering-committee] #265: Unlifted Datatypes, recommendation: accept

I recommend that we *accept* proposal #265 (Unlifted Datatypes)

https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029253857&sdata=aEWC0cJAxCRJ973miRTP%2F6JtGVp%2F4FG6qqmKjjfKywE%3D&reserved=0

https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=JCfBIUeVfDO0f6CElwzpmPY9xyYj7pp%2FoojID59kkCo%3D&reserved=0

It's a fairly conservative extension: the kind TYPE 'UnliftedRep already exists with the required functionality, the only addition here is to allow user-defined types to be declared with that kind. The semantics are clear, and there already exists a prototype patch to implement it.

There are considerable performance benefits to be had for performance-critical code, for instance the containers package.

A couple of minor issues remain:

- Without special support, the type data unlifted Strict a = Force !a comes with an associated box, so this type isn't as useful as it could be. - It isn't possible to define values of kind TYPE 'UnlifedRep at the top level, which might be a surprising restriction to the programmer. (However, there's a reasonable workaround). Relatedly, GHC cannot lift expressions of kind TYPE 'UnlifedRep to the top level in the optimiser, which can lead to surprising performance behaviour. See https://gitlab.haskell.org/ghc/ghc/issues/17521 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2Fissues%2F17521&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=dgDbIe9AhhI%2FIsnPDPxX7EAoVVkjaKthu%2FNGcyEBOTU%3D&reserved=0

Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view.

Cheers

Simon

On Thu, 28 Nov 2019 at 10:06, Joachim Breitner wrote:

Dear Committee,

this is your secretary speaking:

Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029263813&sdata=sbtvm3eM43ihY%2FPoTeS4Sp%2BDE2AJUBSqgGOv6HymoKg%3D&reserved=0

https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029273768&sdata=PeFWonpeS4vYeanypRBMEWgLFy9CgVeue3OhHrZa7aM%3D&reserved=0

I propose Simon Marlow as the shepherd, as the expert on low-level stuff.

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

Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=CSR%2BQeNk7k5o6bjo%2Fv2Ke5Yu6h2hEwqR2gIcu0XMU5U%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cbebbb53672104f8804a408d7770f544a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108780029283726&sdata=taRsN3Xgue2y426KtNoZGzYtwdviS2%2BwyKmnww8yEAs%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Marlow

2 Dec 2 Dec

5:12 a.m.

On Thu, 28 Nov 2019 at 10:06, Joachim Breitner wrote:

...

Dear Committee,

this is your secretary speaking:

Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265

https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-...

I propose Simon Marlow as the shepherd, as the expert on low-level stuff.

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.

BTW, I just checked the proposal process documentation, and it says: - * Now the shepherd proposes to accept or reject the proposal. To do so, they - post their recommendation, with a rationale, on the GitHub discussion thread, - label the pull request as Pending committee review, - re-title the proposal pull request, appending (under review) at the end. (This enables easy email filtering.) - drop a short mail to the mailing list informing the committee that discussion has started. which isn't exactly in line with the paragraph above. Shouldn't the first line be something like "post their recommendation, with a rationale, to the committee mailing list", and remove the final bullet? Cheers Simon

...

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

5:51 a.m.

New subject: [EXTERNAL] Re: Please review #265: Unlifted Datatypes, Shepherd: Simon Marlow

Personally I think it’s helpful to have the proposal and rationale in the public discussion thread, because that gives non-committee members a chance to contribute. E.g. by supporting the recommendation or explaining why they think the recommendation is wrong. Simon From: ghc-steering-committee On Behalf Of Simon Marlow Sent: 02 December 2019 10:13 To: Joachim Breitner Cc: ghc-steering-committee@haskell.org Subject: [EXTERNAL] Re: [ghc-steering-committee] Please review #265: Unlifted Datatypes, Shepherd: Simon Marlow On Thu, 28 Nov 2019 at 10:06, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee, this is your secretary speaking: Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F265&data=02%7C01%7Csimonpj%40microsoft.com%7Cea3e37d7fc99474f2b3208d77710332f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108783771075544&sdata=CTn29iF7iqGfn%2FwdIJRGz%2Baqim2rQk53sCKBPrSny8Q%3D&reserved=0 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsgraf812%2Fghc-proposals%2Fblob%2Funlifted-data%2Fproposals%2F0000-unlifted-datatypes.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cea3e37d7fc99474f2b3208d77710332f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108783771085539&sdata=4ytC%2BHNl38mGCLWUrssLwvH71DbBVrEOhC8TLhoS1jY%3D&reserved=0 I propose Simon Marlow as the shepherd, as the expert on low-level stuff. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Cea3e37d7fc99474f2b3208d77710332f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108783771085539&sdata=uRwxWiNwdquNYPfsHl4AESwX8pvrGhl6tAsFQb9WFR8%3D&reserved=0 I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. BTW, I just checked the proposal process documentation, and it says: • * Now the shepherd proposes to accept or reject the proposal. To do so, they * post their recommendation, with a rationale, on the GitHub discussion thread, * label the pull request as Pending committee review, * re-title the proposal pull request, appending (under review) at the end. (This enables easy email filtering.) * drop a short mail to the mailing list informing the committee that discussion has started. which isn't exactly in line with the paragraph above. Shouldn't the first line be something like "post their recommendation, with a rationale, to the committee mailing list", and remove the final bullet? Cheers Simon Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cea3e37d7fc99474f2b3208d77710332f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108783771085539&sdata=NmVivDrYTY9W2P0cFMpSeAimgtwxViLKuZXp1iilw4E%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cea3e37d7fc99474f2b3208d77710332f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637108783771095532&sdata=hiXqsn8OTheQgjrd3vW%2BIhgITtVIOR7lpucgP3MoCuE%3D&reserved=0

Joachim Breitner

11:13 a.m.

Hi, Am Montag, den 02.12.2019, 10:12 +0000 schrieb Simon Marlow:

...

On Thu, 28 Nov 2019 at 10:06, Joachim Breitner wrote:

...
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.

BTW, I just checked the proposal process documentation, and it says:

Now the shepherd proposes to accept or reject the proposal. To do so, they * post their recommendation, with a rationale, on the GitHub discussion thread, * label the pull request as Pending committee review, * re-title the proposal pull request, appending (under review) at the end. (This enables easy email filtering.) * drop a short mail to the mailing list informing the committee that discussion has started. which isn't exactly in line with the paragraph above. Shouldn't the first line be something like "post their recommendation, with a rationale, to the committee mailing list", and remove the final bullet?

As Simon PJ says, the proposal process text is the better one, and the blurb in my mail was just eternaly copy’n’pasted. Will try to rephrase (or simply point to the process section) in my next mail if I remember. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

1937

Age (days ago)

2000

Last active (days ago)

List overview

Download

11 comments

6 participants

participants (6)

Joachim Breitner
Richard Eisenberg
Sandy Maguire
Simon Marlow
Simon Peyton Jones
Spiwack, Arnaud