FFI Report, CVS Id 1.11
simonpj at microsoft.com
Fri Aug 24 02:36:51 EDT 2001
Excellent stuff. Truly excellent.
* I have many small wording suggestions, but I'll just perform them
* 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
a) It was some while before I realised that the first entity
only for foreign *import*. The foreign *export* entity
and its accompanying text is embedded in the middle of a vast
of foreign import stuff (both before and after!). Let's have
b) Presumably an & import places constraints on the type? Ah! That's
you mean by "static address", and later "imported address".
be confused here.
Strong suggestion: give one example of each form in the
c) Explain that if there is no static/dynamic/wrapper, then static is
Mention why "static" exists at all. (To allow entities called
* 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
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
| > 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!
| 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.
| 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
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.
More information about the FFI