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

[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
>