Re: FFI Definition
[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
Re: Revised FFI syntax + typing
Simon Marlow wrote: A totally minor point, but 'wincall' doesn't feel right. [...] I'd stick with 'stdcall' because that's what everyone else seems to call it. gcc has a 'stdcall' function attribute, BTW. OK, so let's forget about 'wincall' and continue using 'stdcall'. Inventing new names for things already in existence is not a very good plan. Why is Word a GHC extension? Someone remind me? Hmmm, I thought that the Word type itself is a GHC extension, the hslibs docs for module Word only talk about the explictly sized variants. OTOH the implementation exports Word, but for legacy reasons, IIRC. If this is really the case, we should document this somehow in the sources. Cheers, S. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: Revised FFI syntax + typing
Why is Word a GHC extension? Someone remind me? It's not part of the Hugs-GHC standard which is what we were working to when the ffi first came out. It's not part of that standard because it was felt at the time that bounded types with ill-defined ranges were a portability problem waiting to happen. (The alpha was still a viable machine back then and we genuinely believed that Intel were going to produce a 64 bit processor in the near future.) The fact that it's in there at all was just for backward compatability reasons. If we'd had DEPRECATE then, we might (???) even have deprecated it? -- A ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Revised FFI syntax + typing
Thu, 03 May 2001 22:34:50 +0200, Sven Panne [EMAIL PROTECTED] pisze: Hmmm, I thought that the Word type itself is a GHC extension, the hslibs docs for module Word only talk about the explictly sized variants. OTOH the implementation exports Word, but for legacy reasons, IIRC. Rather the opposite: I let it export Word not so long ago, together with adding some instances. But unboxed arrays of Words were present long before that: ByteArray (deprecated), MArray, IArray. I don't agree that having a type of a fixed but unspecified size is evil. You can query the sise - you don't have to assume any particular size - and you have explicitly sized types as well. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: Revised FFI syntax + typing
I don't agree that having a type of a fixed but unspecified size is evil. You can query the sise - you don't have to assume any particular size - and you have explicitly sized types as well. I suspect we're never going to agree about this but perhaps we can try to understand why the other feels the way they do - so I'd like to briefly (re)state why implicitly sized types disturb me so much. There's many possible ways of classifying different portability problems but one of the most important is: 1) Portability problems that can be mechanically detected. This includes missing libraries/header files, libraries and header files installed in the wrong place, missing functions and methods, functions with the wrong type and semantic differences so gross that even the lamest testing will detect the problem. Fixes tend to require conditional compilation. 2) Portability problems that are hard to detect mechanically. This mostly consists of subtle semantic differences that require somewhat carefully designed test cases to detect. Fixes may require conditional compilation but more usually require small subtle changes to the code to ensure that the code doesn't tickle such differences as exist. Usually all that remains is a comment which explains why something is coded in a slightly unnatural way. [If we replace mechanically detected with statically detected, then even gross semantic differences would be in the second category. It makes little overall difference to the argument though.] The first kind is, in some ways, most annoying because it is very visible: the code just won't compile/link until I fix it and the fixes to make it compile remain as an ugly scar on the code. But I feel that the second kind is worse precisely because it is so hard to see: if the code has not been written with those subtle semantic issues in mind it may contain such errors; if the code is modified by someone who didn't consider those issues, it may contain errors. I agree that it is possible to write portable code with implicitly sized types but I am very concerned that it is very easy to write non-portable code containing the second type of portability problem. Using explicitly sized types doesn't avoid all overflow-related errors but at least it makes them appear more consistently and, thanks to the sheer ugliness of the names (Int32, Int8, etc.) it is harder to forget about overflow issues. -- Alastair ps On reflection, I find your example (from last week) of doing radix sorts on Ints a good example of where you would naturally want to be able to do bitwise operations on Ints. I'm not sure if I find it compelling enough to add a Bits Int instance but at least I now know of one example where one might legitimately want to. In the absence of a Bits Int instance I would have to write the code like this: -- this code to go in the same file as the code that assumes that -- Int and Int32 are isomorphic #if sizeof_Int == 32 type Intlike = Int32 toIntlike = intToInt32 -- or fromIntegral fromIntlike = int32ToInt #elif sizeof_Int == 64 type Intlike = Int64 toIntlike = ... fromIntlike = ... #else #warning ... #endif radix_sort :: [Int] - [Int] ... rest of code converts to/from Intlike every time it does a bitop Yeah it's a bit ugly but at least it makes the assumptions it relies on fairly explicit. Even without a comment (which would be a worthwhile addition), the explicit conversions and the ifdefs make it fairly clear that we're assuming some kind of isomorphism to exist. It is unfortunate that protecting against potential portability issues is unnecessary for radix sort. To some degree we are used to that sort of thing though: there are some perfectly safe Haskell programs that the GHC/Hugs typesystem will not let me write. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
