malcolm-ffi@cs.york.ac.uk wrote,
This document looks like a very good starting point.
* An omission: 'foreign label'.
Oops.
* Perhaps the 'specialid' production should contain all the calling convention identifiers?
Yes, I had a weird idea here, but realise now that it doesn't work anyway. qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,
Your syntax puts modifiers between the calling convention and the external id. I agree that it's consistent. Currently ghc accepts unsafe only between the external id and the Haskell id, and dynamic only instead the external id.
Yes, the idea was that this has to be changed in GHC. Sven Panne <Sven.Panne@informatik.uni-muenchen.de> wrote,
* Because of the reason stated above, I think static/dynamic *must* come first after import/export, but the order of unsafe/safe, callconv, and extent should not matter. The var (*not* varid, it was a design flaw IMHO)
I agree.
must be the last thing before the colon, otherwise it tends to drown in the syntax.
Yes.
* I don't understand the last part of section 3.2.1, mentioning the loading of dynamically loaded libs. Is something like dlopen() meant here or linking against a libfoo.so? And the details of how/when this linking should be done are completely obscure to me.
This is just like the library object specification that we have now also. "Simon Peyton-Jones" <simonpj@microsoft.com> wrote,
| > language specific stuff inside the "..." string | > language independent stuff outside | | But static/dynamic probably means different things, depending | on the callconv.
I think it's arguable that static/dynamic should be inside the ext_ent string. Indeed, one might use static/dynamic for ccall, and virtual/non-virtual/static for Java, etc. "Baking in" static/dynamic for all languages may be inappropriate.
Nevertheless, you propose keeping 'mode' outside the ext_ent string. Why? (Apart from backward compat.)
Meanwhile, I think, you are right, we cannot make a clean language-independent static/dynamic distinction.
Also should 'label' be there? Doesn't make sense for Java, does it?
Hmm, not really. So, also into `extent'... "Simon Marlow" <simonmar@microsoft.com> wrote,
A totally minor point, but 'wincall' doesn't feel right. This alternative calling convention has been around since long before windows (it's always been the default calling convention for Pascal, I think).
I'd stick with 'stdcall' because that's what everyone else seems to call it. gcc has a 'stdcall' function attribute, BTW.
Ok - so who prefers `stdcall' and who something else. BTW, I have only included C++ for the sake of completeness into the calling conventions. As nobody is actively working on this - or is there? - I am quite happy to not define anything about it, but the name of the calling convention. Better no definition than an untested one. Cheers, Manuel