[CakeML-dev] Constructor syntax

[Michael.Norrish at data61.csiro.au]

I suppose “I object a bit” because I generally like the SML syntax for most things, and changing smacks a little of “we couldn’t be bothered to do the hard yards and so we made the interesting problem easier to suit ourselves”.  Now, I don’t really believe that, because syntax is not really an interesting problem, and having to handle tupled constructors and all the associated cruft is just masochism.  (The same might be said of giving up on left-to-right evaluation.)

The disadvantage of switching will clearly be that we make it harder for people to port code.  But how much such porting did we ever expect? On a more trivial note, I also think that having to know a constructor’s arity just to pattern match against it is a little ugly.  In SML you can write

   C _ => …

and you know you’ve matched regardless of the arity. Having to remember the arity is a (minor!) burden, both when writing and when maintaining code.  This is why I suggested that “C _” could be a magic form that would match regardless of arity.

Michael

On 10/5/17, 07:43, "Scott Owens" <S.A.Owens at kent.ac.uk> wrote:

    
    > On 2017/05/09, at 20:16, Magnus Myreen <magnus.myreen at gmail.com> wrote:
    > 
    > On 9 May 2017 at 10:13, Scott Owens <S.A.Owens at kent.ac.uk> wrote:
    >> 
    >>> On 2017/05/09, at 01:19, michael.norrish at data61.csiro.au wrote:
    >>> 
    >>> I don’t object too strongly to switching to Haskell syntax.
    > 
    > So you object a bit?
    
    Even though I am advocating the switch, I am a little trepidatious about losing compatibility, since there is almost certainly no going back. So we do need to be sure that we aren’t overlooking any important reasons not to switch.
    
    > 
    >>> I’m curious as to how you will treat the Foo _ pattern though.  If Foo is really of arity 2, something presumably has to convert the convenient Foo _ syntax to the more accurate Foo _ _. Is this going to happen in the type inferencer?
    >>> 
    >>> Or is there a new constructor in the pat type called something like ConstructorPattern, which takes an id and whose semantics is to test for a constructor and not to care about the arguments?
    >> 
    >> We don’t support it at the moment. To add it, I think a new pattern AST for Ctor_any would be the cleanest.
    > 
    > Why would we allow Foo _ in the curried setting if Foo is of arity 2?
    > I think that should be a type error. I read Scott's original reply as
    > a response in the context of tupled constructors, where Foo _ makes
    > sense.
    
    I did mention that originally n terms of tupled constructors. Then I mentioned that we could support it with curried constructors. But maybe we don’t want to.
    
    Scott