Re: [Caml-list] ReasonML concrete syntax

[Sebastien Ferre <Sebastien.Ferre@irisa.fr>]

The Scala notation is an interesting alternative, IMO.

They have two notations, f(x,y) and f(x)(y), the latter being the
curryfied version allowing partial application.

They also have a notation for partial application
of the non-curryfied form,  f(x,_) and f(_,y), with
the advantage that not only the last argument can missing.

The notation f(x,y) can be used for two different types of f
- (x:Int, y:Int) => Int  (no OCaml equivalent)
- (p:(Int,Int)) => Int   (OCaml: int * int -> int)
   In that case, f(x,y) is an abbreviation for f((x,y))

---
Sébastien

On 12/11/2017 07:30 PM, Gerd Stolpmann wrote:
> On 11.12.17 17:10, Ian Zimmerman wrote:
>> On 2017-12-11 15:40, Gerd Stolpmann wrote:
>>
>>> although, with currified functions this is only an illusion
>> As they say, "this".  The alternative syntax will lead to people never
>> learning about partial application.
>>
>> Does your own language curry multiple arguments by default like Ocaml
>> does?  If yes, then (IMO) your choice is a mistake, in spite of the
>> (good) arguments you give for it.
> 
> Yes, it does. I consider it only as a notation, and it's a compromise
> because
> 
> f x1 x2 x3 <=> ((f x1) x2) x3
> 
> doesn't work anymore as an explanation of how multiple args are
> (semantically) treated. It would read
> 
> f(x1,x2,x3) <=>
>    let f1 = f(x1) in
>    let f2 = f1(x2) in
>    f2(x3)
> 
> which works but is ugly and hides more than it explains. On the
> implementation side there is no difference.
> 
> But I can live with that. This language isn't intended to be used in CS
> courses, and the engineers diving deeper into it will still be happy
> that partial application works out of the box.
> 
> Gerd
>>
>> I would be more tolerant about such syntax in a SML-like language where
>> multiple arguments are modelled with tuples in most cases.
>>
>