[m-dev.] multi-language definitions

Holger Krug hkrug at rationalizer.com
Mon Feb 25 18:47:25 AEDT 2002


On Sat, Feb 23, 2002 at 03:01:47PM +1100, Zoltan Somogyi wrote:
> On 22-Feb-2002, Holger Krug <hkrug at rationalizer.com> wrote:
> > Is that really necessary ? For a backend for which no definition
> > exists, you could simply produce a function call (method call) in the
> > target language and, if supported by the target language, a function
> > declaration. And print out a *warning* that these functions still have
> > to be implemented in the target language *or* defined within
> > Mercury.
> 
> I am not sure whether this is feasible for the .net back end. Tyson?

I don't know .net, but for Java it could be done the following way:

Generate a class `Genclass', which contains generated implementations
of all Mercury procedures. For those, for which neither a Mercury nor
a Java implementation was defined in the Mercury code, this class
simply forwards method calls to a second class
`Genclass_fallback'. For `Genclass_fallback' the Java backend only
generates method stubs (signatures without body or with invalid body,
such that the Java compiler claims).

The advantage of this approach is that after the following order of
implementation steps:

1) Mercury declaration without Mercury or Java implementation
2) generate `Genclass' and `Genclass_fallback'
3) fill method stubs in `Genclass_fallback'
4) implemented some of the initially unimplemented procedures in Mercury
   or add the Java implementations into the Mercury code

`Genclass_fallback' must not be rewritten, though some of the
procedure implementations in `Genclass_fallback' became obsolete.

I think for .net a similar approach should be feasible. Tyson ?

-- 
Holger Krug
hkrug at rationalizer.com
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list