- FFI - Haskell.org

extent strings
by Alastair Reid 15 May '01

15 May '01

As the extent strings acquire more structure, I'm starting to wonder if encoding the information in strings is the right approach. What's the advantage of putting the information in a string? 1) All Haskell parsers will be able to read any ffi-ified code even if they don't support the language binding the ffi supports. But what does this achieve if the compiler backend doesn't support that ffi? 2) Avoids problems trying to forcefit Java/C/C++/... identifiers/keywords into Haskell and avoid the (ever-growing) set of Haskell keywords. But this could be done by using "" as an escape mechanism whenever there's a conflict. For example, suppose I wanted to foreign import a function called "class" using currently implemented ffi syntax. I just put "" round the offending identifier and I'm done: foreign import "class" clazz :: <whatever> 3) Might be easier to generate good error messages when the language just isn't supported by that compiler. As long as the "language/calling convention" keyword appears near the start of the foreign decl, I think this is easy to do without packing everything into strings. What's the disadvantage of having highly structured strings as part of the ffi spec? There's no big technical issue that I know of but as the strings get more complex (i.e., as we start to write a grammar for them), alarm bells start to go off in my head: o Having a grammar for parsing strings seems to break the classic language structure of: lexical structure context free syntax static semantics dynamic semantics o Reminiscent of C++'s extern "C" declarations. In itself this isn't necessarily bad - but every time I see one of those decls, the word "ugly hack" springs to mind. I suspect that making these strings even more structured would make the hack look worse. o It seems simpler to have just one grammar for Haskell rather than to split it into two separate grammars. By this, I mean, two logically separate grammars (as in the current proposed syntax) instead of two physically separated grammar (as, for example, if someone were to provide a grammar for the C++ ffi binding as appendix G to the report). Is anyone else concerned about this or am I just pissing in the wind? -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

2 1

RE: Again: FFI Syntax
by Simon Marlow 14 May '01

14 May '01

> So let's simply say: The contents of the include part of > extent are implictly > wrapped into double quotes iff they don't start with '<' or > '"', and no ".h" > is appended. Easy rule, doesn't mix concepts, and is readable: > > foreign import ccall "static !myproc myinclude.h" myProc :: ... I agree: don't make the '.h' implicit. To me it looks much more readable when it's obvious which is the cid and which is the include. Cheers, Simon

1 0

RE: Again: FFI syntax
by Simon Marlow 14 May '01

14 May '01

> * Silly combinations like "an unsafe label" or > "a dynamic import with a given C-name" don't exist. But now we have all new silly combinations, like foreign export "dynexp" foo :: ... and foreign export "dynimp" foo :: .... and foreign export "&foo" foo :: ... the extent field needs to be separated into import-extent and export-extent, I think. Can we make the "static" optional? It wouldn't introduce any ambiguity, and it would save characters in the common case. I like '&', but I'm less sure about '!' - this feels like we're getting a little too cryptic. Cheers, Simon

1 0

RE: Again: FFI syntax
by Simon Peyton-Jones 14 May '01

14 May '01

| Comments? We should really come to an agreement on the syntax soon... Generally, I like it. | An open point is the last case of the include production: | Should we implicitly wrap double quotes around it or not? I | don't really like such implicit things, but | | foreign import ccall "static !myproc \"myinclude.h\"" | myProc :: ... | | could look a little bit funny because of the backslashes. | Again, I don't really mind about that topic. But I'm against | implicitly suffixing with '.h' in any case. I'd go for automatically adding quotes. Acutally, I'd automatically add a '.h' too. Reason: you are really specifying the assembly or package where the function comes from, and that might be useful for linking as well as includes. If the package was called P, the compiler can #include "P.h", and in addition say -lP on its link command. That's less convenient if there's a .h to strip off. Simon

1 0

Again: FFI syntax
by Sven Panne 13 May '01

13 May '01

It's weekend and so it's time for a new syntax proposal... :-) After the recent clarification of the role of "import" and "export" and a few other suggestions, here's my next shot: ------------------------------------------------------------------------ topdecl : 'foreign' impexp callconv extent var '::' type impexp : 'import' | 'export' callconv : <empty> -- defaulting to 'ccall' | 'ccall' | 'stdcall' | 'cplusplus' | 'jvm' | 'dotnet' extent : string -- Wake this optional? Which default then? ------------------------------------------------------------------------ Syntax for ccall/stdcall's import extent: extent : 'static' safety cid include -- former f.i. | 'dynimp' safety -- former f.i.d. | 'dynexp' -- former f.e.d. | '&' cid include -- former f.l. safety : <empty> | '!' -- means "never re-enters Haskell world" include : <empty> | '<' <anything but '>'>* '>' | <anything but '<'> <anything>* ------------------------------------------------------------------------ Syntax for ccall/stdcall's export extent: extent : cid ------------------------------------------------------------------------ I don't have very strong feelings about other names for "dynimp"/"dynexp", so I'll leave this to the native speakers. An open point is the last case of the include production: Should we implicitly wrap double quotes around it or not? I don't really like such implicit things, but foreign import ccall "static !myproc \"myinclude.h\"" myProc :: ... could look a little bit funny because of the backslashes. Again, I don't really mind about that topic. But I'm against implicitly suffixing with '.h' in any case. The story above has a few advantages compared to the last proposal: * import/export explicitly tell you (= the compiler :-) if a new Haskell name is introduced or not, without inspecting extent. * Silly combinations like "an unsafe label" or "a dynamic import with a given C-name" don't exist. * It's (hopefully) more mnemonic, e.g. '&' reminds one of the C address-of operator, and '!' suggests something inherently dangerous. Comments? We should really come to an agreement on the syntax soon... Cheers, Sven

2 1

RE: FFI Definition
by Simon Peyton-Jones 07 May '01

07 May '01

[Welcome back, Sigbjorn. Are you on the FFI mailing list? Now you are back online you should be!] | Export dynamic introduces a name, export static exports an | existing name. For that reason putting this distinction in | extent seems strange for me. This seems like a good point to me. foreign export foo :: Int -> IO Int exports a C-callable function foo *uses* a Haskell function foo :: Int -> IO Int (that is, foo must be in scope) foreign export dynamic baz :: (Int -> IO Int) -> IO Addr does not export anything to C *defines* a Haskell function baz with the type specified (that is, the foreign decl binds baz) This is rather different to 'foreign import' vs 'foreign import dynamic' both of which import a function, but the type of the function depends on whether it's dynamic. PRINCIPLE: it should be possible to look at a foreign decl, and *without looking at the extent string* say what Haskell function is used or defined, and what its type is. CONCLUSION: we need to say outside the extent string whether we are doing foreign export or foreign export dynamic. I'm not sure what the right syntax is Simon

1 0

FFI Definition
by Manuel M. T. Chakravarty 07 May '01

07 May '01

Folks, As promised, I have started on a definition of the Haskell FFI. I started by formalising those aspects of foreign exports and imports that we have recently discussed here. You can access the current text at http://www.cse.unsw.edu.au/~chak/haskell/ffi.ps.gz In addition to general comments, I would particularly welcome your opinion on the FIXME issues. You may note that I have tilted the specification of the calling convention and the related string determining the external entity very much into the direction of the execution platform. In my opinion that makes the whole description much more consistent. In particular, we are now talking about JVM calls rather than Java calls. This fits much better with ccall, wincall, and dotnet. It also makes it much more natural to talk about calling conventions rather than programming languages implemented in terms of these calling conventions. I will add more material (including also a specification of the FFI library) as we go. Cheers, Manuel

5 12

RE: Revised FFI syntax + typing
by Alastair Reid 07 May '01

07 May '01

> 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 reid(a)cs.utah.edu 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.

1 0

Re: FFI Definition
by Alastair Reid 07 May '01

07 May '01

> 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 reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

2 1

RE: Revised FFI syntax + typing
by Simon Marlow 06 May '01

06 May '01

> -- 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

5 5