I'm not sure that exposing a liftIO for Monad.Par is the best idea. Since all these parallel computations use runPar :: Par a -> a, it advertises that the result is deterministic. I'm not really comfortable with a hidden unsafePerformIO hiding in the background.
That said, I don't see a reason for not including a separate version of runParIO :: ParIO a -> IO a for non-deterministic computations. It seems really useful! Regards, - Clark On Wed, Oct 3, 2012 at 10:24 AM, Ryan Newton <rrnew...@gmail.com> wrote: > Several of the monad-par schedulers COULD provide a MonadIO instance and > thus "liftIO", which would make them easy to use for this kind of parallel > IO business: > > > http://hackage.haskell.org/packages/archive/monad-par/0.3/doc/html/Control-Monad-Par-Scheds-Direct.html > > And that would be a little more scalable because you wouldn't get a > separate IO thread for each parallel computation. But, to be safe-haskell > compliant, we don't currently expose IO capabilities. I can add another > module that exposes this capability if you are interested... > > -Ryan > > On Fri, Sep 28, 2012 at 4:48 PM, Alexander Solla <alex.so...@gmail.com>wrote: > >> >> >> On Fri, Sep 28, 2012 at 11:01 AM, Greg Fitzgerald <gari...@gmail.com>wrote: >>> >>> >>> I also tried Control.Parallel.Strategies [2]. While that route works, >>> I had to use unsafePerformIO. Considering that IO is for sequencing >>> effects and my IO operation doesn't cause any side-effects (besides >>> hogging a file handle), is this a proper use of unsafePerformIO? >>> >> >> That's actually a perfectly fine use for unsafePerformIO, since the IO >> action you are performing is pure and therefore safe (modulo your file >> handle stuff). >> >> unsafePerformIO is a problem when the IO action being run has side >> effects and their order of evaluation matters (since unsafePerformIO will >> cause them to be run in an "unpredictable" order) >> >> One common use for unsafePerformIO is to run a query against an external >> library. It has to be done in the IO monad, but it is a "pure" computation >> insofar as it has no side-effects that matter. Doing this lets us promote >> values defined in external libraries to bona fide pure Haskell values. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe