Hi John, Here's a fix to my IO abstraction patch. I'll copy the text from my previous submission below for your convenience. The previous patch was missing a change that I made to Prim.hs, not realizing that it was autogenerated from names.txt. So I'm also sending a second patch adding extra comments indicating that Prim.hs shouldn't be edited. I feel like this is a good general policy: to clearly mark autogenerated files, so naive users won't accidentally edit them and fail to notice that darcs doesn't record those changes. David Here is the previous explanation of why I'm interested in changing the type of IO: This is an attempt to move towards the point where I could try implementing concurrent IO. I am not sure whether this approach will work at all, so I'll appreciate your feedback. I'll probably send a separate email with more details on what I'm thinking. This patch is essentially a cleanup, which moves the newtype of IO into Jhc.IO and avoids exporting its constructor. The hope is that I can later change the type of IO, perhaps to something like newtype OldIO a = IO (World__ -> (# World__, a #)) newtype IO a = IO { runIO :: (a -> ThreadState -> OldIO ()) -- ^ a continuation -> ThreadState -- ^ the current state -> OldIO () } -- ^ the combined computation although I'd also want to figure out how to work exceptions into the picture. Anyhow, I think this patch is reasonable on its own. My greatest uncertainty at the moment due to my lack of understanding of how you deal with FFI calls. i.e. how is the code for a delcaration like foreign import ccall "stdio.h jhc_utf8_putc" c_putc :: Ptr CFile -> Int -> IO () generated? I imagine that some work will have to happen in the core compiler in order for this import to generate a call to Jhc.IO.io (which is what I'd like). Sat Sep 5 12:38:02 EDT 2009 David Roundy <droundy@darcs.net> * try to abstract IO a bit Sat Sep 5 12:38:28 EDT 2009 David Roundy <roundyd@physics.oregonstate.edu> * add warnings not to edit auto-generated Prim.hs file.