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: FFI Definition
Sven Panne [EMAIL PROTECTED] wrote, Manuel M. T. Chakravarty wrote: [loading dynamic libs problem] This is just like the library object specification that we have now also. Huh? What? I've never seen a lib object spec... (or completely forgot it %-) Like so foreign import ccall libgtk.so gtk_widget_destroy gtk_widget_destroy :: Addr - IO () [static/dynamic + callconv] Meanwhile, I think, you are right, we cannot make a clean language-independent static/dynamic distinction. The callconv already prescribes the syntax of ext_ent and the typing, so it could prescribe the possibilities for mode, too. And static/dynamic makes sense e.g. for cplusplus and jvm at least, with a slight reinterpretation of the actual meaning, but that's not very crucial. I'm against stuffing everything into ext_ent in a string form, which would mean a mini-language within Haskell (TCL is lurking! :-). My proposal: -- allowed for import/export mode : 'static'-- allowed for ccall/stdcall/cplusplus/jvm/..., default then | 'dynamic' -- allowed for ccall/stdcall/cplusplus/jvm/... | 'interface' -- allowed for jvm | ... The current idea is to make the syntax of the FFI extension independent of the supported languages. This requires to stuff everything into `extent'. Sure, this will make the `extent' string complex for some languages, but that's inevitable for anything but C anyway. The old design really benefitted from that we basically considered C only. The goal now is to bring the whole thing into better shape for supporting multiple languages and being open for addition of new calling conventions later. And for legacy reasons we have to keep dynamic for some time, anyway. Let's forget about the legacy stuff for the FFI definition. The systems have to support the legacy syntax, but that's really of no concern for the definition. Also should 'label' be there? Doesn't make sense for Java, does it? Hmm, not really. So, also into `extent'... But it *makes* sense for some calling conventions, and it the actual translation will need the callconv (name mangling!), so the only change I propose here is a comment: fkind: 'import' | 'export' | 'label'-- allowed for stdcall/ccall/cplusplus Hmmm, looking at the whole foreign beast gives me a slightly uneasy feeling now. There are loads of strongly interconnected side conditions, but I fear we can't avoid this because of the complexity of the whole topic. But at least we should strive for an ext_ent with minimum complexity when we go the special id way, like we did in the past. The other design, which I believe is cleaner (and which I understand as the consensus at the HIM meeting), is to get rid of all the side conditions and put all the calling convention dependent stuff into `extent'. The latter is calling convention dependent and complicated (for everything but C) anyway. So, let's at least keep the rest simple. In fact, any system supporting a calling convention like jvm, will have to have a parser for extent strings anyway. Another extreme route would be: topdecl : 'foreign' string var '::' type with a separate syntax for the string contents. Yes that's going into the right direction, but it makes sense to leave both the calling convention as well as import/export out of the string. The calling convention defines which parser to use in the string. That's good for implementers, because then, the parser can be chosen before parsing starts. The import/export information is needed by the name analysis, which we better leave independent of the whole extent mess. In other words, having the calling convention and import/export seperate facilitates more modular compiler support. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: FFI Definition
There is now an updated version of the document at
http://www.cse.unsw.edu.au/~chak/haskell/{ffi.ps.gz,ffi.tex}
The LaTeX file is to make citing from the document easier
(as suggested by Fergus). To compile it, you need a style
file which I first have to polish a little more before I put
it on the net (will all happen in due course).
The new version includes the feedback so far. The main
change is that label, static, and dynamic are now part of
`extent' for `ccall' and `stdcall'. It still has many gaps,
but I think it is important to regularly post updates even
if the delta is not very big.
Cheers,
Manuel
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Re: FFI Definition
Mon, 07 May 2001 00:14:32 +1000, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze: The import/export information is needed by the name analysis, which we better leave independent of the whole extent mess. Export dynamic introduces a name, export static exports an existing name. For that reason putting this distinction in extent seems strange for me. -- __( 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: FFI Definition
6 May 2001 15:50:16 GMT, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] pisze: Export dynamic introduces a name, export static exports an existing name. For that reason putting this distinction in extent seems strange for me. Moreover, export dynamic and import dynamic don't have fname or cid. foreign import dynamic is a shortcut for importing an automatically generated C function which could be easily written by hand. It fits well into regular imports with a single distinguished magical extent. All parameters are in the type, so it can be called dynamic or curry or apply or whatever, perhaps with special characters to distinguish the name from plain functions. foreign export dynamic is a shortcut for importing an automatically generated nontrivial C function, with argument type not conforming to regular imports, which could not be written by hand. So it's actually an *import*! It could be spelled as import with a magical name - again all parameters are in the type. -- __( 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: FFI Definition
Sorry for lots of small messages. 'label' can be spelled ''. It's IMHO more intuitive, and reminds that we get a pointer in Haskell and not the dereferenced value. foreign import stdscr stdScr :: Ptr Window -- __( 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: FFI Definition
foreign export dynamic is a shortcut for importing an automatically generated nontrivial C function, with argument type not conforming to regular imports, which could not be written by hand. I don't get it. How do you use a function with a type like: (Int - IO Int) - Addr to import a C function? The closest I can get is to use foreign label to get an Addr (or FunPtr if preferred) but now I'm stuck. What's up? So it's actually an *import*! It could be spelled as import with a magical name - again all parameters are in the type. But it is also used for exporting so the name doesn't seem that inappropriate. Unless you're arguing that, since it brings a name into scope it can be thought of as a kind of import??? (But I don't think you are saying that.) -- Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/ ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: FFI Definition
Sun, 6 May 2001 11:29:18 -0600 (MDT), Alastair Reid [EMAIL PROTECTED] pisze: foreign export dynamic is a shortcut for importing an automatically generated nontrivial C function, with argument type not conforming to regular imports, which could not be written by hand. I don't get it. How do you use a function with a type like: (Int - IO Int) - Addr to import a C function? *This* is an imported function. Well, if I wanted to make it by hand, I would have to make a StablePtr before, because I can't pass (Int - IO Int) to a foreign function directly. In other words foreign export dynamic exp :: (Int - IO Int) - IO Addr is equivalent to exp :: (Int - IO Int) - Addr exp f = exp' = newStablePtr f foreign import exp' :: StablePtr (Int - IO Int) - IO Addr -- exp' generated by the Haskell compiler. Unless you're arguing that, since it brings a name into scope it can be thought of as a kind of import??? (But I don't think you are saying that.) I am! -- __( 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
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: FFI Definition
Marcin 'Qrczak' Kowalczyk wrote: 'label' can be spelled ''. It's IMHO more intuitive, and reminds that we get a pointer in Haskell and not the dereferenced value. foreign import stdscr stdScr :: Ptr Window Nice. :-) Cheers, Sven ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
