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