[ghc-steering-committee] [EXTERNAL] #265: Unlifted Datatypes, recommendation: accept

Thu Jan 30 08:52:14 UTC 2020

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 <rae at richarde.dev> wrote:

> I think that is our stated policy, yes.
>
> On Dec 9, 2019, at 7:58 AM, Simon Marlow <marlowsd at gmail.com> 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 <arnaud.spiwack at 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-562125048
>> .
>>
>> 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 <ghc-steering-committee at haskell.org> wrote:
>>
>>> I’m in support here.  I’ve commented on the discussion thread.
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon Marlow
>>> *Sent:* 02 December 2019 10:06
>>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>>> *Cc:* ghc-steering-committee at 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-unlifted-datatypes.rst
>>> <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 <mail at 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-unlifted-datatypes.rst
>>> <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 at 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 at 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 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/20200130/f902b4bb/attachment.html>