Comments (8)
I'm on the fence about it. On the one hand: I think encouraging MonadCatch
and MonadMask
is a bad idea, as they lead to confusing behavior in many common monads (see https://www.snoyman.com/reveal/monad-transformer-state and https://www.youtube.com/watch?v=KZIN9f9rI34). On the other hand, the RIO
case is completely safe, and adding the instances adds no extra dependencies. I'm open to input on this.
from rio.
I would love to see concurrency
working nicely with rio
, is it possible for concurrency
to stop relying on MonadCatch
and MonadMask
and replacing it with whatever rio
supports (I guess this is unliftio
)? Also, if concurrency
does this change, would it stop working with other tools?
I can relate why (even though it doesn't hurt) we would not like the RIO
monad to extend from MonadCatch
and MonadMask
.
from rio.
In principle concurrency
could stop relying on MonadCatch
and MonadMask
, but it raises some interface questions.
If MonadCatch
goes away, what does the type of forkFinally
become? Would there need to be two of them: forkFinally
, which doesn't catch exceptions; and forkFinallyWithExceptions
which does? Does MonadSTM
lose its MonadCatch
superclass too? If MonadMask
goes away, what happens to forkWithUnmask
and forkOnWithUnmask
?
I somehow get the feeling that there aren't that many people defining their own MonadConc
instances in the wild, so I'm fairly ambivalent about (assuming the naming problem could be fixed) splitting the class up into something like:
class (Monad m, Ord (ThreadId m), Show (ThreadId m)) => MonadConc1 m where
-- ...
class (MonadConc1 m, MonadSTM (STM m), MonadThrow m) => MonadConc2 m where
type STM m :: * -> *
throwTo :: Exception e => ThreadId m -> e -> m ()
atomically :: STM m a -> m a
class (MonadConc2 m, MonadMask m) => MonadConc m where
forkWithUnmask :: ((forall a. m a -> m a) -> m ()) -> m (ThreadId m)
forkOnWithUnmask :: Int -> ((forall a. m a -> m a) -> m ()) -> m (ThreadId m)
from rio.
from rio.
I woke up this morning with some more thoughts about this (what exciting dreams I must have been having!). I'll put together a branch splitting the class up, probably next week, and see what it's like.
There is, however, the question of where a MonadConc
(or whatever) instance for RIO
should live. The concurrency
package is supposed to be a drop-in replacement for Control.Concurrent.*, so I've kept its dependency footprint very light. The dependency graph grows quite a bit (and pulls in heavyweight things like text
) if I add rio
, so I would not want to provide instances in concurrency
. Similarly, rio
doesn't use concurrency
at all so I expect the rio
developers wouldn't want the instances in here. I guess the usual solution to that would be a concurrency-rio
package providing orphans.
from rio.
It seems like this is going to affect a number of instances besides MonadCatch
and MonadMask
. How about a rio-orphans
package for all of these? I'd say we even keep it in the same repo. I'll move ahead with a PR.
from rio.
A rio-orphans
package would be a great solution from my perspective. When that's out I'll make a concurrency-orphans
package with an instance for RIO
, as probably no-one but me wants to maintain MonadConc
instances.
from rio.
See #65.
from rio.
Related Issues (20)
- Show instance and showsPrec HOT 1
- documentation: it's not clear what the "source" argument to logInfoS and friends is for HOT 3
- missing a way to modify a logfunc to provide context HOT 5
- RIO.Process is running an "original" instead of a symbolic link HOT 7
- RIO.Process does not allow to Linux style operations on Windows and vice versa (or I didn't find the way to do it). HOT 1
- RIO module exports words :: String -> [String] HOT 1
- Lifting to Path HOT 1
- Multi-threaded logging HOT 2
- logOptionsHandle -> logSend is not thread-safe HOT 3
- A simple way to extend `SimpleApp`? HOT 3
- augmentPathMap assumes uppercase PATH on windows HOT 10
- Possible bug in RIO's MoandWriter (listen and pass) implementations HOT 2
- fold*1 variants for NonEmpty HOT 3
- Question: is there any chance to move logger to external library and expose some internals? HOT 3
- StrictData language extension HOT 1
- Explain how RIO.Vector relates to Data.Vector?
- Rio.Process shell (like proc) HOT 3
- HLint is triggered
- Unexpected omissions from submodule exports (e.g., RIO.Vector.iforM_) HOT 2
- How to improve integration with Haskeline or vty, using RIO with a terminal interface.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rio.