- FFI - Haskell.org

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

Re: cvs commit: fptools/ghc/lib/std PrelStorable.lhs fptools/hslibs/lang Storable.lhs
by qrczak＠knm.org.pl 14 Mar '01

14 Mar '01

Wed, 14 Mar 2001 10:37:04 +1100, Manuel M. T. Chakravarty <chak(a)cse.unsw.edu.au> pisze: > > Add 'destruct :: Ptr a -> IO ()' method to class Storable. Thanks > > Wojciech Moczydlowski <khaliff(a)astercity.net> for the suggestion. > > Is this supposed to be a GHC-only extension of the FFI libraries? > If not, why didn't we discuss it - or did I miss something? Sorry, I should have discussed it. In the Storable instance of a C struct sometimes poke wants to allocate additional memory. E.g. the struct contains char* which corresponds to String in Haskell. It must be freed somewhere. Usually poke is idempotent, but in this case it's not. There is always a well-defined piece of code derived from what poke does, corresponding to C++'s destructor. There was no good place to put it. It should be called by withObject / withArray functions (I'm going to finish it), and sometimes explicitly before free. Storable is IMHO a very good place. This method has a default definition, so you can forget about it when using Storable for trivial types. Any objections? If not, I'm going to add also destructArray and destructArray0 to MarshalArray, and lengthArray0 while I am at it (it was used internally so it makes sense to be provided separately), and document it. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: Modified proposal for default decls
by Simon Peyton-Jones 27 Feb '01

27 Feb '01

| I am reasonably convinced by the need for an extensible | attribute-style specification such as Marcin has been proposing. I've been talking about the FFI stuff with Simon and Julian. We aren't (yet, anyway) convinced by the need for anything nearly as elaborate as what is now proposed. Most notably, Malcolm's latest proposal introduces a new form of abstraction (named thing), a bundle of attributes like Gtk or Bzip. Another environment for the compiler to manage! Soon people will want to export these things and import them elsewhere! This way lies madness. What is particularly tanatlising is that to a first approximation none of this is necessary. For example, the native code generator is quite happy without any of the new stuff now proposed. I think we can usefully distinguish three kinds of thing: a) What is necessary to uniquely identify the thing you want to call. In C this is just a single identifier; in Java, it's a fully qualified method name, plus the method type. Other languages doubtless lie between b) What is necessary to allow the compiler to typecheck the foreign import/export. In part, we seek #includes so that in the via-C route the C compiler will compare the call with the prototype, and complain if they don't match. But this is an implementation thing. In principle, the Haskell compiler could consult type info and compare. The important thing is that there's enough info to get from the thing-being-called to the type-of-the-thing-being-called. c) What is necessary for particular compilers, compiling in a particular way, to generate the right code. In particular, GHC compiling via C. GHC can't generate prototypes, because they might be #included. GHC can't omit prototypes unless prototypes are guaranteed to be #included. Hence the motivation to specify #include stuff. Notice that a) is essential b) is desirable, but not implemented at all c) is essential, but extremely language and compiler specific Therefore we propose that a) be part of the FFI standard b) be achievable, if desired, via (a) c) be not part of the FFI standard In particular, we propose to stick to a mild variant of the current FFI story foreign import ccall "gtk:foo" foo :: Int -> IO Int * "ccall" is one of a small number of language specifiers, "java" and ".net" "stdcall" being other possibilities. C is strange in having more than one calling convention; we treat "stdcall" as a second "language". * The "gtk:foo" is a string in language-specific format that uniquely specifies the thing being called. It'll be quite different for Java, when it'll contain the type signature of the method and whether it's a "new" constructor etc. * The "gtk:" part is a concession to (b). It specifies a C package from which this procedure comes. There is then some compiler-specific mechanism for mapping the name of a C package to the location of its header files and .o file. * If the Haskell compiler wants to typecheck the import, it is free to consult the header file, meta data or whatever, based on the foreign package name and the name of the thing being called. No "foreign library", no "foreign default"... You get to repeat everything at every foreign import. Notice that cross-module exports of inlinings are now straightforward: the foreign call carries its package name with it. You may think this is too minimalist, but there are big advantage to simple, minimal designs, even if they can't cope with every single case. Do we really need the elaboration of Malcolm's proposal? Simon

5 8

Modified proposal for default decls
by malcolm-ffi＠cs.york.ac.uk 24 Feb '01

24 Feb '01

I am reasonably convinced by the need for an extensible attribute-style specification such as Marcin has been proposing. However I am also intrigued by Alastair's "interesting" interpretation of one of my earlier suggestions, and it led me to the following proposal, modifying Marcin's design for default decls only slightly: Change foreign_decl ::= 'foreign' what foreign_name attributes varid '::' prim_type | 'foreign' 'default' attributes to foreign_decl ::= 'foreign' what [conid] [attributes] [foreign_name] varid '::' prim_type | 'foreign' 'library' conid attributes I also prefer to change attribute ::= varid | varid string_literal to attribute ::= varid | varid=string_literal The 'default' decl changes to a 'library' decl, and we now introduce a *name* for the set of default features. The conid is an arbitrary name chosen by the user; the library declaration *binds* that name to the given list of features. You can have as many library decls as you like - think of them simply as named collections of features. These names can then be used in a foreign import/export as an abbreviation for those feature specifiers. Additional attributes can be added within the foreign import decl to override ones from the named set, as in Marcin's proposal. So, for example, imagine I wanted to use both Gtk and bzip2 within a single Haskell module. First, set up a bunch of defaults for Gtk: foreign library Gtk header="<gtk/gtk.h>" header="<gtk/glib.h>" dll="libGTK.dll" stdcall unsafe (noting that the order of header files is important), and then another bunch of defaults for bzip2: foreign library Bzip2 header="bzip2.h" ccall When it comes to defining the imported functions, I just use the names I introduced earlier to access the defaults: foreign import Gtk "gtk_text_widget" textWidget :: String -> GtkWidget foreign import Bzip2 bzcat :: String -> Ptr () or, if I want to (say) add an extra header file and override an option for one particular import, I can easily do that: foreign import Gtk safe header="<extra_header.h>" "gtk_example" example :: String -> GtkWidget By the way, this implies that certain single-word features must be invertible - 'unsafe' can be overridden by 'safe', 'nonblocking' can be overridden by 'blocking', or whatever. I think this addresses Alastair's concerns about what happens to defaults when you cut+paste code from one place to another. With this proposal, if you forget to copy the library decl, the compiler will tell you that it doesn't know what defaults you intended, and can even tell you (for instance) "A 'foreign library Bzip2' decl is missing.". The name for a set of default decls is a conid rather than a varid, just to distinguish between the name of the feature *set* and the feature names themselves. They can appear in exactly the same position, and would otherwise have the same form in some cases. Marcin has already listed attributes we already know about, and here is my proposed initial list which coincides to some degree: . safe/unsafe (could rename to memsafe/memunsafe maybe?) . blocking/nonblocking . calling convention (stdcall,ccall,java,...) . header="..." (or maybe call it: include="...") . dll="..." (for interpreters under Windows) . unixso="..." (for interpreters under Unix) Note that 'dynamic' is *not* included in the possible attributes - I think that belongs properly to the function, not to the library. Marcin expressed a similar opinion I think. There is also a suggestion here to try to avoid conditional compilation: that we should have *different* attribute specs for the library name that would be required on different types of machine. Hence the naming of 'dll' and 'unixso' - and maybe there are more possibilities. Of course, this is not a panacea, as we know already from the 'gtk-config --libs' story, but it might go some way to helping. A compiler/interpreter would be free to ignore these specs for shared libraries if it thought it could do a better job by some other means. Regards, Malcolm

2 1

RE: Summary of current change suggestions
by Simon Marlow 24 Feb '01

24 Feb '01

> foreign import ccall "<gtk/gtk.h>:gtk_window_new" > windowNew :: CInt -> IO (Ptr Window) > > If the <.> are omitted in the include specification, it > corresponds to an #include"...". Don't forget you might need multiple includes, eg. <sys/types.h> & <sys/socket.h> for socket(), and ordering is important. Multiple includes could be separated by commas. I agree that adding the include spec to the foreign import declaration is a good idea because of the cross-module inlining issue (I'd forgotten about that). Marcin: I guess hsc2hs should have some magic to insert the include specs automatically :) Cheers, Simon

5 4

RE: Modification to foreign import/export
by Simon Marlow 24 Feb '01

24 Feb '01

> If we want to rule cpp as out of bounds (a very worthwhile > but difficult goal), > then we need to think about how to avoid conditional compilation too. I think the goal is not to avoid the use of cpp, but rather to avoid mentioning it in the spec. In practice, many people will be using cpp (one way or another) when they write a C-library binding. Conditional compilation is a fact of life, I don't think it's worth trying to avoid - but at least there's no need to mention it in the FFI spec. Cheers, Simon

5 7

RE: Summary of current change suggestions
by Simon Marlow 24 Feb '01

24 Feb '01

> On Fri, 23 Feb 2001, Fergus Henderson wrote: > > > OK, now how about things where you need to #define symbols before > > including the header file? > > Choose one: > 1. Write a forwarding header which #defines and #includes. > 2. Use compiler-specific switches to get #defines (-D and > -optc-D in ghc). > 3. Extend the proposed FFI to have define as well as include. > > Unfortunately option 1 doesn't always work well on ghc, because Stg.h > (included into .hc files) indirectly includes headers like <stdlib.h> > *before* user-specified -#include options, so symbols like _BSD_SOURCE > are defined too late to have any effects. This should be fixed. I agree. Would it be fixed by just #including Stg.h after any -#includes, or would that create more problems? Cheers, Simon

3 2