FFI Report, CVS Id 1.11

[Simon Peyton-Jones]

Manuel

Excellent stuff.  Truly excellent.  

Simon


* I have many small wording suggestions, but I'll just perform them
directly.

* Still uncontroversial, I found 3.2 to be in a funny order. I'll
re-organise it slightly.

* I found 4.1 pretty confusing, and I'm an unusually well-informed
reader.
  a) It was some while before I realised that the first entity
production is
	only for foreign *import*.  The foreign *export* entity
production 
	and its accompanying text is embedded in the middle of a vast
swathe
	of foreign import stuff (both before and after!).   Let's have
sub-sections!

  b) Presumably an & import places constraints on the type?  Ah! That's
what
	you mean by "static address", and later "imported address".
Easy to
	be confused here.

Strong suggestion: give one example of each form in the
description-list.

  c) Explain that if there is no static/dynamic/wrapper, then static is
assumed.
	Mention why "static" exists at all.  (To allow entities called
wrapper.)

* 5.4.2 Talks of "foreign export dynamic".  Out of date!

* 5.5  I think foreignPtrToPtr had better have an IO type, else you
don't quite know
when it'll be called,. relative to the touchForeignPtr...   Oh-ho!  It
doesn't matter!  
 If it hasn't been called then the supended call keeps the foreign ptr
alive.  If it 
has been called, the touch will keep the foreign ptr alive long enough.
Cunning. But worth explaining!

* 5.5 description of withForeignPtr.   Similarly, should explain a bit
about this "not safe"
stuff. What we mean is that the foreign ptr may be finalised afer
withForeignPtr is done, so the Ptr may be unusable after that -- unless
you touch the ForeignPtr afterwards, in which case it's ok.... Careful
explanation needed.

| > PtrDiff
| > ~~~~~~~
...
| Haskell already uses Int for these kinds of lengths: array
| indices are mapped to Int, default implementations of list 
| functions use Int for measuring lengths.
| 
| On 64-bit processors Int is 64-bit (or 63-bit when targeting
| OCaml etc.), so the need of handling objects larger than a 
| gigabyte in 32-bit architectures is temporary, if at all. 
...
| What about peekArray etc.? It's not clear where to stop.

I must say that I rather agree with Marcin here.  Let's just use Int
(but not Int32!). On machines with big address spaces, Ints will be big.
Keep it simple. Oh, and efficient!

| ForeignPtr
| ~~~~~~~~~~
| 
| Why do we still allow ForeignPtr as an argument to a foreign
| imported function, now that we have withForeignPtr?  Is it 
| just for convenience? If that's the case, it would be 
| enlightening for the spec to say so (perhaps in a footnote).

I agree with this.

C Calls
~~~~~
| suggest that the entity string must always be present, but
| could be "".  I was wondering if there is any real difficulty 
| in permitting an empty entity string to be omitted 
| altogether? 

Makes sense to me, guv.  Makes the common case easy for Joe Programmer.

| Int and Word
| ~~~~~~~~~~~~
| You want to drop the assertion that "arithmetic is performed
| modulo 2^n" for sized Int and Word types, on the grounds that 
| this doesn't hold for Int.  But Int is not of fixed size, so 
| how could it require modulo arithmetic!  I happen to think 
| the fact that Int is of unspecified size >30 bits, with 
| undefined behaviour on overflow, was something of a mistake 
| in Haskell.  Now that we have the opportunity to define a 
| sensible overflow behaviour for fixed size types, I think we 
| should take it.

I agree with this.