On 01/29/2012 11:55 PM, Edward Z. Yang wrote:
Excerpts from Mikhail Vorozhtsov's message of Sun Jan 29 05:34:17 -0500 2012: [snip]
I think it is one of the simplest layouts one can some up with. I'll try to explain the motivation behind each inclusion.
ABORTS(μ) ⊆ RECOVERABLE_ZEROS(μ)
I'm sorry, I cannot understand the discussion below because you haven't defined precisely what ABORTS means. (See also below; I think it's time to write something up.) ABORTS(μ) = { abort e | e ∷ e }
Why are they not equal? After all we can always write `recover weird $ \e → abort e`, right? But zeros from `RECOVERABLE_ZEROES \ ABORTS` may have additional effects. For example, recoverable interruptions could permanently disable blocking operations (you can close a socket but you can't read/write from it). Why the inclusion is not the other way around? Well, I find the possibility of `abort e1` and `abort e2` having different semantics (vs `recover` or `finally`) terrifying. If you can throw unrecoverable exceptions, you should have a different function for that.
RECOVERABLE_ZEROS(μ) ⊆ FINALIZABLE_ZEROS(μ)
If a zero is recoverable, we can always "finalize" it (by catch-and-rethrow).
FINALIZABLE_ZEROS(μ) ⊆ ZEROS(μ)
This one is pretty obvious. One example of non-finalizable zeros is bottoms in a non-MonadUnbottom monad (e.g. my X monad). Another would be `System.Posix.Process.exitImmediately`.
Ugh, don't talk to me about the exit() syscall ;-)
[snip]
Yes, I think for some this is the crux of the issue. Indeed, it is why monad-control is so appealing, it dangles in front of us the hope that we do, in fact, only need one API.
But, if some functions in fact do need to be different between the two cases, there's not much we can do, is there? Yes, but on the other hand I don't want to reimplement ones that are the same. I want to have a modular solution precisely because it allows both sharing and extensibility.
The cardinal sin of object oriented programming is building abstractions in deference of code reuse, not the other way around.
Stepping back a moment, I think the most useful step for you is to write up a description of your system, incorporating the information from this discussion, and once we have the actual article in hand we can iterate from there. I'll probably release an updated (and documented) version of monad-abort-fd when I have enough time. At the moment I'm just overloaded with work.