[ghc-steering-committee] Unlifted Newtypes (#98)

[Joachim Breitner]

Hi,

I agree that this is an accept!

Cheers,
Joachim



Am Mittwoch, den 21.02.2018, 23:18 -0500 schrieb Richard Eisenberg:
> Conversation here has ebbed down. I am understanding this to mean
> acceptance, in accordance with my recommendation. In roughly a week,
> I'll conclude that indeed we have accepted this proposal.
> 
> Thanks,
> Richard
> 
> > On Feb 12, 2018, at 9:43 PM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> > 
> > Given that you think the levity polymorphism-related implications are fine, the proposal seems fine to me.
> > 
> > Manuel
> > 
> > > 12.02.2018 11:28 Richard Eisenberg <rae at cs.brynmawr.edu>:
> > > 
> > > I have been assigned as the shepherd for proposal #98: Unlifted Newtypes, https://github.com/ghc-proposals/ghc-proposals/pull/98
> > > 
> > > Summary:
> > > 
> > > This proposal suggests lifting the current restriction that newtype kinds are always Type -- that is, TYPE LiftedRep. At its core, that's the entire proposal; the rest is just motivation (which is quite well-written, if you're feeling unmotivated) and consequences. Here are a few of the twists and turns:
> > > 
> > > - The non-Type kinds should be inferred, based on the kind of the wrapped type. In the event of a trivial recursive newtype (e.g., newtype Void = Void Void), the kind would default to lifted, though the user could override this behavior with a kind signature using GADT syntax. The proposal author conjectures that all inhabited unlifted newtypes will have inferrable kinds; I've not tried hard to prove or refute this claim.
> > > 
> > > - The proposal suggests that the Coercible mechanism be extended to deal with unlifted types. This could be handled by generalizing the type of `coerce` to be levity-polymorphic. Note that doing so does not violate levity polymorphism restrictions, because coerce always inlines to a cast, and casts are erased before code generation. If `coerce` is generalized, GeneralizedNewtypeDeriving will work over the new unlifted newtypes.
> > > 
> > > - The proposal suggests that newtypes can indeed be levity-polymorphic: newtype Id# (r :: RuntimeRep) (a :: TYPE r) = MkId# a. This does not appear to violate levity polymorphism restrictions, either, because the MkId# constructor doesn't appear in Core. Any use of this newtype will have to be specialized to a certain RuntimeRep, but that specialization would already be guaranteed by the existing levity polymorphism restrictions.
> > > 
> > > The main drawback in the proposal is that this is the first way users can create their own unlifted types. Accordingly, a user might unwittingly use an unlifted type where they expect laziness; the strictness that, say, an unlifted-variable pattern binding would induce would be a surprise and hard to find.
> > > 
> > > Opinion & recommendation:
> > > 
> > > I am in support of this proposal and propose acceptance. The motivation section in the proposal is compelling, and this seems a natural generalization of existing structures. There are no concrete syntax ramifications. Given the existing levity polymorphism set-up, this proposal seems like an easy win.
> > > 
> > > If we are concerned about unexpected strictness, we could require that all unlifted newtypes be suffixed with one or more hashes, but I do not recommend doing so, instead encouraging library-writers to be sensitive to this problem, giving those authors the latitude to choose the best name for their types.
> > > 
> > > Thanks,
> > > Richard
> > > 
> > > _______________________________________________
> > > 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
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180227/9c18013b/attachment.sig>