<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I’m generally in support of this idea, but I’ve suggested a few tweaks on the GitHub thread.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 2, 2019, at 10:06 AM, Simon Marlow <<a href="mailto:marlowsd@gmail.com" class="">marlowsd@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">I recommend that we <i class=""><b class="">accept</b></i> proposal #265 (Unlifted Datatypes)<br class=""></div><div class=""><br class=""></div><div class=""><a href="https://github.com/ghc-proposals/ghc-proposals/pull/265" class="">https://github.com/ghc-proposals/ghc-proposals/pull/265</a></div><div class=""></div><div class=""><a href="https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst" rel="noreferrer" target="_blank" class="">https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst</a></div><div class=""><br class=""></div><div class="">It's a fairly conservative extension: the kind <span style="font-family:monospace" class="">TYPE 'UnliftedRep</span> 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.</div><div class=""><br class=""></div><div class="">There are considerable performance benefits to be had for performance-critical code, for instance the containers package.<br class=""></div><div class=""><br class=""></div><div class="">A couple of minor issues remain:</div><ul class=""><li class="">Without special support, the type <span style="font-family:monospace" class="">data unlifted Strict a = Force !a</span> comes with an associated box, so this type isn't as useful as it could be.</li><li class="">It isn't possible to define values of kind <span style="font-family:monospace" class="">TYPE 'UnlifedRep</span> 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 <span style="font-family:monospace" class="">TYPE 'UnlifedRep</span> to the top level in the optimiser, which can lead to surprising performance behaviour. See <a href="https://gitlab.haskell.org/ghc/ghc/issues/17521" class="">https://gitlab.haskell.org/ghc/ghc/issues/17521</a></li></ul><div class="">Nevertheless, we shouldn't let the perfect be the enemy of the good, and Unlifted Datatypes is a clearly useful addition in my view.</div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Simon<br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Nov 2019 at 10:06, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Committee,<br class="">
<br class="">
this is your secretary speaking:<br class="">
<br class="">
Unlifed Datatypes<br class="">
has been proposed by Sebastian Graf<br class="">
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/265" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals/pull/265</a><br class="">
<a href="https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst" rel="noreferrer" target="_blank" class="">https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst</a><br class="">
<br class="">
I propose Simon Marlow as the shepherd, as the expert on low-level stuff.<br class="">
<br class="">
Please reach consensus as described in<br class="">
<a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br class="">
I suggest you make a recommendation, in a new e-mail thread with the<br class="">
proposal number in the subject, about the decision, maybe point out<br class="">
debatable points, and assume that anyone who stays quiet agrees with<br class="">
you.<br class="">
<br class="">
Thanks,<br class="">
Joachim<br class="">
-- <br class="">
Joachim Breitner<br class="">
<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a><br class="">
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank" class="">http://www.joachim-breitner.de/</a><br class="">
<br class="">
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></body></html>