Malcolm wrote:
I don't know whether we are still worrying about backwards compatibility, [...]
I'm not sure about that either, but it would be a good thing if that was possible IMHO.
And so to declare the former kind of thing, we'd need foreign import "static static" foo :: t ?
I don't much mind either way, since it is a trivial and unlikely situation, but could someone clarify please?
Yep, you would have to write it in the way mentioned above. This breaks backward compatibility, but only on finitely many points, so this is probably acceptable.
I have added a restriction: exported variables must be defined by a function or pattern binding in the *same* module.
I had understood that this was always the case anyway. foreign export f :: t is the sole type declaration for f. Just as it is an error to have more than one type decl for f, so you can't write an additional f :: t in the same file. And just as you cannot write a type decl for an entity imported from a different module, you can't write a foreign export for an imported entity either.
I understood Manuel's restriction differently: You can only create an export named foo via foreign export ccall "foo" bar :: t if bar has a definition in the same module as the foreign decl above.
Again, I'm with Marcin. This restriction looks very artificial and ugly.
On the contrary, I think it is a very natural interpretation. That is also how it is implemented in nhc98, which is something I need to keep my eye on of course - I am not a type system hacker, and I'm afraid I wouldn't know how to implement it any other way currently.
I don't think that lifting the restriction as I understood it should pose any problems. NHC98 should be able to get a binding for an entity defined in another module... :-) Cheers, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de
These comments are based on revision 1.4. Some of these comments may be obsolete, since the discussion on the ffi mailing list indicates the design has changed since then. In section 1, Introduction: - the wording here could be improved by saying explicitly that maximal convience is not a design goal (currently it hints at that but doesn't say it explicitly) - it might help to talk more about different kinds of portability; portability between different Haskell implementations, between different foreign language installations, between different operating systems, hardware architectures, etc.,; source portability versus binary portability; and to explain more clearly which of these this proposal is trying to address. In section 1.2, - The phrase "on the same machine" should be avoided (see above point about different kinds of portability; this is referring to the wrong kind). - Should `CInt' be guaranteed to have the same representation as C's `int', or just the same range of values? In table 1 (Calling conventions): - The entries should be listed in alphabetical order (or grouped conceptually; the current ordering seems to be entirely random). In section 3, - it would help to explain which of these grammar rules are extending existing productions (is it just the new rule for `topdecl'), and which are productions for new non-terminal symbols (all the rest?). - Re "the varid before :: could be a `var'": yes, I agree, IMHO it should be. In section 3.1, - in /the language in which it is implemented/, s/the language/the source language/ -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
On Wed, Jun 13, 2001 at 04:22:16AM +1000, Fergus Henderson wrote:
- Should `CInt' be guaranteed to have the same representation as C's `int', or just the same range of values?
You can't discover the actual representation anyway. What it guaranteed is that you can write CInt on the Haskell side and it will correctly call a C function declared with int, and vice versa for exporting, with all values preserved, and that the Bounded CInt instance corresponds to INT_{MIN,MAX} in C, and that the Storable CInt instance works in the same way as storing ints under pointers in C, and some other instances should match the corresponding C behavior (these things are probably nowhere explicitly said but should be). How the Haskell implementation manages to provide it is its private business. For example in ghc all Int8, Int16 and Int32 (and Int64 on a 64-bit platform) have the same internal representation. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTĘPCZA QRCZAK
participants (3)
-
Fergus Henderson -
Marcin 'Qrczak' Kowalczyk -
Sven Panne