RFC: Unpacking sum types
mail at joachim-breitner.de
Wed Sep 2 02:12:27 UTC 2015
Am Mittwoch, den 02.09.2015, 01:44 +0000 schrieb Ryan Newton:
> Why is there an "_n" suffix on the type constructor? Isn't it
> syntactically evident how many things are in the |# .. | .. #|
> More generally, are the parser changes and the wild new syntax
> strictly necessary?
If we just add it to Core, to support UNPACK, then there is no parser
involved anyways, and the pretty-printer may do fancy stuff. (Why not
unicode subscript numbers like ₂ :-))
But we probably want to provide this also on the Haskell level, just
like unboxed products, right? Then we should have a nice syntax.
Personally, I find
(# a | b | c #)
visually more pleasing.
(The disadvantage is that this works only for two or more alternatives,
but the one-alternative-unboxed-union is isomorphic to the one-element
-unboxed-tuple anyways, isn’t it?)
> 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.
If we expose it on the Haskell level, I find MkSum_1_2# the right thing
to do: It makes it clear that (conceptually) there really is a
constructor of that name, and it is distinct from MkSum_2_2#, and the
user cannot do computation with these indices.
Joachim “nomeata” Breitner
mail at joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nomeata at joachim-breitner.de • GPG-Key: 0xF0FBF51F
Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the ghc-devs