[Haskell-cafe] Monad-control rant

[Mikhail Vorozhtsov]

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.