foreign import "static foo" foo :: t foreign import "static" foo :: t foreign import "" foo :: t
Is the last one nice?
(I still think that the "static" keyword is not necessary.)
How would you import a function named "static" then?
I don't know whether we are still worrying about backwards compatibility, but foreign import "static" foo :: t at the moment declares a function called "static" in the foreign language and "foo" in Haskell. Is the idea that, in the new scheme, this declares a function called "foo" in both Haskell and the foreign language, but with an attribute "static" in the foreign domain? 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?
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.
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. Regards, Malcolm