[CakeML-dev] Constructor syntax

[Ramana Kumar]

I am not opposed to breaking SML syntax compatibility. I think Scott's
preferred option seems good.

On 8 May 2017 at 07:01, Magnus Myreen <magnus.myreen at gmail.com> wrote:

> Scott's arguments have convinced me that we should move to
> Haskell-style syntax for constructors and be more forward looking in
> general. (A few direct replies inline below.)
>
> However, I would like us to wait with the final decision until Ramana
> comes back online.
>
> Does anyone else have opinions regarding this choice of direction,
> i.e. moving away from attempting to be as SML compatible as possible?
>
> Cheers,
> Magnus
>
> On 8 May 2017 at 15:44, Scott Owens <S.A.Owens at kent.ac.uk> wrote:
> >
> >> On 2017/05/08, at 12:53, Magnus Myreen <magnus.myreen at gmail.com> wrote:
> >>
> >> I object to Haskell-style syntax.
> >
> > Do you object because there’s something bad about it, or just because of
> SML compatibility?
>
> I like the look of Haskell syntax. It is just because I don't want us
> to become less SML compatibility.
>
> >> 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.
> >
> > I think this is the point where we either have to decide that SML
> compatibility is critical and commit to keeping it in the long term, or
> decide that we can improve the syntax of the language when needed. So it’s
> not just about the constructors. Essentially, the amount of work to switch
> to curried constructors is very small, and the amount of work needed to
> keep tupled ones is much more, so we don’t want to put in the work unless
> we’re convinced about the usefulness of SML syntax.
>
> You are making some compelling points here regarding the long-term aspect.
>
> > As I see it, the disadvantages of tupled constructors compared to
> curried ones are:
> >
> > - They are ugly
> > - CakeML generally encourages currying
> > - They are less flexible because they don’t support partial application
> > - They aren’t like HOL, so when doing a combined translator and cf
> development, this could lead to confusion
> > - They require some compiler work to implement efficiently
> >
> > The only advantage is that they are how SML does it.
> >
> > What are the advantages of staying with SML? It is a real language, but
> it (sadly) doesn’t appear to have a vibrant community, especially compared
> to other functional languages. Furthermore, there aren’t that many SML
> programs that we will be able to run without changes, since there are still
> quite a few features that we don’t plan to implement any time soon.
> >
> > The disadvantages are that we can’t improve the syntax later on, for
> example by adding end to case, or removing it from let (depending on
> whether you like end or not, but it makes no sense to have it only
> sometimes). When we get around to implementing records and functors we’d
> have to use SML’s approach, even though these might not be the best design
> for our purposes.
> >
> >> 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.
> >
> > It would still be good to be able to write Foo _, but that shouldn’t be
> too difficult.
> >
> > Scott
> >
>
> _______________________________________________
> 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/20170508/9c52adcf/attachment.html>