[CakeML-dev] Constructor syntax

[Scott Owens]

It just occurred to me after pressing send, that the AST, operational semantics, and type system could treat the constructors as having 0 or 1 argument as in 5 below and following SML very closely. Then the compiler could change all of the constructors to have multiple arguments according to their definitions, and insert code to copy into (for pattern matching) and out of (for constructor building) tuples. Of course, those compiler passes would need to know the constructor arities. We’d then need to be able to optimise the copying away later on.

Scott

> On 2017/05/04, at 14:11, Scott Owens <S.A.Owens at kent.ac.uk> wrote:
> 
> After further thought on this, I think the only viable options are to move to Haskell (or another) syntax, or to add some elaboration into the type system. Essentially, with the ambiguous syntax you have to know the declared arity, and that requires an environment to track the constructors. Since the type system already has this environment, it is the natural place to put it. Thus option 2 will only work if the compiler doesn’t need to work out which tuples should exist at runtime and which are actually part of the constructor’s block.
> 
> So I’ll amend my list to be 
> 
> 1) as below
> 3) as below
> 4) as below
> 5) Make all constructors either 0 or 1 argument, and don’t flatten the tuples into the constructor’s block at runtime. Disadvantage: terrible performance.
> 
> Scott
> 
>> On 2017/05/03, at 20:59, Scott Owens <S.A.Owens at kent.ac.uk> wrote:
>> 
>> 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
>> 
>> _______________________________________________
>> 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