[CakeML-dev] Constructor syntax

[Konrad Slind]

Would it be possible to write a tool that would parse SML and generate the
favoured CakeML constructor syntax? Might be a good student project.

Konrad.


On Mon, May 8, 2017 at 2:40 PM, Ramana Kumar <Ramana.Kumar at cl.cam.ac.uk>
wrote:

> 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
>>
>
>
> _______________________________________________
> 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/55b3583a/attachment-0001.html>