<div dir="ltr"><div>Just a small comment about syntax.</div><div><br></div><div>Why is there an "_n" suffix on the type constructor?  Isn't it syntactically evident how many things are in the |# .. | ..  #| block? </div><div><br></div><div>More generally, are the parser changes and the wild new syntax strictly necessary?</div><div><br></div><div>Could we instead just have a new keyword, but have at look like a normal type constructor?  For example, the type:</div><div><br></div><div>   (Sum# T1 T2 T3)</div><div><br></div><div>Where "UnboxedSum" can't be partially applied, and is variable arity.  Likewise, "MkSum#" could be a keyword/syntactic-form:</div><div><br></div><div>   (MkSum# 1 3 expr)</div><div>  case x of MkSum# 1 3 v -> e<br></div><div><br></div><div>Here "1" and "3" are part of the syntactic form, not expressions.  But it can probably be handled after parsing and doesn't require the "_n_m" business.</div><div><br></div><div>  -Ryan</div><div><br></div> <br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 1, 2015 at 6:10 PM Johan Tibell <<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">After some discussions with SPJ I've now rewritten the proposal in terms of unboxed sums (which should suffer from the extra seq problem you mention above).</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 1, 2015 at 11:31 AM, Dan Doel <span dir="ltr"><<a href="mailto:dan.doel@gmail.com" target="_blank">dan.doel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wonder: are there issues with strict/unpacked fields in the sum<br>
type, with regard to the 'fill in stuff' behavior?<br>
<br>
For example:<br>
<br>
    data C = C1 !Int | C2 ![Int]<br>
<br>
    data D = D1 !Double {-# UNPACK #-} !C<br>
<br>
Naively we might think:<br>
<br>
    data D' = D1 !Double !Tag !Int ![Int]<br>
<br>
But this is obviously not going to work at the<br>
Haskell-implemented-level. Since we're at a lower level, we could just<br>
not seq the things from the opposite constructor, but are there<br>
problems that arise from that? Also of course the !Int will probably<br>
also be unpacked, so such prim types need different handling (fill<br>
with 0, I guess).<br>
<br>
--<br>
<br>
Also, I guess this is orthogonal, but having primitive, unboxed sums<br>
(analogous to unboxed tuples) would be nice as well. Conceivably they<br>
could be used as part of the specification of unpacked sums, since we<br>
can apparently put unboxed tuples in data types now. I'm not certain<br>
if they would cover all cases, though (like the strictness concerns<br>
above).<br>
<br>
-- Dan<br>
<div><div><br>
<br>
On Tue, Sep 1, 2015 at 1:23 PM, Johan Tibell <<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>> wrote:<br>
> I have a draft design for unpacking sum types that I'd like some feedback<br>
> on. In particular feedback both on:<br>
><br>
>  * the writing and clarity of the proposal and<br>
>  * the proposal itself.<br>
><br>
> <a href="https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes</a><br>
><br>
> -- Johan<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
</blockquote></div><br></div>
</blockquote></div></div>