From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 0AA3A82355 for ; Wed, 13 Dec 2017 09:22:06 +0100 (CET) X-IronPort-AV: E=Sophos;i="5.45,397,1508796000"; d="scan'208";a="305249706" Received: from spica.irisa.fr (HELO [131.254.18.36]) ([131.254.18.36]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 13 Dec 2017 09:22:05 +0100 To: caml-list@inria.fr References: <6640cb32-fec3-e048-3f40-53d65bae5305@gerd-stolpmann.de> <20171211161024.kafvtxzq3qcoo46p@matica.foolinux.mooo.com> From: Sebastien Ferre Organization: IRISA Message-ID: <131064f1-4d53-5fbc-8aa7-0f6210dcb7bd@irisa.fr> Date: Wed, 13 Dec 2017 09:22:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-MW Content-Transfer-Encoding: 8bit X-Validation-by: sebastien.ferre@irisa.fr Subject: Re: [Caml-list] ReasonML concrete syntax 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. >> >