You'll be glad to know that I'm going to let the repository recover for a couple of days while I hang out with my family. This also means I probably won't be able to fix anything I've broken for a couple of days so let's hope I didn't break anything too badly. Top items on my agenda when I get back to it are: - Making sure that the wrapper and dynamic import forms work The code is there - just need to check it works. - Test, test, test Sigbjorn promised to whack on it with HDirect generated code. Sounds like a great stress test. I should try building HGL using --target ffi. - Add something to the test suite. Has to be written so that the tests pass if ffi is disabled or not implemented. - Further contemplation of how to invoke the ffi generation and how/whether that should invoke the C compiler The current story is that hugs +G will generate a fresh .c file and link it to get a .so file for every .hs file it loads which contains ffi code. This will not look so clever when people install their code in read-only directories. - Autoconfiscation Mostly porting/stealing code from the GHC autoconf stuff. Code most needing fixed are HsFFI.h and the function compileAndLink in ffi.c - More libraries (CError, CTypes, ...) Would be easier if we had the hierarchial modules up and running since the GHC versions are close to what we want. Hmmm, didn't Sigbjorn commit a script to suck the tree over? - Finish the implementation of foreign export. The difficult thing about foreign export is that you can export a function at a more specific type than its Haskell type. For example: foreign export ccall "plus_Int" (+) :: Int -> Int -> Int The way to do this is to treat it as though the user had written: plus_Int :: Int -> Int -> Int plus_Int = (+) foreign export ccall plus_Int :: Int -> Int -> Int My problem is that I am completely baffled by the typechecker - I can't figure out how to do this. (Help with typeForeignExport in type.c very welcome.) (I'd feel bad about the length of this list of undone things if I didn't feel that the ffi is much closer to being usable than it was before I started.) I'm not sure how fast I'll get through this list though - I'm supposed to be choosing and booking a wedding venue and I did hardly any real paying work this week. So if anyone feels like claiming some of these tasks as their own, I'd be one happy Haggis. -- Alastair ps There's some longer term goals like: - Stripping the Hugs-specific code out of GreenCard - Removing any primitives that can be implemented by the ffi - Cleaning up internal naming schemes in Hugs. Hugs still talks about MallocPtrs - terminology that died at least 5 years ago. Addr is gone too. - differentiate between primitives (could be associated with any module) and foreign functions (associated with a very particular module). Take the opportunity to cleanup registerPrims which is pretty gross. But these can wait until the new ffi has proved itself.