[CakeML-dev] Constructor syntax

[Scott Owens]

The SOME (a, b) pattern is a constructor pattern with a tuple sub-pattern. The pattern match compiler has to know the declared arities of the constructors to disambiguate this from a constructor applied to several arguments. This is a complication that I forgot to mention and part of the reason why I like the move to Haskell syntax.

Scott

> On 2017/05/03, at 19:53, Magnus Myreen <magnus.myreen at gmail.com> wrote:
> 
> 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
> _______________________________________________
> Developers mailing list
> Developers at cakeml.org
> https://lists.cakeml.org/listinfo/developers