I'm not sure if [EMAIL PROTECTED] is the appropriate place for an
observation/opinion piece - it was the only mailing list mentioned
on the FFI specs release page and in the specs themselves.
If there's a more appropriate mailing list for this commentary,
let me know.
First some background info...
Haskell has been my first PL of choice since April 2000 but have
been swatting up on the language and related topics since April
1999, so I have a general overview of most of the concepts behind
the language and FP in general. "Amateur software research and
development" is currently my main recreation (for better or
worse!). My primary Haskell system is Hugs, with occasional
but slowly increasing usage of HBI & HBC.
Enough background...
From what I've read, the FFI's approach to achieving
interoperability looks like The Death Of One Thousand Cuts for
Haskell. This is most clearly demonstrated by those laughable
special identifiers (page 3) denoting specific call conventions
which future Haskell implementations would have to be contorted
into supporting. (what will be next? "chash","asm","intercal",
"vb"..?)
From http://www.haskell.org/ghc/overview.html:
"We think that Haskell is a great language
to write applications in, and are dead keen for
GHC to be used for this purpose."
If we all accept this statement for all mature Haskell compilers
the we must hold our ground - rather than dropping down to the
standards of other languages, those languages come up to the
standard of Haskell.
The mechanism to do this already exists in Haskell, but its use
has hitherto been confined to Haskell - module imports.
The interoperability challenge then becomes: how do I bundle up
that C/C++/.NET/Java/etc library into a Haskell module?
Encapsulated as Haskell modules, old libraries can then
access and be accessed by code from other Haskell modules
using the standard import/export mechanism.
So instead of having Haskell implementations handle the calling
conventions of C, C++, Java, .NET, etc, the Haskell calling
convention is handled by the Haskell module encapsulators for
C, C++, Java, .NET, etc, hence moving the complexity out
of already-complicated Haskell implementations into separate
libraries or modules.
The problem of Haskell interoperability is reminiscent of the
problem regarding numeric types during the original definition
of Haskell: how to have overloaded arithmetic operators over
separate numeric types (unlike Miranda(TM)) which could be used
to define new overloaded functions (unlike Standard ML).
In this case the problem becomes: how to enable foreign code
access between Haskell and other languages without rewriting
the Haskell-side access mechanisms for each language.
Type classes were the adopted solution then - perhaps they are
the solution now:
data C = ....
data CPlusPlus = ....
data Java = ....
data DotNET = ....
:
:
class Foreign l where ....
instance Foreign C where ....
instance Foreign CPlusPlus where ....
instance Foreign Java where ....
instance Foreign DotNET where ....
:
:
Anthony Travers (amt DASH public AT dodo DOT com DOT au)
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
