[mercury-users] Problem installing with grade java

[Tyson Dowd]

On 17-Jul-2001, Holger Krug <hkrug at rationalizer.com> wrote:
> 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:

We do something quite similar to this for the .NET backend when
interfacing to C# or managed C++.

> 
> :- module my_lib_module
> 
> :- interface
> 
> % some interface code
> 
> :- implementation
> 
> pragma foreign_module("Java", "au.oz.mu.cs.mercury.stdlib.MyLibModule")

We don't have this, but we do automatically generate a .NET module if a
Mercury module contains (say) C#.

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

We already do all of this, except that we not only generate the class
structure, we fill it in with method declarations and bodies that
contain the C# implementations...

:- func to_string(T) = string.
:- pragma foreign_proc("C#", to_string(X::in) = (S::out), [], "
	S = X.ToString(X);
").

becomes:

using mercury;

namespace @multilang__csharp_code {
public class mercury_code{
public static System.String to_string_2(System.Object[] TypeInfo_for_T, System.Object X)
{
int succeeded;
System.String S;
{
        S = X.ToString(X);
return S;
}
}

:- external can be used to do similar things but it is harder to use
with language such as Java or C# because they don't let you define
one class in multiple files.

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

If someone is going to actively work with the Java backend I'd be pretty
happy to do this.

The task is *mostly* straightforward Java coding, but due to the
immaturity of the Java backend and the fact that not everything always
matches up 100% it can be a bit more difficult than that.
It depends what kind of librar code you are writing.

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

Yep -- as you can see we are going doing this path already.

We also have a branch of the compiler where you can declare foreign_types
(which correspond to .NET types) and use type classes and pragma
foreign_class to expose a Mercury type class as a .NET class with
inheritance.

All of this work should be pretty much transferrable to the Java backend
too.

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