Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[OSR] Exceptionless error management, take 2
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-02-11 (12:53)
From: David Teller <David.Teller@u...>
Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2
I'm not sure where you see approach 2. 

My suggestion deals with approach 1, while Daniel's is approach 3. The
point of monads is not related to converting exceptions, but rather to
being able to compose functions without having to add a manual check at
each step. And the point of this "optimized" monad implementation is
just to make that faster.

If the confusion is caused by my answer to your previous post, I just
realized that my fixing your "bind" was a mistake. Please accept my
apologies, I misread what you had written.

Now, if this candidate is too confusing -- which I can't judge, as I
wrote it -- perhaps something less confusing would be more appropriate. 


On Mon, 2008-02-11 at 07:12 -0500, Yaron Minsky wrote:
> Something about this whole error-handling proposal confuses me.
> Here's my concern: I can see 3 approaches, all having to do with what
> goes in the 'b slot in the ('a,'b) status type:
>      1. Use different, wholly incompatible types in 'b.  This allows
>         you to put useful information into the signature of each
>         error-producing function, but basically requires individual
>         handling of each error.  No monadic magic and no conversion to
>         exceptions is possible, and each error must be handled
>         individually.  It's more explicit and more verbose.
>      2. Use the same type in 'b everywhere.  There's no extra
>         explicitness here, and I don't actually see any advantage over
>         just using exceptions.
>      3. Use different but compatible types, e.g., polymorphic
>         variants.  Then you get both explicitness and the chance to
>         use monadic or other tricks to join together the errors at the
>         type level.  That has some clear advantages (the type system
>         can infer for you the ser of all possible error messages), but
>         we've found it leads to some sticky type error messages in
>         some cases.
> So, I understand why someone would try (1) or (3), but (2) seems
> utterly pointless to me.  The proposal seems to be aiming at (1), but
> then there's all this talk of monads which doesn't seem to fit (1).
> Am I missing something?
> y
David Teller
 Security of Distributed Systems
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations.