I think that is our stated policy, yes.On Dec 9, 2019, at 7:58 AM, Simon Marlow <marlowsd@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@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@haskell.org> wrote:_______________________________________________I’m in support here. I’ve commented on the discussion thread.
Simon
From: ghc-steering-committee <ghc-steering-committee-bounces@haskell.org> On Behalf Of Simon Marlow
Sent: 02 December 2019 10:06
To: Joachim Breitner <mail@joachim-breitner.de>
Cc: ghc-steering-committee@haskell.org
Subject: [EXTERNAL] [ghc-steering-committee] #265: Unlifted Datatypes, recommendation: accept
I recommend that we accept proposal #265 (Unlifted Datatypes)
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@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@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