[m-dev.] multi-language definitions

[Holger Krug]

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

Or even better: they throw a `MethodNotImplemented' exception, such
that the code runs whenever the procedures aren't needed. So you can
use the Mercury lib's whenever you do not need methods which aren't
needed by your backend. In this case the Mercury compiler has to give
a detailed report, what procedures still must be implemented.
 
> The advantage of this approach is that after the following order of
> implementation steps:

A further advantage would be:

The costs to port Mercury libraries to other backends would be
lowered. The steps would be:

1. Actuate the Mercury compiler and generate the stubs
2. Fill in and test the stubs
3. Integrate the stub implementations into the Mercury code

Step 1 needs almost no time.

Step 2 is the most time-consuming step and needs no active knowledge
of Mercury, because the people doing this wouldn't see any mercury
code. A great part of the work could be done by programmers having
good experience in the target language.

Step 3 needs a Mercury programmer on a copy-and-paste level.

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