Mon Feb 21 07:28:50 EST 2005
But I don't understand why .net concerns affect the ccall calling
convention instead of the dotnet convention?
Portability seems to be a major problem - even if we restrict
ourselves to Unix systems, there's no sense in being able to specify
libX11.so unless you can also specify the directory. Which directory
will that be? Well, it varies from one system to another.
Can someone come to the defence of the lib specifications because, at
the moment, I see no argument for keeping them in the spec. The only
thing they might be useful for is that often an ffi module needs a
little file of support code and it's convenient to have a way of
mentioning that file.
(btw This isn't me trying to get out of implementation work: Hugs now
supports the lib specifications and, as of last night, is able to load
and run the HGL examples. To achieve this, I had to fix GreenCard
which had clearly not been required to generate a library spec for
some time since what it generated was syntactically incorrect.)
> I'd be delighted if Hugs adopted a package system similar to GHC's
I think I'd be happy if this happened too - but I think I'll leave
that to someone else...
In the meantime, I'm leaning towards the following interface for Hugs
(GHCi and other interactive systems might provide a similar interface):
hugs +G Foo.hs --lib="-L/usr/X11R6/lib -lX11 -lc"
or, simpler still,
hugs +G Foo.hs Bar.hs --lib="/usr/X11R6/lib/lib/X11.so.6 /usr/lib/libc.so.5"
[The +G flag is a way of telling Hugs that it is to generate ffi code
not to load and run code - so this is something that tends to be
written at program install time not during normal runs.]
Anything needing compiled as a result of loading Foo and Bar will be
linked against these files. GHCi could do something similar but it
would start by loading these files into the global namespace and then
any dynamically loaded code or foreign imports would do lookups in
[Actually, Hugs probably would not use --lib= because Hugs
traditionally uses cryptic, confusing flag names...]
Alastair Reid reid at cs.utah.edu http://www.cs.utah.edu/~reid/
More information about the FFI