While block and unblock have been removed from base, they are still
implementable
in modern GHC. So another possible future is to deprecate MonadCatchIO
(which should have been done a while ago, honestly!), but manually redefine
the functions so that old code keeps working.
Edward
Excerpts
Arie Peterson ar...@xs4all.nl wrote:
Would anyone have a problem with a deprecation of
MonadCatchIO-transformers, and a failure to update it to work with a
base without 'block' and 'unblock'?
Yes. This is a simplified variant of a monad I use:
newtype Continue f m a = Continue (m (Maybe
Ertugrul Söylemez e...@ertes.de wrote:
newtype Continue f m a = Continue (m (Maybe a, f (Continue f a)))
Typo:
newtype Continue f m a = Continue (m (Maybe a, f (Continue f m a)))
Sorry.
Greets,
Ertugrul
--
Not to be or to be and (not to be or to be and (not to be or to be and
(not
On Sun, Mar 3, 2013 at 6:07 PM, Ertugrul Söylemez e...@ertes.de wrote:
Arie Peterson ar...@xs4all.nl wrote:
Would anyone have a problem with a deprecation of
MonadCatchIO-transformers, and a failure to update it to work with a
base without 'block' and 'unblock'?
Yes. This is a
On Sunday 03 March 2013 17:07:18 Ertugrul Söylemez wrote:
Would anyone have a problem with a deprecation of
MonadCatchIO-transformers, and a failure to update it to work with a
base without 'block' and 'unblock'?
Yes. This is a simplified variant of a monad I use:
newtype Continue
On Mon, Mar 4, 2013 at 12:07 AM, Ertugrul Söylemez e...@ertes.de wrote:
Arie Peterson ar...@xs4all.nl wrote:
Would anyone have a problem with a deprecation of
MonadCatchIO-transformers, and a failure to update it to work with a
base without 'block' and 'unblock'?
Yes. This is a
Also I've seen at least one article about the incorrectness of
monad-control. That's one further reason I like to avoid it.
I'd appreciate a link if anyone could manage to find it. I haven't seen
any criticisms of monad-control.
Oddly, I just stumbled across
