Re: let ... in layout

[Benoit Deboursetty <debourse@email.enst.fr>]

> seems such a common construct in caml that it could do with some
> syntatic sugar. I often see let..in run to 5-20 clauses. This appears
> incredibly ugly compared to the equivalent haskell code, is harder to
> read and takes longer to write due to the clutter of the surrounding
> token magic. Has anyone thought about applying layout in general to
> ocaml, or otherwise sugaring let...in? Is there any reason why the BNF
> 
>         let {name = expr}+ in
> 
> would be ambiguous?

Plenty...

1. Because the equal sign is also the structural equality operator, there
is no way you could know that you begin another binding. With O'CaML now,
you can write
  let a x = f x = 3
which means
  let a x = ((f x) = 3)
where you would like
  let a x = f in
  let x = 3 in

So perhaps you would better want a reserved keyword such as "be" or "is"
to declare bindings.

2. But even there, there is another ambiguity between
multiple applications and function definition : think about the following
code...
  let a        = f x y z in
  let g x y z  = b       in

With your proposition this would turn into
  let a       is f x y z
      g x y z is b        in

Let us read this as a line :
  let a is f x y z g x y z is b in
           \_____________/
            where do you separate the two bindings?

So, anyway, we must separate two successive bindings with a keyword.
Perhaps you want a keyword that is an alias for "in let"...

Something you can do sometimes to reduce your number of "let ... in" is to
use
  let a, b, c = ..., ..., ... in (* 3 bindings at a time *)
which I believe is optimized by the compilers and finally completely
equivalent to
  let a = ... in let b = ... in ...
(except perhaps order of evaluation?)

If you do not like O'CaML grammar, I can only encourage you to use the
excellent "caml preprocessor and pretty-printer" (camlp4) to modify it.
http://caml.inria.fr/camlp4
It is much easier to use camlp4 than to write your own parser!!

When you can write both a parser and a pretty-printer for O'CaML and when
you can translate automatically from the original syntax to the other and
vice-versa, you know you have done something which is not ambiguous.

Best regards,
BdB.