From: blue storm <bluestorm.dylc@gm...>  20080519 07:03:34

Sorry, silly mistake : fun b' > Some (a' + b') On 5/19/08, blue storm <bluestorm.dylc@...> wrote: >> 2) For [Option.enum], it's not a big deal, just a matter of >> uniformisation wrt other containers. I consider also adding [iter] and >> [filter]. > > Enum already have iter and filter. As it is supposed to provide a > common layer for those kinds of operation, i'm not sure iter and > filter are that useful. An of_enum would be useful, though (is it ok > for those function not to be one to one mapping ?). > >>> What's the use case for Option.enum? > > For example, if you have an enumeration of options, and you want to > "flatten" it into an enumeration of the base type (you're not > interested in the failure cases) : > Enum.concat (Enum.map Option.enum your_option_enum) > > > > Speaking of the Option module, I have a suggestion for a monadic > "bind" function (a celebrity in the Haskell world, would imho be > useful in OCaml too) : > > let bind f = function >  None > None >  Some v > f v > (patches against .ml and .mli attached) > > It looks very much like map, except that the given function decides > wether the result is a failure or a success. > > A typical use case would be the evaluation of an arithmetic AST (eg. a > Sum data type), with an "eval" function that can fail, and thus > returns an int option : > > let rec eval : ast > int option = function >  Num n > Some n >  ... >  Sum (a, b) > Option.bind (fun a' > Option.bind (fun b' > a' + b') > (eval b)) (eval a) > > Option.bind allows one to compose possiblyfailing operations. > > The parameters order (first the function, then the option) was choosen > to be coherent with the other functions of the Option module. > Haskellers are more used to the reverse order of the >>= operator (an > infix version of bind), with the option first, allowing for a more > natural style : > eval a >>= fun a' > eval b >>= fun b' > a' + b' > > I think keeping the old order is a good compromise for now (moreover, > the type is more elegant with the function first). If you're > interested in the >>= syntaxic sugar too, i'd be happy to provide such > an infix operator with reversed parameters. > 