Re: Syntax for label, NEW PROPOSAL

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

> > also i do want the fun: label (you may change the name, but a label
> > here is useful) to be able to write 
> > 
> > let sum l = List.fold_right acc:0
> >               fun:(fun long multi line function  definition here)
> > 
> > but i agreed that the acc label (in fun x acc:y -> x + y) is a pain,
> > because he forbid the use of usual function here 
> 
> I don't think this ``long multi line function  definition here'' is a
> really good argument. Several years ago, I thought the same, so that I
> defined *_on version of list functionals with list in the first place
> instead of at the end; for instance, I could write:
> 
> map_on l (fun x -> long multi line function)
> 
> Now I'm sure this is not the right solution to a real problem: the
> elegant way to deal with that is to name the function using a let.
> 
> let eta_expand x =
>  ... in
> 
> map eta_expand l.
> 
> Several arguments are in favor of a let binding:
> 
> - we still have only one functional and one way to call it
> - we have no unreadable long inline function definitions
> - the name we give to the function helps to understand its semantics
> - we can use the same construction in case of more complex function
> even in case of recursive function, where the fun x -> construct is
> hopeless (to solve this problem a ``fun rec'' construct have been
> proposed once, but the let rec way is much simpler, regular and
> elegant!)
> - the let way is a general solution to the general problem of long
> multi-line expressions in every construct of the language, including
> arithmetic operations.

There may indeed be good reasons for let-binding.
However, if you look at the sources of ocaml, you will see that in
many, many places such functions are defined inline without
let-binding. I see two reasons for that:
* you often don't want to think of a name for such a function
  (most of them are just 2 or 3 line long)
* it forces you to move the code around in a way that is not
  necessarily very natural. It's a bit like RPN: first define a
  function, then apply a functional to it.
  (We could of course ressucite the where clause :-)

More generally, my experience is that more freedom in the way to
layout them increases the use of functionals. After all there are many
ways to see the same function, different logical understanding of its
meaning. And the fact you can use all these ways with the same function
avoids confusion.

Why should we decide that one way is right, and others are wrong?

Jacques