From: blue s. <blu...@gm...> - 2008-05-19 06:59:04
|
> 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 possibly-failing 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. |