From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q03MIkn0004085 for ; Tue, 3 Jan 2012 23:18:46 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjACAFF+A09KfVI0imdsb2JhbABDggWqVAgiAQEBCgkNGQYhgXIBAQEEEgITGQEbHQEDDAYFBAc7IgERAQUBHAY1oFUKi2WCa4Q/P4hxAgULjAQElQKNfT2Dew X-IronPort-AV: E=Sophos;i="4.71,452,1320620400"; d="scan'208";a="125475496" Received: from mail-ww0-f52.google.com ([74.125.82.52]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-MD5; 03 Jan 2012 23:18:41 +0100 Received: by wgbdr12 with SMTP id dr12so32782706wgb.9 for ; Tue, 03 Jan 2012 14:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bNOC6D8f5p1QMehgU2Tpts6X8DIGQ++N/eDG1FYtAe4=; b=bbroU2cPcit85IrYWY5+wbyHDA2JlDgKG7kSwlRMcilbF4F7OAHsRFim0L2SfVLnUF 8FRzBZlPkadaGfBpRWscMCYBVBybn3vKeV9Jl0IgVLhWVWkxZzmPz5RNgefjyp50MlQn eF7D1F8XGKZ7tYa26/BHUQM9h7NdNGGRxEtuQ= MIME-Version: 1.0 Received: by 10.227.200.206 with SMTP id ex14mr53666548wbb.11.1325629120904; Tue, 03 Jan 2012 14:18:40 -0800 (PST) Received: by 10.216.65.129 with HTTP; Tue, 3 Jan 2012 14:18:40 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Jan 2012 23:18:40 +0100 Message-ID: From: Diego Olivier Fernandez Pons To: Wojciech Meyer Cc: caml-list Content-Type: multipart/alternative; boundary=000e0cd5a0b0db002a04b5a71477 Subject: Re: [Caml-list] "Let"-less syntax for coreML --000e0cd5a0b0db002a04b5a71477 Content-Type: text/plain; charset=ISO-8859-1 Wojciech, > - ambiguity with structure equivalence operator - replacement of == would not be good as it is reserved for > physical equality Pointer equality is not coreML (not in SML, nor F#). Easy to fix anyway. - ambiguity in the parser, e.g. the toplevel let bindings are separated > by "let", the local lets by pair "let" and "in" > I thought about this one... that's the interesting point of forcing a single name on the left of the '=' sign f = fun x y -> x + y you can deduce this meant LET f = fun x y -> x + y and therefore know where the previous instruction ends because the two constructions are isomorphic. Say let g = fun x -> x + 1 in let f = fun x -> let v = g 0 in x + v becomes g = fun x -> x + 1 f = fun x -> v = g 0 in x + v with a unique semantic g = fun x -> x + 1 f = fun x -> v = g 0 in x + v You only need "in" for the return value of the function, all other elements being separated by an implicit ";" Notice that "fun" is also useless, the arrow alone shows it is a function g = x -> x + 1 but that feels a bit extreme. - ignoring "rec" - no good too - please see the other thread, it > contradicts how the aliasing of values is now used e.g. for extending > modules via. include > Easy to fix as well. Diego Olivier --000e0cd5a0b0db002a04b5a71477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0 =A0 Wojciech,
=A0
- ambiguity with structure equivalence operator=A0=
- replacement of =3D=3D would not be good as= it is reserved for physical=A0equality
=A0
Pointer e= quality is not coreML (not in SML, nor F#). Easy to fix anyway.

- ambiguity i= n the parser, e.g. the toplevel let bindings are separated
=A0by "let", the local lets by pair "let" and "in= "

I thought about this one... that= 's the interesting point of forcing a single name on the left of the &#= 39;=3D' sign

=A0 =A0 =A0f =3D fun x y=A0-> x + y

you can deduce this meant LET f = =3D fun x y=A0-> x + y and therefore know where the previou= s instruction ends because the two constructions are isomorphic.

Say

=A0 =A0 let g =3D fun x -> x + 1 in=A0let f =3D fun x ->= let v =3D g 0 in x + v

becomes

=A0 =A0g =3D fun x -> x + 1 f =3D fun x -> v =3D g 0 in x + v

with a unique semantic

=A0 g =3D fun x -> x + 1=A0
=A0 f =3D = fun x ->=A0
=A0 =A0 =A0 =A0 v =3D g = 0=A0
=A0 =A0 =A0in x + v

You only need "in" for the return value of the fun= ction, all other elements being separated by an implicit ";"

Notice that "fun" is also useless, the arrow= alone shows it is a function=A0=A0g =3D x -> x + 1 but that feels= a bit extreme.

- ignoring "rec" - = no good too - please see the other thread, it
=A0contradicts how the aliasing of values is now used e.g. for extending =A0modules via. include

Easy to fix as= well.

=A0 =A0 =A0 =A0 Diego Olivier
--000e0cd5a0b0db002a04b5a71477--