Hmm. After experimenting a bit more, I think I'm going to give up on this particular project. I don't see a way to introduce a new IO without duplicating most/all of base and jhc. And even if I were to do that, it doesn't look like the result would work with FFI without requiring users to manually wrap FFI calls into IO from Jhc.Prim.IO. I find the idea of writing the Haskell runtime in plain old Haskell, simply by wrapping a less featureful IO very appealing, albeit likely to be less efficient. But alas, it doesn't look pleasant trying to work this as an option into Jhc. btw, I've gotten my Haskell IO monad to do exceptions as well as concurrency... although of course it can't handle errors in pure code without some sort of help... but then, that's inevitable. All implemented without even unsafePerformIO or unsafeInterleaveIO... which are themselves still unimplemented, and probably won't be able to spawn threads until such time as I move the ThreadState into an IORef or something of the sort. But then, an unsafePerformIO that spawns a thread that outlasts its result is a pretty unholy beast. David On Sat, Sep 5, 2009 at 8:08 PM, John Meacham<john@repetae.net> wrote:
An issue is that the newtype for IO needs to be in Jhc.Prim, Jhc.Prim is included as a dependency for every module because it has things that the compiler needs to exist no matter what you are building. This doesn't mean that Jhc.IO has to export it non-abstractly, and allowing it to be fully abstract is useful, but we need to move the actual newtype back into Jhc.Prim.
Just because an IO in Jhc.Prim exists, it doesn't mean you can't provide an alternate IO via a package of course.
You might be interested in Jhc.JumpPoint, which was the original implementation of IO exceptions. now, we actually have Grin primitives for continuations, though they arn't currently used, they may be useful for what you are doing. See 'MkCont' in Grin.Grin.
John