[m-dev.] multi-language definitions

[Tyson Dowd]

On 25-Feb-2002, Holger Krug <hkrug at rationalizer.com> wrote:
> 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).

This is almost exactly what we do for foreign_proc MC++ on .NET, or
foreign_proc C on the gcc back end.

You could implement this by simply writing

:- pragma foreign_proc('Java', foo(X::in, Y::out), [promise_pure], "
	// XXX fill this stub in
").

for each foreign_proc.  This has the advantage that you can also name
the variables X and Y.

> 
> 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.

Another way to do this is to make Genclass_fallback an (abstract?) base
class and Genclass_fallback_implementation a derived class that provides
the implementations.  Then you don't have to worry so much about
overwriting Genclass_fallback.

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

Nothing too difficult about it, as long as it's all in the same
assembly.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------