RFC: Unpacking sum types

[Joachim Breitner]

Hi,

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 |# .. | ..  #| 
> block? 

Correct.

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

Greetings,
Joachim

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150901/ed78b526/attachment.sig>