June 2002 - FFI - Haskell.org

RE: Library archives
by Simon Marlow 11 Aug '02

11 Aug '02

> I see a lot of discussion about header files. > I see a small amount of discussion of libraries with many conflicting > suggestions. > I see no _conclusion_. Ok, I can't see the conclusion either, but I seem to recall that at one stage the library specs were removed from the spec altogether and only came back again because of .NET (no, I'm not sure why they're in the C section of the FFI spec either). >From the GHC perspective they're not useful, and it would be headache to implement them if we had to. Fortunately the current spec says that they are a "hint" only, so we don't have to implement them. But that causes problems for anyone wanting to write portable FFI code: by definition, because the interpretation of the lib spec is implementation dependent, it can't be used in portable code. So really, I think it should be removed. If the FFI spec says anything about libraries, IMHO it should say that the methods used to find and link against external libraries are implementation dependent. We as implementers can always get together and agree on a common mechanism (packages, command-line arguments, whatever) to make life easier for the punters. > ps In case it wasn't clear > yesterday, I think the spec should be > clear about whether C libraries live in local or global namespaces. > I propose that they should be in a single global > namespace. This will require no change to GHC but will require a change to > Hugs' historical behaviour. Fine by me. Cheers, Simon

4 3

More on Ptr types
by George Russell 22 Jul '02

22 Jul '02

By the way, you lot are aware that under the old ANSI C standard at least, pointer types can have different sizes depending on the type? Thus a pointer to a properly-aligned 64-bit entity needs 3 less bits than one to an 8-bit entity, and implementations are entitled to use this. The only guarantee I can remember is that (void *) is big enough to represent everything. Does this affect things at all?

4 7

Getting constants from #defines
by Ian Lynagh 27 Jun '02

27 Jun '02

Hi all, I was expecting something like foreign import ccall unsafe "static ncurses.h ERR" cERR :: CInt to allow me to access the value of ERR (a #define) as cERR. However, as far as I can tell GHC is trying to compile this as if ERR was a function. This seems silly to me as a function can always be defined with a type "a -> b" where "a", "b" or both can be "()" so this should be unambiguous. Am I misunderstanding what is going on here? Thanks Ian

2 1

RE: Getting constants from #defines
by Simon Marlow 26 Jun '02

26 Jun '02

> I was expecting something like > > foreign import ccall unsafe "static ncurses.h ERR" cERR :: CInt > > to allow me to access the value of ERR (a #define) as cERR. > However, as > far as I can tell GHC is trying to compile this as if ERR was a > function. This seems silly to me as a function can always be defined > with a type "a -> b" where "a", "b" or both can be "()" so this should > be unambiguous. The FFI doesn't have support for grabbing the values of #defines - you need to use another tool to do this (autoconf, hsc2hs, c2hs, green-card, hdirect, whatever). The declaration above binds cERR to a function of zero arguments. i.e. in C-speak this would be void cERR( void ); A function of type a->b has one argument of type 'a', not zero. Cheers, Simon

2 1

Greencard-Canada-Aupair
by Greencard 25 Jun '02

25 Jun '02

1 0

Re: Problem with FFI?
by Alastair Reid 21 Jun '02

21 Jun '02

[reply redirected to ffi(a)haskell.org] John Meacham <john(a)repetae.net> writes: > I may be missing something obvious here, but from the current FFI > spec it appears that it is impossible to create libraries in haskell > which are meant to be called from c code without running into > undefined behavior. The problem is in the definition of hs_init() > and hs_exit() . now, it is acceptable to have hs_init and hs_exit > called in the initialization and finalization of your library, but > the problem arrises when you link against more than one library > which is implemented in haskell, suddenly whichever library is > initialized secondly segfaults! (or whatever undefined behaviour > means.). programs could suddenly stop working when a library is > changed from a c implementation to a haskell one, which seems to be > a bad thing. Hmmm, I see what you mean. > proposed fix: allow nested calls to hs_init, hs_exit, a counter is > incremented when hs_init is called more than once, and decremented > on hs_exit. only the last call to hs_exit will actually do whatever > needs to be done. The hs_init function takes arguments - what if each call to hs_init specifies a different set of arguments? How about: hs_set_hs_argv (int argc, char *argv[]); hs_set_prog_argv (int argc, char *argv[]); hs_init (); hs_exit (); Where: hs_set_hs_argv sets command line parameters for the Haskell runtime system It can be called at most once and that call must be before the first call to hs_init Warning! The flags are not remotely portable between different Haskell runtimes. hs_set_prog_argv sets arguments seen by getProgName and getArgs It can be called at most once and that call must be before the first call to hs_init hs_init initializes the Haskell runtime It can be called multiple times and must be called before the first call to any function exported by the Haskell code. hs_exit finalizes the Haskell runtime hs_init and hs_exit are required to satisfy the usual bracketing rules: 1) At any time, the number of calls that have been made to hs_exit must be no more than the number of calls that have been made to hs_init. 2) If the number of calls to hs_exit is equal to the number of calls to hs_init, then no further calls to hs_init may be made. By the way, the name 'hs_exit' is a little confusing - I expected it to have an ExitCode argument. 'hs_fini' would better match its actual purpose. > note that this cannot be implemented by the programmer himself since > there might be several third party libraries also implemented in > haskell which an app wishes to link against. You can implement the modified API (or your modified semantics) quite readily as a little library which you link against your program. All you have to do is tweak the names a little (e.g., s/hs/HS/) to avoid name clashes. -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

2 2

Real ZOO web site, welcome! ID<iilCkdvnhoo1ruj>
by Farmgirl10585 20 Jun '02

20 Jun '02

1 0

RE: Library archives
by Simon Marlow 19 Jun '02

19 Jun '02

> The questions that come up as I implement the ffi are mostly things > that are not clear from the spec. This is a particularily good > example of that - there's no example and the explanation is brief and > open to many interpretations. I could hunt through the archives and > guess at what the final decision was or I could ask for clarification > so that we all agree on what change is needed to the report (or I look > foolish when the appropriate section of the report is pointed out to > me). > > In this case, all I could find was a brief discussion with no final > conclusion. (Or maybe I missed the conclusion - the subject lines one > the messages are fairly uninformative so I skimmed old mail fairly > quickly.) See these threads, for example: http://www.haskell.org/pipermail/ffi/2001-February/000212.html http://www.haskell.org/pipermail/ffi/2001-May/000345.html Cheers, Simon

2 1

Re: freeHaskellFunPtr
by Sven Panne 18 Jun '02

18 Jun '02

Alastair Reid wrote: > This looks fairly delicate [...] Agreed. :-} > It seems like your example could be handled by calling the free > function in the Haskell code that invokes the C code that invokes the > callback: [...] My Haskell callback is actually a one-shot timer callback from GLUT, and I'm not directly "invoking the C code that invokes the callback": After an initial setup phase, *everything* is callback-driven, so your proposal is not a solution here. > How much worse would it be to write your code in this way? Hmmm, it looks like I have to resort to a "global variable" hack for tracking the (un-)registration of other callbacks, anyway. The problem is as follows: If you repeatedly set or clear a Haskell callback, you have to track what the C side already knows on the Haskell side, too, just for freeHaskellFunPtr. :-P The additional problem with those one-shot callbacks is that only the callback knows when to deregister. In a nutshell: I'm not very happy with the explicit allocation and deallocation of the 'foreign import wrapper' thunks. They are an artefact of the Haskell implementations and look strange in an otherwise GC-ed world... Anyway, the documentation of freeHaskellFunPtr should be made a little bit clearer about what we decide. Cheers, S.

2 1

RE: Library archives
by Simon Marlow 18 Jun '02

18 Jun '02

> In conclusion, C is designed to use a single global namespace and > things break if you try to change that. Hence, I don't think the ffi > for C can allow C libraries to export overlapping names. I think the > ffi spec should explicitly say that all C libraries are loaded into a > single global namespace. And I don't think the square bracket part > can be treated like a Haskell qualified name. Agreed. The library spec part of an FFI declaration is not indended to replace the specification of libraries by command-line options or packages. We had a long discussiong about this a while back (sorry for sounding like a broken record!), where some people argued that libraries should be specified in the FFI declaration in the source code, and some people (inc. me) argued that libraries should be kept out of the source code altogether, on the grounds that they were too system-dependent and it would be impossible to write portable code without resorting to CPP. There were other reasons, but I can't remember them all now. > The package system provided by GHC and NHC provides an alternate place > where libraries could be specified. Can someone familiar with > packages and with Hugs comment on whether they'd be able to replace > the ffi's library spec and would make sense for typical Hugs usage. > And would that meet SimonPJ's need too? I'd be delighted if Hugs adopted a package system similar to GHC's - we even considered that possibility by including a field in the package spec for specifying where source code for a package lives (which is unused by GHC). I'd be surprised if GHC's package system couldn't be used relatively unchanged in Hugs. All you need to do is: - on starting Hugs, read a package config file (unfortunately I guess you'll need a yacc parser for that) - augment the search path with directories from packages specified on the command line (the source_dirs field of the package spec) - dlopen() libraries from packages (the extra_libraries field of the package spec). Cheers, Simon

2 1