Result monad

[Malcolm Matalka]

Thanks for pointing that out, I actually ran into it this weekend and
didn't get what was going on.  I ended up just handling every failure in
all cases, which is excessive but not so bad in this case.

Sebastien Mondet <sebastien.mondet at gmail.com> writes:

> Hi
>
> We've been doing that for a few months (e.g.
> https://github.com/biocaml/biocaml/blob/master/src/lib/biocaml_fastq.mli )
>
>
> In a sense it's great (and we plan to keep doing this):
> - polymorphic variants force the exhaustiveness of pattern matching (so you
> do not forget error cases)
> - (infered) function types fully document anything that may happen inside a
> function
>
> There are a few annoyances to keep in mind:
> - the error types must remain open so that ocaml can merge them ( [> ... ])
>   * sometimes this gets in the way, and you spend time type-hacking only
> for errors that never happen
>      (e.g. if you want to put a function in a record/object you have then
> to play with "type 'error t =  { x : ... -> (..., .... as 'error) Result.t
> }" etc.)
>   * sometimes it's difficult to "reopen" polymorphic variant types
> - pattern matching does not know how to remove cases:
>   match error with
>   | `db_error e -> .... return ()
>   |  other_error -> error other_error (* without annotations, [> `db_error
> ... ] will remain part of the total error type *)
>
>
> Cheers
> Seb
>
>
>
>
>
>
>
> On Tue, Nov 27, 2012 at 3:27 PM, Malcolm Matalka <mmatalka at gmail.com> wrote:
>
>> I've been playing with writing code that can fail in a lot of ways and
>> using Result.Monad_infix to make it more readable.  I've found that this
>> only really works well if all of my functions that return a Result.t
>> have polymorphic variants on the Error side.  Is this the suggested best
>> practice as well?  I'm considering just mandating all my code that can
>> return a Result.t does this.
>>
>> Thanks,
>> /Malcolm
>>