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
[email protected] • http://www.joachim-breitner.de/
Jabber: [email protected] • GPG-Key: 0xF0FBF51F
Debian Developer: [email protected]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
