FFI Report, CVS Id 1.11

[Manuel M. T. Chakravarty]

Folks,

After another teaching-enforced pause, I have continued
working at the FFI Report:

  http://www.cse.unsw.edu.au/~chak/haskell/ffi.ps.gz

For C, the report should now be essentially complete (I have
included all the libraries).  There are, however, still some
outstanding issues (see the report and below for the gory
details).  For all calling conventions other than ccall and
stdcall, most is still missing.

My plan for driving this further is as follows:

* Get all but the most controversial outstanding issues for
  the language-independent and the C binding fixed until
  ICFP.

* Have a meeting at ICFP to nail any remaining issues in the
  language-independent and C binding as well as discuss how
  much we exactly want to do for other calling conventions
  and how we go about doing it.

Could everybody who is coming to ICFP and would like to
attend the meeting drop me a note please?  Just so that we
can fix when to meet.  I will be in Florence from Saturday
around noon until the following Friday (maybe even Saturday)
noon.

Cheers,
Manuel

PS: The source of the document is in cvs.haskell.org and at 
    <http://www.cse.unsw.edu.au/~chak/haskell/ffi.tex>.

-=- The Gory Details(TM) -=-

I went through all messages on this list that I hadn't
responded to yet and either included the suggestions or they
are discussed below.

"static" keyword
~~~~~~~~~~~~~~~~
Marcin wrote re removing the "static" keyword in C extents,

> What the lack of static takes away is the ability to import a function
> called "dynamic" or "wrapper". I don't think that it's a big limitation
> considering hundreds of names which are taken away by a Haskell's
> runtime system.

IHMO, it is one thing for an implementation to do that and
another for a language definition.

> Anyway, we could call them "_dynamic" and "_wrapper" to indicate
> that they are magical in some sense - using such names for external
> function names would be a violation of ISO/ANSI C rules (they are
> reserved for the C implementation).

*urgh*  I think, that's uglier than having "static".  So,
I'll stick with static unless there are serious counter
arguments. 

Backward compatibility
~~~~~~~~~~~~~~~~~~~~~~
Malcolm raised the issue of backward compatibility.  As I
understand it we aren't concerned about the definition
actually encompassing the syntax and semantics currently
implemented in GHC and NHC, but there is an understanding
that those system will allow the "old" syntax for a while
after they adopt the standard.

NHC's current implementation of "foreign export"  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~