You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Process r a is defined as ReaderT (ProcessEnv r) IO a. Indeed, we don't want any other monad but IO as the base monad for processes (theoretically anything implementing MonadUnliftIO may work, dunno, but it's not really worth it since that's then limited to ReaderT and IdentityT anyway).
Now, it could make sense to have the internal implementation to be newtype ProcessT r m a = ProcessT (ReaderT (ProcessEnv r) m) a, and only export type Process r = ProcessT r IO in the public-facing API (and specializing all functions for it, as is already the case). Then, the implementation could be abstracted over MonadConc (or similar) and we could write tests using DejaFu or IOSim to validate certain behaviours.
Lots of opportunity for experimentation here.
The text was updated successfully, but these errors were encountered:
Currently,
Process r a
is defined asReaderT (ProcessEnv r) IO a
. Indeed, we don't want any other monad butIO
as the base monad for processes (theoretically anything implementingMonadUnliftIO
may work, dunno, but it's not really worth it since that's then limited toReaderT
andIdentityT
anyway).Now, it could make sense to have the internal implementation to be
newtype ProcessT r m a = ProcessT (ReaderT (ProcessEnv r) m) a
, and only exporttype Process r = ProcessT r IO
in the public-facing API (and specializing all functions for it, as is already the case). Then, the implementation could be abstracted overMonadConc
(or similar) and we could write tests using DejaFu or IOSim to validate certain behaviours.Lots of opportunity for experimentation here.
The text was updated successfully, but these errors were encountered: