- FFI - Haskell.org

Re: Again: FFI syntax
by Marcin 'Qrczak' Kowalczyk 30 May '01

30 May '01

Tue, 29 May 2001 10:37:54 +0200, Sven Panne <Sven_Panne(a)BetaResearch.de> pisze: > Just to restate my position: I'm against *always* wrapping the header file name > in double quotes, unless > > #include "foo/bar.h" > > implies > > #include <foo/bar.h> > > if the first form is not found. It does, but having "" and (ab)using it to mean <> would be bad - if the current directory happens to contain a file with such name then confusion begins. I propose adding implicit "" if <> are not given explicitly. As -#include in ghc does (it looks for "" or <> and adds "" if neither is found; it might even not be necessary to allow explicit "" at all, only explicit <> or implicit ""). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Again: FFI syntax
by Sven Panne 29 May '01

29 May '01

Simon Marlow wrote: > 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. That's exactly what I had in mind. > Can we make the "static" optional? It wouldn't introduce any ambiguity, > and it would save characters in the common case. Well, it *would* introduce ambiguity (or we steal some names from C land): foreign import ccall "dynimp" dynimp :: ... > I like '&', but I'm less sure about '!' - this feels like we're getting > a little too cryptic. The reason for the "cryptic" '!' is avoiding ambiguity. Let's assume we introduce a modifier which looks like a valid C identifier. What should the following mean then? foreign import ccall "static foo bar" baz :: ... Is it an import of the C entity "foo" with the #include file "bar", or is it an import of the C entity "bar" with modifier "foo"? An alternative would be to make the include part somehow distinguishable from a C identifier, but I'm not sure if this would be less cryptical. And '!' is not that bad IMHO, the connotation "DANGER" should be obvious, and a single character doesn't clutter up the extent. *sigh* Syntax wars again... :-} Cheers, Sven -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de

3 6

RE: extent strings
by Simon Peyton-Jones 29 May '01

29 May '01

A process comment: This FFI discussion is dragging. I really want to get a conclusion because I want to implement it for .NET. Manuel --- you are are Tzar. Whip us into order! (I don't think that any of the issues are do-or-die ones; i.e. compromise is possible!) | > > [...] What's the advantage of putting the information in a string? | > [...] This is useful for tools that parse Haskell source code but | > which are not compilers -- e.g. documentation generators. | | That's not really an argument, because if we slightly change | the grammar, a "catch-all" production is easily specified: But only if the catch-all production catches all. For example, suppose we wanted to specify the full type signature of a Java function. In principle we could specify a grammar that would describe foreign import jvm static int Java.Lang.foo( int x ) foo :: Int -> IO Int But it's hard to parse without the newline, and it's going to be hard to specify a catch-all syntax that enables the documentation generator to skip all the jvm-specific junk. I think we should stuff it into a execution-platform-specific string, thus foreign import jvm "static int Java.Lang.foo( int x )" foo :: Int -> IO Int What should be visible "outside" the string. I think: a) what Haskell function is being defined or used b) what the Haskell type of that function is c) whether the function is being *defined* (like foreign import or foreign export dynamic) or *used* (like foreign export) Haskell functions that are *used* must be in scope already; those that are being *defined* are brought into scope by the foreign decl. Unfortunately, 'foreign export dynamic' defines a function, so one cannot just look at the import/export keyword. Maybe we need foreign import foreign export foreign dynexport ? (Dynamic import is quite different; it's still an import, but there's one more argument.) Simon

3 2

Re: Again: FFI Syntax
by Sven Panne 29 May '01

29 May '01

Simon Peyton-Jones wrote: > [...] 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. Hmmm, this looks like mixing concepts again. I thought we agreed on the fact that the include part specifies an #include, and nothing else. For "real" stuff things aren't that easy anyway: Include files for larger libraries live in subdirectories (e.g. <GL/gl.h>, <readline/readline.h>), linking a single additional library is seldom enough (e.g. you normally need to link with termcap,too, when you link with (n)curses, linking an X app needs almost a dozen libs on some platforms, etc.), ... 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 :: ... Cheers, Sven -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de

2 1

Re: FFI Definition
by Sven Panne 29 May '01

29 May '01

Simon Marlow wrote: > The reason for not putting them in the source is because the names of > libraries change from system to system but their APIs don't. It's > possible to write a portable binding to an API if you don't have to > include the libraries, but including the library names requires > information from the system, which is normally picked up by a configure > script. [...] I'd go even one step further: Often even the names of #include files differ for the same API, or you have to #include some other headers first, etc., just take a look into GHC's RTS for example. If we specify #includes in the FFI, we effectively resort to autoconf or something like that in our hand-made #include files most of the time, I fear. (or clutter up the Haskell sources with #if #endif :-P ) But most people on this list think different and you don't have to use this feature, so I can live with that. Cheers, Sven -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de

2 1

RE: FFI Definition
by Simon Marlow 16 May '01

16 May '01

> Simon PJ writes: > > I thought we agreed to remove the specification of > libraries from the > > FFI, and leave it to some compiler-dependent mechanism. As > Sven points > > out, there are going to be times when you really don't want > a library at > > all, or in any case not one with the same name as the > header file, and > > there will be cases where you want several libraries in some > > system-dependent order that shouldn't be placed in the source code. > > I'm certain that at least one person (me) disagreed with removing any > library specs from the FFI. I tend to the view that if the compiler > needs to know about something (and can't work it out for itself) the > information should be in the source code. Putting it in a Makefile > or some other auxiliary structure (package configuration?) is not > really clean enough for me. I don't want to have to write three > different Makefiles, one for each possible compiler I could use. > Please let's aim for portability. > > Having said that, it is true that the FFI may not be the best place > for a specification of link libraries or whatever. Maybe we should > agree on some pragmas for this sort of information? In any case, > I'd like to have a compiler-independent standard, whether or not it > is part of the FFI. The reason for not putting them in the source is because the names of libraries change from system to system but their APIs don't. It's possible to write a portable binding to an API if you don't have to include the libraries, but including the library names requires information from the system, which is normally picked up by a configure script. For example, what should I link to in order to get GLib? On the RedHat system here, it's -lglib, but on my FreeBSD box at home it's -lglib12, but the code for the binding remains the same. So to keep the Haskell code portable, it should omit the library names. I see the information in a package config as "meta-information" about the Haskell code: information about the particular environment in which the code is running. It's certainly not a perfect separation, because some system-specific things have to be compiled into the code to get decent performance (the values of the errno constants, for example), but at least it leaves the Haskell code independent of filenames and directory locations. If you want to put this information in a pragma for NHC that's fine. I'd much prefer to see NHC use our package scheme though: I'll be happy to incorporate any changes needed by NHC into the tools. Cheers, Simon

1 0

RE: FFI Definition
by Simon Marlow 16 May '01

16 May '01

> I still don't understand the dynamic library stuff related to > "fname". Is > it a hint for a compiler to link against a given library? Any compiler > surely has some kind of option/pragma for this already. What should it > mean when there is a corresponding static lib, but not a dynamic one? > Most of the time one doesn't really care about this. What > should it mean > for an interpreter? dlopen-ing? How should the condition > > "... if the external entity has to be obtained from a dynamically > loaded library ..." > > be implemented, i.e. when does "fname" simply denote the header to > #include and when does it denote something related to a DLL? It looks > like mixing two unrelated concepts here. I thought we agreed to remove the specification of libraries from the FFI, and leave it to some compiler-dependent mechanism. As Sven points out, there are going to be times when you really don't want a library at all, or in any case not one with the same name as the header file, and there will be cases where you want several libraries in some system-dependent order that shouldn't be placed in the source code. GHC already has such a mechanism: the package system, and additionally using fname as a library spec would make our lives somewhat harder. I suggest just deleting the sentence "Moreover ... may be made." on page 6. Cheers, Simon

2 1

RE: extent strings
by Simon Marlow 15 May '01

15 May '01

> Hmmm, that's an opinion, but not a technical reason. What I > was hoping for > is a real rationale for the extent string, i.e. why neither > the one extreme > > topdecl : 'foreign' string var '::' type > > nor my last suggestion (the opposite extreme) would fit. > Currently we seem > to draw a rather arbitrary line between "real" Haskell syntax and the > extent string, while my last suggestion only used strings for entities > where nothing Haskell-like would fit syntactically, i.e. C identifiers > and #include paths. So I'm with Alastair and Fergus, but I'm > still ready > to be convinced otherwise... I think the rule of thumb which we've been using so far is * the information outside the string is enough for a compiler to statically analyse and typecheck the foreign declaration, which includes checking whether the type of a f.e.d. has the right form, etc. * the information inside the string is required only by a compiler back-end that needs to generate the actual call (in the case of an import) or definition (in the case of an export). One reason for keeping the back-end info inside a string is because it is likely to be specified using syntax from the foreign language: eg. C identifiers don't have the same lexical syntax as Haskell identifiers, and C++/Java identifiers have to include a type to be uniquely specified. It's hard to say how well this generalises without working though all the issues for 2 or 3 different languages, but I guess we already know that ceratin foreign declarations don't make sense for Java (f.i.d.), so the upshot seems to be that each language will need its own foreign declaration syntax. I buy the argument that introducing new syntax for each new language is OK as long as it generalises to a list of vars/strings, for tools that don't need to understand any more than that. This looks like a reasonable compromise that should keep everyone happy. Cheers, Simon

1 0

Re: extent strings
by Sven Panne 15 May '01

15 May '01

Marcin 'Qrczak' Kowalczyk wrote: > I propose the following guideline: > > * what to import / as what to export - inside the string > * how to import/export - outside the string [...] Hmmm, that's an opinion, but not a technical reason. What I was hoping for is a real rationale for the extent string, i.e. why neither the one extreme topdecl : 'foreign' string var '::' type nor my last suggestion (the opposite extreme) would fit. Currently we seem to draw a rather arbitrary line between "real" Haskell syntax and the extent string, while my last suggestion only used strings for entities where nothing Haskell-like would fit syntactically, i.e. C identifiers and #include paths. So I'm with Alastair and Fergus, but I'm still ready to be convinced otherwise... Cheers, Sven -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de

1 0

Re: extent strings
by Sven Panne 15 May '01

15 May '01

Fergus Henderson wrote: > On 14-May-2001, Alastair Reid <reid(a)cs.utah.edu> wrote: > > [...] What's the advantage of putting the information in a string? > [...] This is useful for tools that parse Haskell source code but which > are not compilers -- e.g. documentation generators. That's not really an argument, because if we slightly change the grammar, a "catch-all" production is easily specified: ------------------------------------------------------------------------ topdecl : 'foreign' 'import' callconvC impspecC var '::' type | 'foreign' 'export' callconvC cid var '::' type -- "Don't know the callconv"-production | 'foreign' ['import'|'export'] (var|string)* var '::' type callconvC : 'ccall' | 'stdcall' impspecC : ['static'] ['unsafe'] cid include -- former f.i. | 'dynimp' ['unsafe'] -- former f.i.d. | 'dynexp' -- former f.e.d. | 'label' cid include -- former f.l. -- contents automagically wrapped into double quotes if they don't start -- with either '"' or '<' include : string -- could default to var of production topdecl cid : string ------------------------------------------------------------------------ Personally, I'd prefer something like the above syntax, too, restricting oneself syntactically to (var|string)* for any future calling convention's import/export specification is not that hard. Completely switching to string land is a little bit of hack IMHO, but perhaps the advocates of this solution could explain their preference a little bit. Just a side note: The above syntax is quite close to the current one, and defaulting (even of callconvC) can be done without ambiguity: foreign import puts :: CString -> IO CInt *sigh* At least there seems to be some consensus regarding the syntax of the import/export specification for C, within a string or not... Cheers, Sven P.S.: Still no better naming suggestions for 'dynimp' and 'dynexp'? -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de

2 1