[mercury-users] Problem installing with grade java

[Holger Krug]

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

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

Obviously not very difficult. But cut and paste work should be done by
the computer to reduce the probability of errors, shouldn't it ?

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

Yes, and the Java coders have to manually translate the signatures,
which also firstly is very straightforward, I admit, and therefore not
the right work for human programmers, I claim. Secondly it requires a
kind of preparation which would not be necessary otherwise.

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

Yes, that's it ! I also deem, it should be "pretty similar" to what
already has been done.  

My question now is: Is there anybody subscribing this mailing list, to
add such functionality to the Mercury tools ? We currently haven't got
the time to get acquainted with the Mercury codebase, but would be keen
to port the Mercury libraries to Java.

I repeat the functionality as Tyson and I now seem to agree on:

* Java package configurable via Makefile resp. compiler options
* output of Java skeletons or abstract base classes (I think abstract
  base classes would be better, because it would be simpler to exchange
  the implementation layer) containing:
  - one method declaration for each Mercury procedure declaration
  - method implementations for each Mercury procedure implementation
  - method stubs or method signatures declared abstract (I prefer the
    second variant) for each Mercury procedure declared but not
    implemented in Mercury (implemented maybe in C, C# or some
    other language)
  If abstract base classes are generated they should compile as they
  are without any changes.

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