- FFI - Haskell.org

RE: Trying to build HDIRECT with ghc-5.00.2
by Simon Marlow 13 Jul '01

13 Jul '01

I'm probably about to get my head bitten off for this, but here goes: would it be possible to move H/Direct in the direction of using the FFI libs? For a few reasons: - deprecated features are going to be removed at some point. In fact, I've removed them all in the new Core Libraries. - there's lots of duplicated functionality. - one might be able to mix H/Direct and hand-written FFI code. I realise this would probably be a lot of work, but then of course H/Direct will benefit from improvements to the FFI libs, like stack-allocation (if I ever get around to doing it). Cheers, Simon > -----Original Message----- > From: Sigbjorn Finne [mailto:sof@galconn.com] > Sent: Thursday, July 12, 2001 3:46 PM > To: Simon Peyton-Jones; ahey(a)iee.org > Cc: ffi(a)haskell.org > Subject: Re: Trying to build HDIRECT with ghc-5.00.2 > > > No, it was just a bug that was introduced somewhere > on the road to GHC5. The version of Int in the repo does > the right thing now. > > --sigbjorn > > ----- Original Message ----- > From: "Simon Peyton-Jones" <simonpj(a)microsoft.com> > To: "Sigbjorn Finne" <sof(a)galconn.com>; <ahey(a)iee.org> > Cc: <ffi(a)haskell.org> > Sent: Thursday, July 12, 2001 01:04 > Subject: RE: Trying to build HDIRECT with ghc-5.00.2 > > > > | (*) - ghc-5.00.2 give Int.sizeofInt{8,...} the type Int32; > > | HDirect generated sources assume Word32 (as it should be). => > > | you may need to tweak the generated code in a select few > > | places to make ghc-5.00.2 happy. > > > > Sigbjorn: > > > > Are you suggesting a change to the Int module? It would > > be nice to settle ethis so that no tweaking was reqd. > > > > I'm ccing the FFI list as that seems the right place to decide. > > > > Simon > > > _______________________________________________ > FFI mailing list > FFI(a)haskell.org > http://www.haskell.org/mailman/listinfo/ffi >

1 0

RE: Trying to build HDIRECT with ghc-5.00.2
by Simon Peyton-Jones 12 Jul '01

12 Jul '01

| (*) - ghc-5.00.2 give Int.sizeofInt{8,...} the type Int32; | HDirect generated sources assume Word32 (as it should be). => | you may need to tweak the generated code in a select few | places to make ghc-5.00.2 happy. Sigbjorn: Are you suggesting a change to the Int module? It would be nice to settle ethis so that no tweaking was reqd. I'm ccing the FFI list as that seems the right place to decide. Simon

2 1

Re: Patch for buildings hugs with pthreads
by Sven Panne 09 Jul '01

09 Jul '01

Antony Courtney wrote: >[...] We are currently working on a novel mechanism for mapping Java > method names to Haskell function names; when that is complete, we plan > to make this system available to the community. It might be a good idea to join the Haskell Foreign Function Interface (FFI) mailing list (http://haskell.org/mailman/listinfo/ffi) for anybody interested in this kind of stuff. Apart from some occasional syntactic Jihads, it's quite low-volume. The new design is intended to accommodate various languages apart from C, e.g. SPJ is working on a .NET binding IIRC, which probably has very similar problems as a one for Java (overloading, exceptions, etc.). A draft document is available at http://www.cse.unsw.edu.au/~chak/haskell/ffi.ps.gz and http://www.cse.unsw.edu.au/~chak/haskell/ffi.tex The Java part is almost nonexistent yet and has only been discussed very superficially, so any help and suggestions are highly appreciated. > However, because the Java VM is multi-threaded, I had to rebuild Hugs from > sources under Linux to use the multi-threaded version of the C library. The > changes were very minor: > - Pass the -D_REENTRANT flag to CC > - Add -lpthread to LIBS for linking > - #define DONT_PANIC to avoid catching signals used by the user-space > LinuxThreads implementation. Hmmm, things are a little bit different on Solaris IIRC, but I don't have the relevant man pages at hand. I'll have a look tomorrow... Cheers, Sven.

1 0

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