extended foreign decls
trd at cs.mu.OZ.AU
Thu Dec 7 07:42:57 EST 2000
On 07-Dec-2000, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
> | For ("preferred" language, foreign language) pair, you define an
> | "extrusion". This defines how to generate the appropriate code to
> | interface with one foreign language in another.
> All sounds very ingenious. Much of it, though, is quite Mercury
That's why I'm game to mention it on a Haskell list ;-)
> As you say, it's a way of making the Mercury compiler think it's only
> talking to C.
> Obvious question: do you plan to package your solution as a reusable
> tool, so that others can profit from its ingenuity?
At the moment the "extrusion" (for want of a better name, I'm probably
going to find the standard terminology some day) is built into the
To make it a separate tool, you would need to provide it with some idea
about the parameters that need to be passed to the foreign code. For
example, it would need to know about the types (so as to be able to
marshall correctly) and whether the parameters are inputs or outputs.
If you have this information, you should be able to generate the
appropriate extrusion into C code, and the corresponding wrapper around
the other foreign language. Since the extrusion and the wrapper are
only in C/foreign language, it should be able to be used by any
I have no plans at present to do this (thesis pressure is building).
But I am not far down the path of implementing the code in the Mercury
compiler, so I will see how far I can separate out the extrusion code
(when I next get a chance to work on it, that is).
The major complication I see arising is that you might want quite
detailed type information, which could be language specific. But that
could be made pluggable.
Of course, all you would have to do is make a Mercury binding for
Haskell, and you could get it all for free ;-) (no, no just kidding,
stop hurting me!)
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
trd at cs.mu.oz.au #
More information about the FFI