From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA21987 for caml-red; Thu, 28 Sep 2000 09:20:00 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA20413 for ; Thu, 28 Sep 2000 06:36:49 +0200 (MET DST) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e8S4alX19462; Thu, 28 Sep 2000 06:36:47 +0200 (MET DST) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id VAA22198; Wed, 27 Sep 2000 21:36:42 -0700 (PDT) Date: Wed, 27 Sep 2000 21:36:42 -0700 (PDT) From: Brian Rogoff To: Daniel de Rauglaudre cc: Gerard Huet , caml-list@inria.fr Subject: Re: Revised syntax question In-Reply-To: <20000927075012.C5396@verdot.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: weis@pauillac.inria.fr On Wed, 27 Sep 2000, Daniel de Rauglaudre wrote: > But... but! I don't want to make a business with that. We can talk about > it, but I agree to change that into a completely symmetrical form like the > one you propose if we are numerous enough to accept that form. Besides, there > is the problem of the "let" inside sequences which my form does not allow. > > (Explanation: when you write in OCaml syntax: > e1; e2; let x1 = f1 in e3; e4 > actually, this sequence has 3 (not 4) expressions: > e1; e2; (let x1 = f1 in e3; e4) > since the binding x1 = f1 runs up to e4; in my syntax you have to write: > do e1; e2; return let x1 = f1 in do e3; return e4 > and I recognize it is ugly.) How many times did you bump into this coding, or is it mostly an abstract problem? I guess if you are sticking in debug info it is pretty easy to get it... > What about Michel Mauny's proposition for the sequence: > do { e1; e2; ... ; en } > > The braces remind C language, what is logical, since it is imperative. > The "let" up to the end of the sequence could be represented by "let > binding ;", i.e. ended by just a semicolon instead of "in": > do { e1; e2; let x1 = f1; e3; e4 } > > what would remind the "x1 = f1;" of C. > > The while and for constructs could be changed into: > > while e do { e1; ....; en } > for x = e1 to e2 do { e1; ...; en } > > with the same ability to write this "let x = y;" This looks good to me. My criteria involve simplicity, ease of explanation to beginners, and "just one way to do it", but I also think that imperative sequences should stick out "just a little" in a mostly functional language. This is nice and light, and loses the asymmetry that Gerard finds distasteful. As you say it has some syntactic compatibility with C (and Haskell :) and reduces the keyword count, though of course Gerard's proposal uses even fewer if we adopt it for loops too. > I can implement that if there are several persons who like it, > because, for the moment, I am used to "do...return ()" in my code, I > wrote a lot of code with it and I don't want to change it if three > days after, people tells me it is uglier. After thinking about it for two days I still think it looks OK. Maybe wait one more? :-) > I can also change my syntax tree to that form and accept > <:expr< do { e1; ... ; en } >> > as sequence syntax tree. > > I consider simple parentheses as not enough "sequence". When a > parenthesis is opened, if the expression is long, there is no way to > know whether it is a sequence or not. There is the same problem with > t-uples but generally, t-uples are shorter than sequences. I consider > that the language should clearly show sequences, even with a loss of > simplicity. I agree with this, sequences should be a little distinct. I don't know if we are at an impasse though, since this is a matter of taste. I can accept that do/done and do/return are too heavyweight, but does do { e1; ... ; en } add too much weight? It's hard to imagine a lighter solution without going all the way to ( e1; ... ; en ) so there's not much room left for compromise. I think either is acceptable, and is an improvement over the current state of affairs. -- Brian