Re: RFC: Unpacking sum types

Just a small comment about syntax. Why is there an "_n" suffix on the type constructor? Isn't it syntactically evident how many things are in the |# .. | .. #| block? More generally, are the parser changes and the wild new syntax strictly necessary? Could we instead just have a new keyword, but have at look like a normal type constructor? For example, the type: (Sum# T1 T2 T3) Where "UnboxedSum" can't be partially applied, and is variable arity. Likewise, "MkSum#" could be a keyword/syntactic-form: (MkSum# 1 3 expr) case x of MkSum# 1 3 v -> e 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. -Ryan On Tue, Sep 1, 2015 at 6:10 PM Johan Tibell wrote:

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).

On Tue, Sep 1, 2015 at 11:31 AM, Dan Doel wrote:

...

I wonder: are there issues with strict/unpacked fields in the sum type, with regard to the 'fill in stuff' behavior?

For example:

data C = C1 !Int | C2 ![Int]

data D = D1 !Double {-# UNPACK #-} !C

Naively we might think:

data D' = D1 !Double !Tag !Int ![Int]

But this is obviously not going to work at the Haskell-implemented-level. Since we're at a lower level, we could just not seq the things from the opposite constructor, but are there problems that arise from that? Also of course the !Int will probably also be unpacked, so such prim types need different handling (fill with 0, I guess).

--

Also, I guess this is orthogonal, but having primitive, unboxed sums (analogous to unboxed tuples) would be nice as well. Conceivably they could be used as part of the specification of unpacked sums, since we can apparently put unboxed tuples in data types now. I'm not certain if they would cover all cases, though (like the strictness concerns above).

-- Dan

On Tue, Sep 1, 2015 at 1:23 PM, Johan Tibell wrote:

...

I have a draft design for unpacking sum types that I'd like some feedback on. In particular feedback both on:

* the writing and clarity of the proposal and * the proposal itself.

https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes

-- Johan

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs