Re: Syntax for label
[
Home
]
[ Index:
by date

by threads
]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
Date:   (:) 
From:  Pierre Weis <Pierre.Weis@i...> 
Subject:  Re: Syntax for label, NEW PROPOSAL 
> > # 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 multiline expressions in every construct of the language, including arithmetic operations. Best regards,  Pierre Weis INRIA, Projet Cristal, http://pauillac.inria.fr/~weis