[mercury-users] Problem installing with grade java

[Tyson Dowd]

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

We also plan to cut down on the amount of foreign code by doing
more of the standard library in Mercury and less of it in foreign
language code.

But you are right, there will be more foreign language code in the
library if we do more ports.  This code has be be stored somewhere.
A certain amount of it must be written in foreign languages.

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

Well they don't *have* to review changes, but it is likely that they will.

> * The people doing language ports of libraries have to change the
>   Mercury source file. They have to understand Mercury more than
>   necessary.

Absolutely true.

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

Actually quite a bit of it is written in Belgium, France and the UK.
Right now I am adding the .NET port from Belgium.

But it could be easier for other people to add code.

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

Ok, this kind of thing would be nice in some ways, although I think you
are overstating how difficult it will be to do -- the Mercury code you
write is simply a cut and paste of the MC++ or C implementation, with
the code removed, and then you fill it in with Java. 

But let's explore how it could be implemented...

If I were to add something like:

:- pragma import("Java", mercury_predicate_name(in, in, out),
	"au.oz.mu.cs.mercury.stdlib.modulename.mercury_predicate_name").

then as long as you put the right type signature into the Java file, it
will work.  You would have to add :- pragma imports all over the library
(but just once -- this code needs very little reviewing and no
maintenance).


We could also add an option to the compiler that automatically assumed
that there is an import statement for every single predicate that has no
clauses (you suggested this in your previous mail, now I'm just talking
about how it could be implemented).


It would be a bit more work to output the skeletons (base classes)
for you to subclass (or stubs for you to fill in).  I'm thinking it will
be pretty similar to how we generate the C# code now, except that we
will leave all the bodies of the code empty.

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

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