[mercury-users] Problem installing with grade java

[Holger Krug]

On Wed, Jul 18, 2001 at 02:08:38AM +1000, Tyson Dowd wrote:
> We do something quite similar to this for the .NET backend when
> interfacing to C# or managed C++.
> 
> We don't have this, but we do automatically generate a .NET module if a
> Mercury module contains (say) C#.

What you are doing (have done), I suppose, is to extend Mercury's C
Interface to other languages like C#, maybe Java, and so on. If you
proceed this way implementing several language ports, the Mercury
project will become almost unmanageable out of the following reasons:

* Every language port adds new pragma's to the Mercury sources. After having
  ports to C, C#, Java, Python and Perl etc. the Mercury sources are a
  huge collection of pragmas with the percentage of real Mercury code being
  almost 0.
* The maintainers of the standard library files have to review changes
  in all of the language ports, which is very time consuming and makes no
  sense. The other solution would be to have several maintainers for one
  single file, one for each language port, nothing to be glad with.
* The people doing language ports of libraries have to change the
  Mercury source file. They have to understand Mercury more than
  necessary.

You can solve all these issues when almost all code comes from
Melbourne, because you have regularly meetings and the creators of the
language who guide the process. But it becomes very difficult for you
(as managers of the process and maintainers of the files) and external
contributors (as possible contributors of language ports), if anybody
from outside wishes to add a language port to the Mercury libraries.
(Not to speak about the Mercury runtime, which is outside my current
scope.)

I'm going to exemplify (and improve) further what I yesterday tried to
explain, taking Java as an example:

Suppose our company (The Rationalizer) wants to add a Java port to the
Mercury libraries (what we really want to do). Suppose we get versions
of mcc/mmake from you, which can be called in the following way (from
inside the library subdirectory of the Mercury distribution):

# variable `JAVA_PACKAGE' set in Mmakefile to something like
# `au.oz.mu.cs.mercury.stdlib'

$mmake --use-subdirs store.java

When calling `mmake' not any single changes were made to the Mercury
sources as they are today. `mmake' called this way creates a file
`Mercury/java/au/oz/mu/cs/mercury/stdlib/StoreAbstract.java' containing:

* An abstract class au.oz.mu.cs.mercury.stdlib.StoreAbstract
* Java translations of Mercury predicates and functions, which were
  defined using the Mercury language in store.m.
* Abstract methods (i.e. method signatures) for those Mercury predicates
  and functions, which were declared in store.m, but not defined there
  using the Mercury language (i.e. defined either in some other language,
  e.g. C, or even not at all).

The one who is responsible for the Java port now has to derive a
concrete class (say Store.java) from the abstract one, implementing
those methods not implemented in StoreAbstract.java. It's the usual
Java work for a common Java programmer. He/she has to know very few
about Mercury.  After having finished this work, Store.java and
similar files will be delivered to Melbourne for inclusion into the
distribution. The only thing necessary to do at Melbourne would be to
add some Makefile options, that's all. The interface between the
porters of the stdlib's to Java and the core Mercury maintainers would
be very simple. The Java guy must not have any deep understanding of
Mercury and the Mercury maintainers must not review any changes made
to the core library files maintained by them, because there are no
such changes.

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

Because you add C# implementations to the Mercury sources, an approach
working in your case but having the deficiencies as described above.

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

As I said, porting the stdlib's to Java is a task, we would like to
fulfill. But, as I also said, I think, slightly changed tools could
simplify the management of the process from your as well as from our
side a great deal.


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