RE: Revised FFI syntax + typing
Simon Marlow [EMAIL PROTECTED] wrote, 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. I don't think I have any strong feelings either way. Word has a pleasing symmetry with Int, but on the other hand if it isn't useful then we should omit it. I agree in principle with Alastair's portability argument, but don't think it is worth applying for this particular case since we already have Int. I mostly agree with Simon. There is no point in trying to fix a problem that H98 already introduced. The H98 Committee in their infinite wisdom chose to have types with system-dependent sizes and I think, we should be as orthogonal as possible whether we like it or not. Moreover, 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 Interesting language, but can anyone remind me what these #if etc are supposed to me - I can't find them in the Haskell report. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Revised FFI syntax + typing
Sven Panne [EMAIL PROTECTED] wrote, 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. As I seem to be the only one who is really against stdcall, let's revert to it *sigh* Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: Revised FFI syntax + typing
Interesting language, but can anyone remind me what these #if etc are supposed to me - I can't find them in the Haskell report. They're not? But I see code like that all over the place. There is no point in trying to fix a problem that H98 already introduced. The H98 Committee in their infinite wisdom chose to have types with system-dependent sizes and I think, we should be as orthogonal as possible whether we like it or not. But H98 doesn't have Word so I don't see a requirement to add it or to provide ffi support for it. -- Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/ ps As I understand it, underspecifying the size of Int in Haskell 1.0 was largely to allow compilers to use one or two bits as tags to distinguish boxed values (pointers) from unboxed values (ints, chars, etc.). In particular, this lets Haskell compilers generate Lisp code (since Lisp compilers often use that GC trick and lack the type information which would make it redundant). No current Haskell compilers use this trick (it's not very effective in lazy/polymorphic languages). Hugs comes close but, though it would be easier to provide ints with restricted range, it opts for providing a full 32 bits. (The decision to do this predates my involvement with Hugs.) The other reason for doing it is the hope of going a little bit faster on 64 bit machines. I'm not sure if there actually is a performance benefit or if it is significant. pps I'm assuming that UShort and the like have system-dependent sizes but I'm not objecting to them because it's just not possible to work with C without making the types match up - Int8 and friends don't go quite far enough towards speaking C's language. Pretty much every ffi interface I've ever written starts by figuring out the sizes of each of the major C types and selecting the corresponding explicitly sized Haskell type to represent it. ___ 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? 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. I don't think I have any strong feelings either way. Word has a pleasing symmetry with Int, but on the other hand if it isn't useful then we should omit it. I agree in principle with Alastair's portability argument, but don't think it is worth applying for this particular case since we already have Int. Cheers, Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: Revised FFI syntax + typing
I know that this is a silly argument, but Word is used internally in
RULES for fromIntegral to generate good code for conversions between
sized integers.
Since Word{8,16,32} and sometimes Word64 is represented as data-wrapped
Word#, it's easy to implement many conversions by delegation to the
conversion with source or target type replaced with Word.
This was actually what triggered me to add missing instances for Word
(Num and Integral were needed).
--
__( 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
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
RE: Revised FFI syntax + typing
-- allowed for import/export callconv : 'ccall' -- default | 'wincall' | 'stdcall' -- deprecated, same as wincall | 'cplusplus' | 'jvm' | 'dotnet' 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. word_ty : 'Word8' | 'Word16' | 'Word32' | 'Word64' | 'Word'-- GHC extension Why is Word a GHC extension? Someone remind me? Cheers, SImon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
