Re: [ghc-steering-committee] #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