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

[Richard Eisenberg]

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/ghc-proposals/ghc-proposals/pull/265>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst <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 <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 <mailto: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/ghc-proposals/ghc-proposals/pull/265>
> https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst <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 <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 <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/20191202/e8bd544e/attachment.html>