- FFI - Haskell.org

QForeign-0.65 is out
by qrczak＠knm.org.pl 15 Apr '01

15 Apr '01

http://prdownloads.sourceforge.net/qforeign/qforeign-0.65.tar.gz qforeign-0.65 (Apr 15, 2001) ---------------------------- * Make libraries for GHCi too (HS*.o). * hsc2hs should work on Windows too (untested). * Works with nhc98-1.02 too. ghc-4.09 support dropped. * hsc2hs parser rewritten. #{stuff} added (like #stuff but self-delimited). Now correctly handles '--' in operators and backslash-newline pairs in C lexical world. * Use {-# LINE #-} pragmas for nhc98 too. * Zlib and Bzip2 express byte lists as [Word8] instead of String. * QCError.errnoToIOError uses strerror instead of its own error strings, and uses FFI.mkIOError under nhc98 if available. * Add destruct method to class Storable (thanks Wojciech Moczydlowski <khaliff(a)astercity.net> for the suggestion). * Add QCFile: conversion between Handle and FILE * (compiled when module Posix is available). * Support readline-2.2.1 as well as readline-4.x. * Support Unicode 3.1.0 in unidata. Characters up to 0x10FFFF. Better definitions of some character properties. More efficient GenUnicodeData. * README is more interesting. * License changed from GPL to LGPL. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: FFI progress
by Simon Peyton-Jones 12 Apr '01

12 Apr '01

| In case you aren't aware of this, Windows DLL's by default, (actually | always, as far as I know) use the stdcall (Pascal) calling convention. | | I personally hope that you won't drop anything which facilitates using | Haskell under Windows. Dead right. I wasn't proposing removing the functionality, just changing how to get at it. More concretely, there are two alternatives 1. Treat C-via-stdcall and C-via-ccall as two different "languages". E.g. foreign import "C/stdcall" "gtk:foo" foo :: Int -> IO Int 2. Treat C as one language, but put the calling convention into the language specific string. E.g. foreign import "C" "stdcall/ gtk:foo" foo :: Int -> IO Int I prefer (1) but it's not a big deal. Simon

2 1

RE: FFI progress
by Simon Peyton-Jones 09 Apr '01

09 Apr '01

Is anyone actually specifying stdcall ccall calling conventions in a foreign import? I want to pull it out of GHC but I don't want to break anything. Simon

3 2

RE: FFI progress
by Simon Peyton-Jones 07 Apr '01

07 Apr '01

One other thing. What did we decide about the 'calling convention' field. I reckon it should vanish into the language-specific string, or alternatively treat C as two languages that differ in their calling convention. No way C calling conventions deserve special treatment. Simon

1 0

Re: FFI - some comments
by qrczak＠knm.org.pl 06 Apr '01

06 Apr '01

Thu, 5 Apr 2001 07:45:44 -0700 (PDT), Ronald Legere <rjljr2(a)yahoo.com> pisze: > KDirect: Looked at it abit. Pretty sparsely documented. I could not > figure out how it fits in with the latest tools. How does QForeign > relate to Foreign? What is an hsc file? Also it is pretty limitted > in the marshalling. No callbacks etc. Here is the story of QForeign, hsc and KDirect. One year ago the core 'foreign' declarations were already stable and implemented in ghc (for sure) and nhc (probably already at that time). The FFI documentation said that support for more complex marshalling is delegated to separate tools. Available tools, namely HDirect and Manuel's C2HS, were too heavy for my taste. But Sven's modules provided by ghc: FFI (later renamed to Foreign) and Marshal, were insufficient. I realized that a few more functions would make the basic FFI usable directly, without sophisticated preprocessors. I also wanted to experiment with typed 'Ptr a' instead of amorphic 'Addr'. So I merged ideas from ghc's module FFI and C2HS with my own FFI vision, and QForeign was born. QForeign evolved. The basic style of calling a C function while marshalling arguments and results changed a few times. It got examples. It suggested how to handle structs and enums. It became my Unicode laboratory. Since writing lots of small C functions for getting struct fields and constants was painful, I wrote glue-hsc: a simple preprocessor which translates a Haskell module with embedded C bits into a C program which outputs a real Haskell module. It allows embedding snippets of C code which are extracted into .c and .h files to be compiled separately. The source file extension .hsc means: .hs + bits of C included. QForeign was following changes in ghc and it also influenced ghc. ghc got typed pointers, alloca, withForeignObj, C array support, hsc2hs (renamed from glue-hsc), errno handling, C string support interface. As soon as some QForeign's feature got into ghc, QForeign switched to use it from ghc instead of providing it itself. If a feature mutated during its path to ghc, QForeign reflected the change. ghc's FFI support and my FFI vision were slowly converging. I had to write a networking program at the University, so of course I decided to use Haskell. That's why QForeign has pcap in examples. I asked my admin to install ghc in students' lab. The latest stable version was 4.08.1, so I #ifdefed parts of QForeign to support ghc-4.08* too by providing its own typed pointers and Storable again (no Unicode, no --add-package). Supporting several ghc versions at once happened to be easy (hsc2hs delegates #ifdefs to cpp). So I tried to port QForeign to nhc too and it worked, after some bugs that I reported were fixed. So I also thought about supporting hbc, which would require writing a preprocessor which translates 'foreign' declarations to appropriate hbc's magic, but hbc is dead, so I forgot it. Since Hugs recently got 'foreign' declarations, it might be possible to port QForeign to Hugs in future, but its foreign module management looks hard. QForeign and FFI modules provided by ghc-5.00 (to be released really soon) are now very close, after Manuel put some marshalling utilities into ghc and I backported them to QForeign as usual. The largest difference is that QForeign makes real use of Unicode (when the compiler has wide Chars) by converting most strings exchanged with the world between the specified encoding (default: locale dependent) and Haskell's Unicode, even though Unicode support modules are still experimental and transparent conversion on Handle IO is temporarily hacked on top of original Handle functions. In essence QForeign provides the interface of ghc-5.00's FFI on ghc >= 4.08 and nhc98. My friend Wojciech Moczydlowski <khaliff(a)astercity.net> asked me what is the currently recommended way of interfacing between Haskell and C. I showed him how do I do it. He said that Greencard and HDirect were easier: you didn't have to write marshalling code around each function, but all arguments were magically coverted basing on a single type declaration of the function. I replied that my solution is more general, especially if the Haskell's interface of a C module doesn't want to exactly mirror the original C interface, and that it's impossible to match everything automatically, and that it's not that painful to write function wrappers by hand. He said that a tool could handle simple cases automatically, leaving only hard types to the programmer. I said that I don't know how express a C interface to archieve this, and that C libraries are too complex to be wrapped in Haskell automatically, and thus I can't provide anything more sophisticated than hsc2hs. So he created KDirect. KDirect currently works on top of QForeign and hsc2hs. I assume that in future it will be able to use FFI modules provided by ghc >= 5.00, and that eventually all Haskell implementations will provide common FFI modules. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

FFI progress
by Simon Peyton-Jones 29 Mar '01

29 Mar '01

Manuel The FFI discussion seems to be completely stalled. Would you, as our Tsar, like to summarise the state of play, and re-invigorate it? We don't have a plan at the moment; nor do we have even a draft FFI document (the one you are going to write!). I'm concerned that we'll just dribble on and lose morale. Simon Here's my contribution to re-invigoration: As I recall the main sticking point is whether we have a global 'foreign library' declaration in addition to foreign import etc. The main (only?) motivation for such a thing is C It's a powerful motivation because C is ubiquitous. I do have one suggestion to elaborate our earlier proposal. To remind you our simple-minded proposal was * no 'foreign library' decl * the c-language-specific string on a foreign import could say foreign import "gtk:foo" foo :: <type> with 'gtk' indicating which foreign package was indicated Main complaint was: the package-name => what-to-do mapping still isn't specified. In short, our simple-minded proposal is too simple-minded to be useful. OK so the new suggestion is this: the 'gtk' indicates 'please #include gtk.h'. It's up to you to have a 'gtk.h' lying around, in which you can put all the other #includes (including whether in <> brackets or "" quotes) to your heart's content. I bet this still doesn't solve the problem entirely, but maybe it solves enough of the problem. I remain reluctant to generate elaborate designs for a single language. Simon

4 4

RE: FFI progress
by Simon Peyton-Jones 28 Mar '01

28 Mar '01

| I propose the following (basically my last proposal plus | suggestions made by others): | | foreign import "gtk.h:foo" foo :: <type> | | corresponds to a `#include "gtk.h"' and | | foreign import "<gtk.h>:foo" foo :: <type> | | corresponds to a `#include <gtk.h>'. The former allows to | have a custom `gtk.h' "lying around" as suggested above. | The filename may of course be a path. | | As suggested by SimonM, we also allow multiple includes | seperated by comma | | foreign import "<sys/types.h>,<sys/sockets.h>:socket" | socket :: <type> Do we really need this? Surely it's not so hard to have one header file per package living in a standard place that collects the headers needed for a particular package, including whether they are <..> or "...", etc. Its easy to add features and nigh impossible to remove them. I suggest we have just "gtk:foo" (no ".h") meaning #include "gtk.h" Now we can sensibly interpret "gtk:foo" as meaning "foo from package gtk"; and in concrete terms import a suitable header file. But I could imagine a clever compiler could also use to add gtk.a to the link line etc (hence no .h). Let's see if simplicity is too painful. I can't imagine it will be. Simon

1 0

RE: FFI progress
by Simon Marlow 28 Mar '01

28 Mar '01

> If we adopt the proposal, I will define it in detail. Seems fine to me. Cheers, Simon

1 0

Libraries and FFI
by Simon Peyton-Jones 23 Mar '01

23 Mar '01

| I would also want to echo Simon's comment that the new hierarchical | namespace and library proposal should go a long way to making the | library situation better in the very near future. We are currently | discussing a general layout and re-naming of the existing modules from | hslibs. If Hugs users and developers don't join in the discussion, | then we could be wasting our effort. We really want to develop | a de-facto cross-compiler standard, not just a one-compiler or | two-compiler standard. ...and indeed, no one from OGI is subscribed to either the FFI or the Libraries discussion list. I'm ccing some of them so they can take a look at the thread: http://haskell.org/pipermail/ffi/2001-March/thread.html http://haskell.org/pipermail/ffi/2001-March/000270.html Staying out of these discussions is a perfectly reasonable choice on their part (there are only so many hours in the day) but it does mean that it's unreasonable to expect Hugs to track either debate. In the minutes of the Haskell Implementors Meeting in Jan we had: Hugs: OGI in maintenance mode. There's a danger that Hugs will gradually die, which none of us want. One idea: advertise openly for a home for Hugs. JOHN will take this suggestion to OGI. John, did anything come of this? Simon

1 0

CfP: Babel01 Workshop on Multi-Language Infrastructure and Interoperability
by Fergus Henderson 23 Mar '01

23 Mar '01

I'm not sure if Nick Benton posted a copy of this to ffi(a)haskell.org yet. Probably many of you have seen this before. But I would particularly like to invite submissions from the Haskell community, since I know that many of you have been doing a significant amount of work on language interoperability. BABEL'01 CALL FOR PAPERS First Workshop on Multi-Language Infrastructure and Interoperability http://research.microsoft.com/~nick/babel01.htm Satellite to PLI'01 Firenze, Italy, 8th September 2001 AIMS AND SCOPE Recent years have seen a resurgence of interest in multi-language tools and intermediate languages, and in interoperability between programs and components written in different programming languages. Shared infrastructure such as code generators, analysis tools and garbage collectors can greatly ease the task of producing a high-quality implementation of a new programming language, whilst being able to interoperate easily with code written in existing languages is essential for such an implementation to be useful in practice. This workshop aims to bring together researchers and developers working on multi-language integration. Contributions are welcome on topics including, but not limited to: * Compilation of high level languages to common executable formats such as Sun's Java Virtual Machine, the DRA's ANDF or Microsoft's .NET Common Language Runtime. * Defining and using bindings for component middleware such as OMG's CORBA or Microsoft's COM. * Language constructs to support interoperability between different languages, particularly from different paradigms (e.g. OO/functional). * Multi-language backends for compilation and/or analysis (e.g. MLRISC, FLINT, C--, TAL, SUIF). * Type theoretic and semantic foundations for multi-language work. * Multi-language development environments and tools (e.g. debuggers, profilers). Submissions may address any programming paradigm. Experience papers which describe the use of multiple languages in application development are also welcome. Authors unsure of the appropriateness of a potential submission should email the PC chair (nick(a)microsoft.com) PROGRAMME COMMITTEE Nick Benton (chair) Microsoft Research Fergus Henderson University of Melbourne Andrew Kennedy (organiser) Microsoft Research Greg Morrisett Cornell University Martin Odersky Ecole Polytechnique Federale de Lausanne John Reppy Bell Labs Andrew Tolmach Portland State University David Wakeling University of Exeter INVITED SPEAKERS Zhong Shao Yale University IMPORTANT DATES Deadline for submission 1st June 2001 Notification of acceptance 9th July 2001 Final version due 10th August 2001 SUBMISSION DETAILS Papers should be at most 14 pages and should be submitted in Ghostscript-compatible PostScript or PDF format and be printable on both US letter and A4 paper. Authors are strongly encouraged to use ENTCS style files (see http://math.tulane.edu/~entcs/) Papers should be submitted electronically from the workshop website given above. Submissions should not overlap significantly with work which has already been published or submitted to any other conference or journal. An informal proceedings will be published as a technical report and distributed at the workshop. It is intended that a final proceedings will be published in a volume of ENTCS. -- Fergus Henderson <fjh(a)cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

1 0