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

Sandy Maguire sandy at sandymaguire.me
Tue Dec 3 01:39:20 UTC 2019


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 <rae at richarde.dev> 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 <marlowsd at gmail.com> 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-unlifted-datatypes.rst
>
> 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 <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://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst
>>
>> 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 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
>
>
> _______________________________________________
> 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/20191203/b735c0ba/attachment.html>


More information about the ghc-steering-committee mailing list