> > # let sum l = List.fold_right fun:begin fun x acc:y -> x + y end acc:0;;
> > val sum : 'a -> int list -> int = <fun>
>
> here, i prefer to use parenthesis as :
>
> let sum l = List.fold_right fun:(fun x acc:y -> x + y) acc:0;;
>
> it's more readable
:)
Me too, ``here, i prefer to use parenthesis as :'' List.fold_right ( + ) 0
> 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.
Best regards,
-- Pierre WeisINRIA, Projet Cristal, http://pauillac.inria.fr/~weis
This archive was generated by hypermail 2b29 : Fri Mar 17 2000 - 11:31:06 MET