This site is updated infrequently. For up-to-date information, please visit the new OCaml website at ocaml.org.

Re: Revised syntax question
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: -- (:) From: Brian Rogoff Subject: Re: Revised syntax question
```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

```