Result monad

[Yaron Minsky]

We actually tend to a style where we use a ('a,Error.t) Result.t
(also known as an 'a Or_error.t), where an Error.t is essentially a
lazily constructed s-expression.  Obviously, once you do this, you
can't programmatically distinguish between different errors
effectively, but we like it better than the polymorphic variant trick
that Sebastien mentions, because of the god-awful type error messages
that leads to.

y

On Tue, Nov 27, 2012 at 4:11 PM, Malcolm Matalka <mmatalka at gmail.com> wrote:
> 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
>>>