Re: [Ocaml-lib-devel] [Batteries] First patch: Option, LazyList

[blue s. <blu...@gm...>]

Sorry, silly mistake :
   fun b' -> Some (a' + b')

On 5/19/08, blue storm <blu...@gm...> 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 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.
>