March 2001 - FFI - Haskell.org

Typing f.e.d.
by Sven Panne 30 Apr '01

30 Apr '01

I have a small change request regarding foreign export dynamic. Currently the FFI doc says: topdecl : ... .. | 'foreign' 'export' [callconv] 'dynamic' varid :: prim_type -> IO Addr GHC additionally allows: prim_type -> IO Ptr As usual the FFI "looks through" newtypes. But now that we have FunPtr, the following typing makes much more sense: 'foreign' 'export' [callconv] 'dynamic' varid :: prim_type -> IO (FunPtr prim_type) where both prim_types have to be the *same*. We should probably allow the old Addr-typing as well for some time to facilitate the transition, but not the Ptr-typing (bleeding edge people will know what to do :-). The corresponding changes to GHC look easy, so I'd like to commit this if there are no objections. Furthermore, the FFI docs still talk about Addr only, not Ptr/FunPtr. Now that Addr is deprecated, this should be changed, too. Cheers, Sven

5 7

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

RE: unsafePerformIO and unsafeInterleaveIO
by Simon Marlow 23 Mar '01

23 Mar '01

> qrczak(a)knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote, > > > Mon, 19 Mar 2001 11:04:43 -0700, Alastair Reid > <reid(a)cs.utah.edu> pisze: > > > > > > Should these functions be available through the standard FFI? > > > > IMHO they should. > > > > > > I don't understand the question. > > > Are you asking which modules should export them? > > > > Yes. IMHO they should be made as "standard" as the rest of FFI > > and exported from module Foreign. > > I guess, you could a (maybe inefficient) version of > unsafePerformIO using the FFI functionality anyway. This > gives us a default implementation, so I thing, we should > include it. I am not so sure about unsafeInterleaveIO. I'm not sure about including these functions in Foreign. Their location should be standardised, sure: but that's something to be discussed as part of the new library proposal. I don't feel they belong in Foreign. Cheers, Simon

5 6

RE: unsafePerformIO and unsafeInterleaveIO
by Simon Marlow 23 Mar '01

23 Mar '01

Alastair Reid writes (on the FFI mailing list): > ps I wonder if it'd be possible to merge them by doing this > in the hslibs repository: > > 1) Move the STG Hugs ifdefs out of the way: > > find . -name '*.[l]hs' | xargs perl -p -i > -e's/__HUGS__/__STG_HUGS__/' > > The __HUGS__ label made sense when I expected CLassic Hugs > to be replaced by STG-Hugs > - but it wasn't so it should be renamed. > > 2) Merge in the current Classic Hugs libs (using ifdef __HUGS__). > > (There's a question of what to do with the Hugs libs which > don't exist in > the Hugs-GHC standard. I imagine that GHC merrily puts > GHC-specific files > into the repository and that'd be the thing to do with > Hugs files. In each case, > a giant ifdef round the whole file would prevent it from > troubling the other party.) > > 3) Add enough infrastructure to make it easy to checkout a > working version of Hugs > based on the hslibs repository. Rather than doing this, if there is effort available at the Hugs end I would urge them to participate in the discussion of the new library proposal. The result will be an evolution of hslibs, so I'm not keen to put in too much work on hslibs until the design is settled. The plan for the new libraries is to have a central compiler-independent repository for the source. It'd be great if Hugs joined in too. Cheers, Simon

1 0

RE: unsafePerformIO and unsafeInterleaveIO
by Simon Marlow 22 Mar '01

22 Mar '01

> > Without a standard way to get > > at unsafePerformIO, such code would still rely on > > non-standard features, which goers against the aim of > > standardising the rest of the FFI. > > The Hugs-GHC standard libs have them exported from IOExts. > > Of course, the Hugs-GHC standard isn't an official Haskell > library committee approved standard but, since it's something like 4 > years old, I think it's a better candidate for approval than > the ffi library which hasn't really stabilised yet, hasn't > been whacked > on by a large number of users, is much younger, etc. Sadly, due to lack of support on the Hugs side, the Hugs/GHC extension libraries have drifted apart. I would have liked Hugs to ship with a cut-down hslibs at some point (and indeed there's some support in the hslibs build system for Hugs), but there was no-one available at the Hugs end to do the work and make it happen. Longer term, the effort currently underway on libraries(a)haskell.org should eventually provide a unified story for "extension" libraries. Cheers, Simon

2 1

unsafePerformIO and unsafeInterleaveIO
by qrczak＠knm.org.pl 20 Mar '01

20 Mar '01

Should these functions be available through the standard FFI? IMHO they should. Their functionality on a variety of concrete types can be archieved by using C, in an ugly and inefficient way. FFI already contains the level of unsafety they are at. They are useful, especially in the context of FFI. They are used all over hslibs: Concurrent, SocketPrim, Posix, MatchPS, XmlParse, Memo, Readline, Select, QuickCheckBatch, Unique. I used them in 5 out of 8 bindings to random C libraries (Bzip2, Curses, Libgr, Readline, Zlib). They are available in all four Haskell implementations, only through different modules. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

4 4