June 2001 - FFI - Haskell.org

RE: FFI Report, CVS Id 1.5
by Simon Peyton-Jones 07 Jul '01

07 Jul '01

| IMHO, this is not a very attractive solution. I'd prefer to | complicate the ccall entity description slightly and go for | | foreign import ccall "myheader.h foo@mylib" foo :: Int -> Int | | Ie, we optionally allow the specification of the name of a | dll. This is only a hint and may be ignored by a given | Haskell system (in particular, in most systems, command line | options overrule such library names). OK: belt and braces. Certainly the 'mylib' is properly part of foo's external name. Let's use the "::" syntax which .NET uses for other namespace management things "myheader.h mylib::foo" foo :: Int->Int Simon

3 2

RE: Core libs summary
by Malcolm Wallace 29 Jun '01

29 Jun '01

[ cross-posted to the FFI list ] > > I remember that one of the ForeignObj-like datatypes pretty much > > requires threads to implement it because the finaliser is an arbitrary > > piece of Haskell code. This would be hard to support in Hugs and I > > expect NHC would have problems too. > > I seem to recall NHC having some difficulty with this... Malcolm? Yes and no. An arbitrary Haskell-code finaliser for a ForeignObj is stored in nhc98's runtime system as a StablePtr to the code. When the ForeignObj is garbage-collected, its finaliser is placed onto a 'pending' queue. Then when GC finishes, the pending queue is executed before control returns to the main evaluation. (Each item on the queue is thrown away after execution). This is all implemented, but the evaluation of the pending queue currently causes a seg fault. Chasing the bug wasn't a high priority at the time (18 months ago), and I have simply never got round to looking at it again. There is also the problem that executing a finaliser might itself cause another GC, but I can't remember if I had a solution for that. Regards, Malcolm

1 0

DLL spec [ was: FFI Report, CVS Id 1.5 ]
by Sven Panne 23 Jun '01

23 Jun '01

Manuel wrote: > [...] I'd prefer to complicate the ccall entity description > slightly and go for > > foreign import ccall "myheader.h foo@mylib" foo :: Int -> Int > > [...] Any objections? I'd favour this, too. Just a very minor note: If there is a "::"-syntax for this already on .NET, we should adopt this instead of "@". I'm not sure about this or similar lexical conventions on other platforms, though. 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 Report, CVS Id 1.5
by Simon Peyton-Jones 17 Jun '01

17 Jun '01

I'm trying to compile Haskell for the .NET platform. For this platform it makes perfect sense to say foreign import ccall "foo" foo :: Int -> Int because you can make C calls on .NET as well as .NET calls. The problem is that the call must specify which DLL the function comes from. The line in the .NET assembly code looks something like pinvoke dllname::foo I remember now that this is why I originally suggested that the C calling convention specify a "package name" rather than a header file name. Thus foreign import ccall "wuggle::foo" foo :: Int -> Int rather than wuggle.h Now I didn't follow all the details of why this was a bad idea but I thought I'd mention the problem. My preference would be to specify "wuggle" as the package name in the C entity, and attach a ".h" to it when emitting code for certain common platforms. The programmer would need to provide a suitable .h file, if necessary simply by #including the ones really needed. I'm conscious that this is resurrecting old territory; if it's been done to death already, just say 'no'. I suppose in that case I will have to add an extra .NET form foreign import dotnet "callC wuggle::foo" foo :: Int-> Int Simon

3 2

RE: FFI Report, CVS Id 1.5
by Simon Peyton-Jones 15 Jun '01

15 Jun '01

| There is now a new revision of the definition at | | http://www.cse.unsw.edu.au/~chak/haskell/ffi.{ps.gz,tex} Great stuff. It's looking good. | > * You mention en passant that there's a new type CInt. | Very good, but | > the full set of types (and their operations) must be defined in the | > language-specific sections. Indeed, I suggest we take 3.2 and | > make it a top-level Section, with a sub-section for each language. | | The types have to be defined, but I was planing to do that | as part of the libraries (where they are defined). I disagree with this. Here's why. I think it is useful to make a separation between - what must be implemented by the Haskell compiler - what is defined by a portable library To implement a C interface, a Haskell compiler must implement - foreign ccall ... - the types: CInt ...etc - Storable instances for those types So I propose that we have Section 4: External platforms 4.1: C [ccall, stdcall] 4.2: Java 4.3: .NET (i.e. lift current 3.5 to top level). Furthermore, within each of these I suggest we define what foriegn types and instances must be defined. Simon

1 0

FFI Report, CVS Id 1.5
by Sven Panne 14 Jun '01

14 Jun '01

Malcolm wrote: > I don't know whether we are still worrying about backwards > compatibility, [...] I'm not sure about that either, but it would be a good thing if that was possible IMHO. > And so to declare the former kind of thing, we'd need > foreign import "static static" foo :: t > ? > > I don't much mind either way, since it is a trivial and unlikely > situation, but could someone clarify please? Yep, you would have to write it in the way mentioned above. This breaks backward compatibility, but only on finitely many points, so this is probably acceptable. > > > > I have added a restriction: exported variables must be > > > > defined by a function or pattern binding in the *same* > > > > module. > > I had understood that this was always the case anyway. > foreign export f :: t > is the sole type declaration for f. Just as it is an error to have > more than one type decl for f, so you can't write an additional > f :: t > in the same file. And just as you cannot write a type decl for > an entity imported from a different module, you can't write a > foreign export for an imported entity either. I understood Manuel's restriction differently: You can only create an export named foo via foreign export ccall "foo" bar :: t if bar has a definition in the same module as the foreign decl above. > > Again, I'm with Marcin. This restriction looks very artificial and ugly. > > On the contrary, I think it is a very natural interpretation. That is > also how it is implemented in nhc98, which is something I need to > keep my eye on of course - I am not a type system hacker, and I'm > afraid I wouldn't know how to implement it any other way currently. I don't think that lifting the restriction as I understood it should pose any problems. NHC98 should be able to get a binding for an entity defined in another module... :-) Cheers, S. -- 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 2

Re: FFI Report, CVS Id 1.5
by Sven Panne 14 Jun '01

14 Jun '01

Marcin wrote: > Being just Storable is not enough to generate a foreign call. Exactly. > For example floating point arguments might be passed in different > registers than integer arguments. [...] ... or 'long long's being passed in a register pair, starting at an even register number. :-P (happens on PowerPC g++) I think it boils down to the following: For every calling convention there is a fixed set of primitive types which the Haskell system must know about, e.g. CInt, CFloat, Ptr a, ... for ccall/stdcall. The only convenience which can be offered for the programmer are opaque newtypes around these types or automatic flattening of pure product types (like e.g. GreenCard does for tuples IIRC). Marshaling and parameter passing are two different things. In a nutshell: Nice at it seems, the Storable-idea has to be replaced by something else, I fear. > > foreign import "static foo" foo :: t > > foreign import "static" foo :: t > > foreign import "" foo :: t > > > > Is the last one nice? > > Not nice and not necessary if the whole "" can be omitted, but it > makes rules more consistent. In particular this should be legal: > foreign import "&" foo :: Ptr t > so with "static" too... I'm with Marcin here. > (I still think that the "static" keyword is not necessary.) How would you import a function named "static" then? > > I have added a restriction: exported variables must be > > defined by a function or pattern binding in the *same* > > module. > > > > This shouldn't be a serious restriction in practice, but > > may make live easier for some systems. > > Why? The implementation could always generate a wrapper. > > And it is possible to do a non-FFI export of entities defined in > other modules (even written qualified), so FFI exporting rules could > be consistent with it. Again, I'm with Marcin. This restriction looks very artificial and ugly. Cheers, S. P.S.: Regarding the funny restriction on the type of f.i.d.: This has in effect been removed & fixed in GHC's implementation. -- 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

4 3

RE: CCallable/CReturnable classes (was Re: FFI Report, CVS Id 1.5)
by Simon Peyton-Jones 13 Jun '01

13 Jun '01

| Is CCallable/CReturnable a useful part of the new | multi-lingual ffi story (either in the ffi spec or in GHC's | implementation of the ffi spec)? Definitely not. It's a GHC implementation trick, that's all. Doesn't belong in a spec Simon

1 0

Re: FFI Report, CVS Id 1.5
by Marcin 'Qrczak' Kowalczyk 09 Jun '01

09 Jun '01

Sat, 09 Jun 2001 23:25:08 +1000, Manuel M. T. Chakravarty <chak(a)cse.unsw.edu.au> pisze: > The new definition reduces the problem of defining exactly > which types can be marshalled to a reference to Storable. Being just Storable is not enough to generate a foreign call. For example floating point arguments might be passed in different registers than integer arguments. So what should happen when the programmer makes a Storable instance for some weird type? (Storable.peek would be needed for importing, not exporting, and vice versa for poke - you wrote it backwards.) > Consequently, Storable must be derivable. Ok, but it's not enough. I hope that generics will subsume some uses of deriving, but for that they must be fixed (as I told a long time ago). In particular I hope that generics will cover Storable and Dynamic. It seems that even if they are fixed, it's not enough to write generic instances of these classes:-( > foreign import "static foo" foo :: t > foreign import "static" foo :: t > foreign import "" foo :: t > > Is the last one nice? Not nice and not necessary if the whole "" can be omitted, but it makes rules more consistent. In particular this should be legal: foreign import "&" foo :: Ptr t so with "static" too... (I still think that the "static" keyword is not necessary.) > I have added a restriction: exported variables must be > defined by a function or pattern binding in the *same* > module. > > This shouldn't be a serious restriction in practice, but > may make live easier for some systems. Why? The implementation could always generate a wrapper. And it is possible to do a non-FFI export of entities defined in other modules (even written qualified), so FFI exporting rules could be consistent with it. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: FFI Report, CVS Id 1.4
by Simon Peyton-Jones 09 Jun '01

09 Jun '01

| Subject: FFI Report, CVS Id 1.4 | | ...is available at | | http://www.cse.unsw.edu.au/~chak/haskell/ffi.{ps.gz,tex} Good stuff, Manuel. Thanks! Suggestion: would you like to add this to the CVS repository. Then others can get hold of it, and even modify it (e.g. correct typos, add examples). It's inefficient to type a message saying "add a comma after "..bubble.."". There's an obvious place for it. The Haskell Report is in the CVS repository cvs.haskell.org in the 'module' haskell-report. Thus cvs checkout haskell-report There is a sub-directory for report/ and another for libraries/, so you could just create a directory for ffi/. I'm unsure about access permissions, but I'm copying Jeff Lewis who is root on that machine. ============= More generally, the spec is looking good. * I strongly suggest however adding a brief collection of examples as Section 1.3 (or Section 2). * Similarly, for each language-specific section, we must add a collection of examples. No one who was not intimately familiar with the FFI would be able to make sense of 'import dynamic' or 'import wrapper'. * You mention en passant that there's a new type CInt. Very good, but the full set of types (and their operations) must be defined in the language-specific sections. Indeed, I suggest we take 3.2 and make it a top-level Section, with a sub-section for each language. * "external types" are mentioned in 3.2.1 but nowhere defined. * Nowhere do you say that in foreign import ... foo :: type that this defines the Haskell variable 'foo' with type 'type'. (Currently it's just "defines a variable", with nothing about type.) * I think we are agreed that the stuff about marshalling libraries belongs in this document too. Much of it is already written. Could it be incorporated?

2 2