Repository navigation
Allow sequencing evaluations relative to io actions #1
Description
Activity
I have added a test for runEvalIO (Borgvall@7ee1026) and implement it using the classic Eval implementation using
Done(Borgvall@563bb87).I think there's a much simpler way to accomplish this in vaguely recent compiler versions:
{-# Language GeneralizedNewtypeDeriving #-} newtype Eval a = Eval (IO a) deriving (Functor, Applicative, Monad) runEval (Eval m) = unsafePerformIO mExposing the newtype constructor from an "internals" module would give users maximal flexibility, but barring that, exposing wrapping and unwrapping functions seems reasonable.
If you propose to change the internal implementation of
Eval, please open a new issue. It would have a much greater impact, and needs broader discussions.I think, that sequencing evaluations relative to io actions should be part of the external interface.
The reverse (
IO -> Eval) would break the basic idea of the parallel package!- added a commit that references this issue
on Jun 2, 2018
It is sometimes useful to sequence the evaluation relative to IO actions. For instance one might spark a computation in parallel, while the main thread is waiting for further input.
I have written a (ghc only) patch that provides functions that allow this (Borgvall@3d5b0fb). You might consider merging it.
The downside is, it depends on the internal representation of IO and Eval, and adds functions to the external interface.