[m-dev.] Re: Java naming issues

[Fergus Henderson]

On 16-Feb-2004, James Goddard <goddardjames at yahoo.com> wrote:
> At the moment, if you write a program with more than one module, then try to :-
> import_module one into the other, then we just output a java import statement.
> 
> eg:
> x.m:    :- import_module y.
> x.java: import y;
> 
> But y is already implicitly imported, since y.java is in the same directory as
> x.java.  (And y.class will be in the same directory as x.class).  So this
> statement is unnecessary.

How do you know that y.java is in the same directory as x.java?

What if y is a module in a Mercury library, e.g. the Mercury standard
library or e.g. the extras/complex_numbers library, which is located in
a different directory?

> Furthermore, java's `import' is only supposed to be
> used to import packages so that you don't have to refer to classes by their
> fully qualified name - it doesn't make sense to use it when there is no
> hierarchy and in fact this causes a compile-time error.
> 
> Should I modify mlds_to_java.m to never output import statements?  Provided we
> never actually need to import anything, (and we shouldn't if we always use
> fully qualified names) this will work fine and solve this particular problem.

I think it is useful to be able to see at a glance which module(s) a
module depends on, so I think it may be worth still outputting this
information, even if it is only as a comment at the start of the generated
Java code.  But otherwise your suggestion sounds fine.

> The second problem comes with sub-modules.  If I declare a sub-module `sub'
> within x, I get out a file `x.sub.java` containing class `x.sub` but Java
> doesn't like this.  Specifically, it decides there's a syntax error when it
> gets to the dot.  Also, I noticed that we output a `package x` statement, which
> doesn't make sense according to Java's naming conventions.  I see three
> solutions:
> 
> 1. Output class sub as an inner class of x, within x.java.
> 2. Produce instead `x__sub.java' containing class `x__sub` (and get rid of the
> package statement)
> 3. Create a subdirectory `x' within both `javas' and `classs' in which to keep
> class `sub'.
> 
> I don't know how easy it will be to apply any of these fixes, but number 2
> seems  the simplest to me.  Let me know what you think.

I think number 3 is the right approach.

Approach 1 isn't going to work properly with separate sub-modules.
In particular the Mercury language reference manual says "Implementations
should support separate compilation of separate sub-modules.", and that's
not really possible with approach 1.

Approach 2 might perhaps be a little easier to implement than approach 3,
but it is not idiomatic Java, and so it is not good for interoperability
with Java or other languages that generate Java.

P.S. Please add "sub-modules" to the list of not-yet-supported features
in README.Java.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------