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.