[CakeML-dev] Constructor syntax

[Magnus Myreen]

I'm confused as to how 2 solves the SOME (a,b) problem when it appears in
patterns. -- Magnus
On Wed, 3 May 2017 at 20:34, <Michael.Norrish at data61.csiro.au> wrote:

> I think 2 is best, but worry about how to handle patterns.  Does the
> pattern compiler have to understand that applications to tuples may or may
> not be proper constructor applications?
>
> Michael
>
> On 3/5/17, 16:52, "Scott Owens" <S.A.Owens at kent.ac.uk> wrote:
>
>     In preparation for the CakeML tutorials, I would like to improve the
> way we treat constructors. The biggest problem is that the constructor
> application syntax and tuple creation syntax are ambiguous. When you write
> SOME (1,2), is that SOME applies to a tuple, or SOME applied to 2
> arguments? The first is the only type-correct way to interpret the program,
> but the second is consistent with the way that all non-unary constructors
> are parsed. There are 4 approaches to solving this, in the order that I
> prefer them in. I’d appreciate any feedback, in particular since moving
> away from SML would be a big step.
>
>     1) Choose a different syntax that is unambiguous. Either follow
> Haskell and write curried constructors (good), or use a different
> surrounding character, e.g., C <1, 2, 3> instead of C (1, 2, 3) (bad, I
> think). Advantage: we can pick a nice syntax and this is easy to implement.
> Disadvantage: lose SML compatibility.
>
>     2) Make all constructors be single argument functions. Multi-arg
> constructors take in a tuple. Advantage: increase SML compatibility.
> Disadvantage: The compiler would need an extra optimisation to not actually
> allocate an intermediate tuple, but we do want something like this for
> function calls anyway.
>
>     3) Keep the language the same, but use the type inferencer to do the
> disambiguation. Advantage: Still SML compatible. Disadvantage: Have to add
> elaboration into the inferencer and type system. This will be a lot of
> work, but is mitigated by other handy uses the elaborator could have once
> it’s in place.
>
>     4) Keep the language the same, but use the parse tree to AST
> translation to disambiguate based on the constructor arities.
>
>     Scott
>     _______________________________________________
>     Developers mailing list
>     Developers at cakeml.org
>     https://lists.cakeml.org/listinfo/developers
>
>
> _______________________________________________
> Developers mailing list
> Developers at cakeml.org
> https://lists.cakeml.org/listinfo/developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cakeml.org/pipermail/developers/attachments/20170503/6914fe2c/attachment.html>