From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q03JCWUE000666
	for <caml-list@sympa-roc.inria.fr>; Tue, 3 Jan 2012 20:12:32 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsCACNSA09KfVK2kGdsb2JhbAA5CoIFgwunSAgiAQEBAQkJDRsEIYFyAQEBAwESAg8EGQEBNwEPCwsPAgUhAgIPAQQNEwEFASITIodYApkOCoozaoMzAY1jB4EvhyeCI4EWlQaKb4MOPYN6
X-IronPort-AV: E=Sophos;i="4.71,451,1320620400"; 
   d="scan'208";a="137712588"
Received: from mail-we0-f182.google.com ([74.125.82.182])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Jan 2012 20:12:27 +0100
Received: by werb13 with SMTP id b13so15171261wer.27
        for <caml-list@inria.fr>; Tue, 03 Jan 2012 11:12:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=gamma;
        h=from:to:cc:subject:references:date:in-reply-to:message-id
         :user-agent:mime-version:content-type:content-transfer-encoding;
        bh=na4KkBhjyX91w/fgYzaoI9DLJjxt1mVJa+N37paG4rY=;
        b=R0lyXqq22RciAp2w/O0wLX+IaL5dU36iXiqyqNlcBOiGLS0ZHBps9dhmePu8Ogkmo/
         Res7BhbPYjWIZRMDUoeSRzWbsDB7snvY8pelwQGAI9HYpde4RYM6i7YM1URp7uctHbt4
         A/XEXK3sWzp08qz+sq7XJ5/6FuWJpI3DPSoAk=
Received: by 10.216.136.232 with SMTP id w82mr29579019wei.46.1325617947226;
        Tue, 03 Jan 2012 11:12:27 -0800 (PST)
Received: from spec-desktop.danmey.org (cpc1-cmbg12-0-0-cust201.5-4.cable.virginmedia.com. [86.9.116.202])
        by mx.google.com with ESMTPS id q5sm7248170wbo.8.2012.01.03.11.12.25
        (version=TLSv1/SSLv3 cipher=OTHER);
        Tue, 03 Jan 2012 11:12:26 -0800 (PST)
From: Wojciech Meyer <wojciech.meyer@googlemail.com>
To: Diego Olivier Fernandez Pons <dofp.ocaml@gmail.com>
Cc: caml-list <caml-list@inria.fr>
References: <CAHqiZ-L3_qx4sWUrxw57usJkguCb2wuBtRx6d_Gz9aucV_bsqw@mail.gmail.com>
Date: Tue, 03 Jan 2012 19:12:26 +0000
In-Reply-To: <CAHqiZ-L3_qx4sWUrxw57usJkguCb2wuBtRx6d_Gz9aucV_bsqw@mail.gmail.com>
	(Diego Olivier Fernandez Pons's message of "Tue, 3 Jan 2012 19:43:49
	+0100")
Message-ID: <wf4nwc38it.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q03JCWUE000666
Subject: Re: [Caml-list] "Let"-less syntax for coreML


Hi,

Diego Olivier Fernandez Pons <dofp.ocaml@gmail.com> writes:

>     List,
>
>
> I was wondering if there was any obstruction to the removal of the
> "let" keyword in a syntax for coreML.
>
> My reasoning is that because everytime there is a "let" there is also
> an "=" sign, we could completely remove the "let" and use the "=" sign
> instead to identify new symbol introductions.

>
> x = 1
> s = function x -> x + 1
> d = s 1
> o = function f g -> function x -> f (g x)
>
> The only cases to handle would be
> - comparison "=" sign : replaced by "=="
> - let rec : could be ignored or replaced by something else like "=|"
> - equational style 'let f x y = x + y' : forbid
>
> Does anyone see anything that could prevent this from being done ?

The problem here is that it would cause:

- ambiguity with structure equivalence operator
- ambiguity in the parser, e.g. the toplevel let bindings are separated
  by "let", the local lets by pair "let" and "in"
- replacement of == would not be good as it is reserved for physical
  equality
- 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

--
Wojciech