[m-rev.] for review: namespace changes

[Fergus Henderson]

On 03-May-2001, Peter Ross <petdr at cs.mu.OZ.AU> wrote:
> compiler/ilasm.m:
> compiler/ilds.m:
> compiler/mlds_to_il.m:
> compiler/mlds_to_mcpp.m:
>     For the module foo.m, place all the code in a type called
>     mercury_code in the namespace foo rather than in the type foo and no
>     namespace.  This helps avoid problems where you have a type and a
>     namespace at the top level with the same name.

The code for that diff looks OK.
The only problem I can see is that you didn't update runtime/mercury_il.il
to use the new naming convention.

But I have more serious concerns about this change.
I'm not sure (1) whether this naming convention is ideal,
or (2) whether this is the right place to make this transformation.

(1) Is this naming convention ideal?
In fact I don't understand what the naming convention is.
The naming convention should be clearly documented.
Currently there is documentation in mlds.m about how we map
Mercury names to MLDS names, and giving guidelines about
how MLDS names should be mapped to target code names.
But there's no other documentation about mapping MLDS names to IL names.
If the IL back-end is not just following the guidelines in mlds.m,
then then we need to carefully document the mapping.

> -        return mercury::array__c_code::__Unify____array_1_0(
> +        return mercury::array__c_code::mercury_code::__Unify____array_1_0(

That name is getting pretty ugly.  Why does it have both c_code and
mercury_code in it?

The name also doesn't match the documentation in the log message,
which says "For the module foo.m, place all the code in a type called
mercury_code in the namespace foo".  Here the type called mercury_code
is in a namespace "mercury::array__c_code", but there's no source
file named "mercury::array__c_code.m".  So I don't understand what's going on.

Please explain in more detail what the naming convention is, including
what happens for nested modules, procedures, types, pragma foreign_proc /
pragma foreign_code.

(2)
The other possibility is to do the transformation when generating
MLDS, rather than in MLDS_to_il.m.  So we need to ask some questions:

	(a) Is the same issue going to affect other target languages?

		C: no.  Java: yes.  C++: yes.

	(b) Should we use the same solution, or are there better solutions
	available for other target languages?
	
		For Java and C++, we can avoid the clash by using
		first-letter-uppercase for type names and
		first-letter-lowercase for namespace names.
		This might be a nicer solution.

	(c) Do we want to keep the naming convention consistent between
	different target languages?

		All other things being equal, yes.  This might make
		interoperability easier.  In particular, if you're calling
		Mercury code from Java or C++, and the Mercury code has been
		compiled with the MLDS back-end to Java, IL or (not yet
		implemented, but might be useful in the future) C++, and
		you're going to call the generated Mercury code directly
		(rather than using `pragma export'), then it would be
		nice if the way to do the call was the same regardless
		of whether the Mercury code was compiled to Java, IL or C++.

The answers to the previous two questions suggest different courses of action.
If we use a different solution when compiling to Java or C++, then
it's right to do the transformation during mlds_to_il.m.  But if
we want to use the same approach for Java, IL, and C++, then it might
be better to do it when generating MLDS (or perhaps as an MLDS to MLDS
transformation).

--
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------