Recent ffi commits

[Alastair Reid]

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.