[mercury-users] Problem installing with grade java

[Holger Krug]

On Fri, Jul 13, 2001 at 03:52:44AM +1000, Fergus Henderson wrote:
> Well, before that can be done, the first step is to implement the compiler
> support for `pragma foreign_proc("Java", ...)'.

To save typing one could use the module system of Java (i.e. classes)
and establish a 1-1 relationship between Mercury modules and Java
classes using a pragma called e.g. `foreign_module' used in a way
like:

:- module my_lib_module

:- interface

% some interface code

:- implementation

pragma foreign_module("Java", "au.oz.mu.cs.mercury.stdlib.MyLibModule")

% further implementing code (Mercury and C code)

All Mercury procedures which are declared but not defined (or only
defined in other languages than Java) have to be implemented in the
Java class au.oz.mu.cs.mercury.stdlib.MyLibModule. For this purpose a
scheme for the unequivocal naming of Mercury procedures in Java must
be defined.

An additional Mercury compiler option generates the class structure
(including - static - method signatures) of
au.oz.mu.cs.mercury.stdlib.MyLibModule automatically from the Mercury
code.

If somebody from Melbourne could implement the infrastructure for this
(i.e. define the naming scheme and implement the additional pragma and
the Java code generator) I think the user community (including our
company) would fill the library gaps in short time, because the task
would be reduced to straightforward Java coding.

A further simplification without using any kind of pragma
could be achieved using compiler options like:

mmc --use-java-class au.oz.mu.cs.mercury.stdlib.MyLibModule
mmc --generate-java-template au.oz.mu.cs.mercury.stdlib.MyLibModule

--use-java-class instructs the compiler to forget about all
implementation in C etc. within the module and use the java class
au.oz.mu.cs.mercury.stdlib.MyLibModule for the implementing Java code.
mmc would only translate Mercury code to Java and use
au.oz.mu.cs.mercury.stdlib.MyLibModule for those Mercury procedures
which are declared in the module but not defined using Mercury. (It
would not be necessary for the Mercury compiler to know anything about
au.oz.mu.cs.mercury.stdlib.MyLibModule but the name. The Mercury
compiler would presuppose certain method signatures for
au.oz.mu.cs.mercury.stdlib.MyLibModule to exist. Later on the Java
compiler claims, if au.oz.mu.cs.mercury.stdlib.MyLibModule does not
correspond with those assumptions.)

--generate-java-template generates the template Java source code for
au.oz.mu.cs.mercury.stdlib.MyLibModule.

To generalize this second approach would be straightforward. Hence
further ports of Mercury libs to other modularized languages would be
very simple without any needs to change Mercury code !

Maybe the remarks made remain valid for the .NET port of Mercury, too ?!

-- 
Holger Krug
hkrug at rationalizer.com
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------