| 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 independent. 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? Simon
On 07-Dec-2000, Simon Peyton-Jones <simonpj@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 independent.
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 Mercury compiler. 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 language. 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@cs.mu.oz.au # http://www.cs.mu.oz.au/~trd #
participants (2)
-
Simon Peyton-Jones -
Tyson Dowd