[CakeML-dev] Constructor syntax

Magnus Myreen magnus.myreen at gmail.com
Mon May 8 11:53:31 UTC 2017


I object to Haskell-style syntax.

I've been all too busy in the last few days to reply and I wanted to
reply properly. I've all along thought that option 2 is best, because
we shouldn't break compatibility with SML.

We should implicitly define functions for each constructor (at each
Dtype) so that one can write `map SOME xs` and `SOME (1,2)` without
problems, and then rely on an optimisation in BVL to inline the
primitive Con syntax in the right places and get rid of the tupling.

Patterns need to be treated more carefully. I think the syntax should
only take zero or one argument in patterns. However, the type system
and type inference should inspect the shape of the argument to check
that the constructor is given the right number of elements as a tuple
in the argument to the constructor. The relevant part of the compiler
knows enough about arities of constructors to produce the right code
from this cons-applied-to-tuple pattern. I think we should ban
applying a constructor to something too abstract in patterns, e.g. |
Foo x => when Foo is defined as Foo of int * int.

Cheers,
Magnus

On 8 May 2017 at 13:10, Scott Owens <S.A.Owens at kent.ac.uk> wrote:
> I’m surprised that this hasn’t generated discussion. To force matters, I will change the syntax to the curried Haskell style starting next Monday, unless I hear an objection and some follow-up discussion. I think this problems needs to be solved one way or the other before the tutorials start.
>
> Scott
>
>> On 2017/05/04, at 14:29, Scott Owens <S.A.Owens at kent.ac.uk> wrote:
>>
>> 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
>>
>> _______________________________________________
>> Developers mailing list
>> Developers at cakeml.org
>> https://lists.cakeml.org/listinfo/developers
>



More information about the Developers mailing list