Result monad

[Sebastien Mondet]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/core/attachments/20121127/fea364e4/attachment-0001.html>