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 <johan.tib...@gmail.com> 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 <dan.d...@gmail.com> 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 <johan.tib...@gmail.com> >> 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 >> > >> > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs