[EMAIL PROTECTED] 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.
[EMAIL PROTECTED] (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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
