<div dir="ltr">Would it be possible to write a tool that would parse SML and generate the<div>favoured CakeML constructor syntax? Might be a good student project.</div><div><br></div><div>Konrad.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 8, 2017 at 2:40 PM, Ramana Kumar <span dir="ltr"><<a href="mailto:Ramana.Kumar@cl.cam.ac.uk" target="_blank">Ramana.Kumar@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am not opposed to breaking SML syntax compatibility. I think Scott's preferred option seems good.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 8 May 2017 at 07:01, Magnus Myreen <span dir="ltr"><<a href="mailto:magnus.myreen@gmail.com" target="_blank">magnus.myreen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Scott's arguments have convinced me that we should move to<br>
Haskell-style syntax for constructors and be more forward looking in<br>
general. (A few direct replies inline below.)<br>
<br>
However, I would like us to wait with the final decision until Ramana<br>
comes back online.<br>
<br>
Does anyone else have opinions regarding this choice of direction,<br>
i.e. moving away from attempting to be as SML compatible as possible?<br>
<br>
Cheers,<br>
Magnus<br>
<span><br>
On 8 May 2017 at 15:44, Scott Owens <<a href="mailto:S.A.Owens@kent.ac.uk" target="_blank">S.A.Owens@kent.ac.uk</a>> wrote:<br>
><br>
>> On 2017/05/08, at 12:53, Magnus Myreen <<a href="mailto:magnus.myreen@gmail.com" target="_blank">magnus.myreen@gmail.com</a>> wrote:<br>
>><br>
>> I object to Haskell-style syntax.<br>
><br>
> Do you object because there’s something bad about it, or just because of SML compatibility?<br>
<br>
</span>I like the look of Haskell syntax. It is just because I don't want us<br>
to become less SML compatibility.<br>
<span><br>
>> I've been all too busy in the last few days to reply and I wanted to<br>
>> reply properly. I've all along thought that option 2 is best, because<br>
>> we shouldn't break compatibility with SML.<br>
><br>
> 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.<br>
<br>
</span>You are making some compelling points here regarding the long-term aspect.<br>
<div class="m_-129985275440429717HOEnZb"><div class="m_-129985275440429717h5"><br>
> As I see it, the disadvantages of tupled constructors compared to curried ones are:<br>
><br>
> - They are ugly<br>
> - CakeML generally encourages currying<br>
> - They are less flexible because they don’t support partial application<br>
> - They aren’t like HOL, so when doing a combined translator and cf development, this could lead to confusion<br>
> - They require some compiler work to implement efficiently<br>
><br>
> The only advantage is that they are how SML does it.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
>> We should implicitly define functions for each constructor (at each<br>
>> Dtype) so that one can write `map SOME xs` and `SOME (1,2)` without<br>
>> problems, and then rely on an optimisation in BVL to inline the<br>
>> primitive Con syntax in the right places and get rid of the tupling.<br>
>><br>
>> Patterns need to be treated more carefully. I think the syntax should<br>
>> only take zero or one argument in patterns. However, the type system<br>
>> and type inference should inspect the shape of the argument to check<br>
>> that the constructor is given the right number of elements as a tuple<br>
>> in the argument to the constructor. The relevant part of the compiler<br>
>> knows enough about arities of constructors to produce the right code<br>
>> from this cons-applied-to-tuple pattern. I think we should ban<br>
>> applying a constructor to something too abstract in patterns, e.g. |<br>
>> Foo x => when Foo is defined as Foo of int * int.<br>
><br>
> It would still be good to be able to write Foo _, but that shouldn’t be too difficult.<br>
><br>
> Scott<br>
><br>
<br>
______________________________<wbr>_________________<br>
Developers mailing list<br>
<a href="mailto:Developers@cakeml.org" target="_blank">Developers@cakeml.org</a><br>
<a href="https://lists.cakeml.org/listinfo/developers" rel="noreferrer" target="_blank">https://lists.cakeml.org/listi<wbr>nfo/developers</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Developers mailing list<br>
<a href="mailto:Developers@cakeml.org">Developers@cakeml.org</a><br>
<a href="https://lists.cakeml.org/listinfo/developers" rel="noreferrer" target="_blank">https://lists.cakeml.org/<wbr>listinfo/developers</a><br>
<br></blockquote></div><br></div>