let ... in layout

let ... in layout

[Julian Assange]

let .. in
let .. in ...

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?

The only other haskell features I frequently miss, are list
comprehensions and multiple argument pattern matching.

Cheers,
Julian.

Re: let ... in layout

[Jean-Yves Moyen]

On 15 Mar 2000, Julian Assange wrote:

> 
> let .. in
> let .. in ...
> 
> 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?

I guess one can write:
let silly f=
  let x=List.map f z=3 in
    ...

which can be read either:
let silly f=
  let x=List.map f in 
  let z=3 in
    ...

or:
let silly f=
  let x=List.map in
  let f z=3 in
    ...

Of course, if your definition aren't mutually recursive, you can use 'and'
to separate two deifferent definitons:
let x=t
and y=u
and ...
and z=v in
  ...

which is not so long to write, unambigous and readable (I find).

> The only other haskell features I frequently miss, are list
> comprehensions and multiple argument pattern matching.

I don't understand exactly what you mean by 'multiple argument pattern
matching', but I guess you could just use a tuple-pattern matching:

let f a b c=
  match a,b,c with
    ...

which allows you to match several arguments at once.



Hypocoristiquement,
Jym.

Re: let ... in layout

[Benoit Deboursetty]

> 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.

Re: let ... in layout

[Julian Assange]

Jean-Yves Moyen <Jean-Yves.Moyen@loria.fr> writes:

> let f a b c=
>   match a,b,c with
>     ...
> 
> which allows you to match several arguments at once.

Sure, but

let f a b c =
   match a,b,c with
        0,1,2 -> 3

is a lot more cluttered than

f 0 1 2 = 3

This wouldn't really be an issue except that pattern matching is so
common. Intuitive brevity (as opposed to the brevity represented by
languages such as perl) is what makes both haskell and *ml so
readable. While both functions seem equally readable because they are
both small, once you have a screen full of them there is a significant
difference in clarity.

Cheers,
Julian.

Re: let ... in layout

[Pierre Weis]

> Jean-Yves Moyen <Jean-Yves.Moyen@loria.fr> writes:
> 
> > let f a b c=
> >   match a,b,c with
> >     ...
> > 
> > which allows you to match several arguments at once.
> 
> Sure, but
> 
> let f a b c =
>    match a,b,c with
>         0,1,2 -> 3
> 
> is a lot more cluttered than
> 
> f 0 1 2 = 3
> 
> This wouldn't really be an issue except that pattern matching is so
> common. Intuitive brevity (as opposed to the brevity represented by
> languages such as perl) is what makes both haskell and *ml so
> readable. While both functions seem equally readable because they are
> both small, once you have a screen full of them there is a significant
> difference in clarity.
> 
> Cheers,
> Julian.

You're right but this is not only a problem of syntax. There are
semantics issues to consider.

As for the syntax, your example is a bit contrieved, since there are
not that many functions with pattern matching on 3 arguments that has
only one match case. In general, such a complex function will have
many cases and then the (admittedly heavier) way of writing the code
in Caml gives you an extra benefit of naming the arguments, not
repeating the function name, and clearly exhibit the complete pattern
matching in one place:

let f a b c =
    match a, b, c with
    | 0, _, 0 -> a + b + c
    | ....

Also, the semantics of partial applications of curried pattern
matching is not clear: consider your f example

let f 0 1 2 = 3;;

What's the meaning of this definition ? Two interpretations have been
used in Caml:

let f1 a b c =
    match a, b, c with
    | 0, 1, 2 -> 3
    | _ -> raise Match_failure

let f2 = function
  | 0 -> (function
          | 1 -> (function
                  | 2 -> 3
                  | _ -> raise Match_failure)
          | _ -> raise Match_Failure)
  | _ -> raise Match_Failure

I guess f2 is more consistent with the usual semantics of ML, while f1
seems to be more natural for users:

with f2 partial applications will fail as early as necessary:
(f 1 raises Match_failure as the definition of g in let g = List.map (f 1)),

while with f1, application of f will fail only when 3 arguments are provided.

I guess that this is this semantic problem, and the new syntax to add
that prevents the addition of this feature to Caml.

Best regards,

Pierre Weis

INRIA, Projet Cristal, http://pauillac.inria.fr/~weis

Re: let ... in layout

[Dmitri Lomov]

Julian Assange wrote:
> 
> [skip]
> 
> The only other haskell features I frequently miss, are list
> comprehensions and multiple argument pattern matching.

Actually, comprehensions can be easily added using camlp4.
I did this as an excercise for O'Caml course last spring.
Source code is at:
ftp://young.tepkom.ru/pub/compr

The implementation supports list as well as array comprehensions.

> 
> Cheers,
> Julian.

Friendly,
Dmitri

_________________________________________________________________
Dmitri S. Lomov
mailto:dsl@tepkom.ru    ICQ#: 20524819 (Rusty)
http://users.tepkom.ru/dsl, http://young.tepkom.ru
ftp://young.tepkom.ru
+7 (812) 428-46-57 (b)   +7 (812) 295-94-15 (h)