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