<div dir="ltr"><div><div><div><div>I'm in favour of the proposal, but on this point:<br><br>>  The proposal author conjectures that all inhabited unlifted newtypes 
will have inferrable kinds; I've not tried hard to prove or refute this 
claim.<br>
<br></div>What will happen if a kind can't be inferred? What error message will the user see?<br><br></div>I think the potential for confusion goes further than "the strictness that, say, an unlifted-variable pattern binding would induce would be a surprise and hard to find.". The user is quite likely to encounter type errors due to trying to use an unlifted newtype in a pair or a list, for example, or returning one in a monad.  In this case they'll see a kind mismatch error, ideally we would want the compiler to emit a helpful hint in these cases.<br><br></div>Cheers<br></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 February 2018 at 04:18, Richard Eisenberg <span dir="ltr"><<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Thanks,<br>
Richard<br>
<div class="HOEnZb"><div class="h5"><br>
> On Feb 12, 2018, at 9:43 PM, Manuel M T Chakravarty <<a href="mailto:chak@justtesting.org">chak@justtesting.org</a>> wrote:<br>
><br>
> Given that you think the levity polymorphism-related implications are fine, the proposal seems fine to me.<br>
><br>
> Manuel<br>
><br>
>> 12.02.2018 11:28 Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>>:<br>
>><br>
>> I have been assigned as the shepherd for proposal #98: Unlifted Newtypes, <a href="https://github.com/ghc-proposals/ghc-proposals/pull/98" rel="noreferrer" target="_blank">https://github.com/ghc-<wbr>proposals/ghc-proposals/pull/<wbr>98</a><br>
>><br>
>> Summary:<br>
>><br>
>> 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:<br>
>><br>
>> - 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.<br>
>><br>
>> - 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.<br>
>><br>
>> - 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.<br>
>><br>
>> 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.<br>
>><br>
>> Opinion & recommendation:<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> Thanks,<br>
>> Richard<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> ghc-steering-committee mailing list<br>
>> <a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@<wbr>haskell.org</a><br>
>> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
><br>
<br>
______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@<wbr>haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
</div></div></blockquote></div><br></div>