[m-rev.] for review: namespace changes

[Peter Ross]

On Thu, May 03, 2001 at 03:25:27AM +1000, Fergus Henderson wrote:
> 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.
> 
Yes I found that while testing the change.

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

The current convention is that the namespaces are derived from the
module name, with some exceptions for foreign code and the std lib.  ie
the module foo will create a namespace foo, the submodule bar in the
module foo will create a namespace foo.bar an so on.  However due to the
object oriented nature of the .NET backend we need to have a class name
declared inside the namespace to hold the code.  Seeing that we are
going to be generating IL representation of the mercury code,
mercury_code seemed as good a name as any for the class.


> > -        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?
> 
Because it is not that trivial to fix.  I would prefer to use the name
mercury::array::c_code::__Unify____array_1_0.  I do plan to fix this in
the future, but it is not the best use of my time while I have trd here.

> 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.
> 
There is a filename called array__c_code.cpp, so that is where the name
comes from.  The mercury, I believe, is your fault.  There is a whole
bunch of special case code which appends the mercury in front of anything
which comes from the std library.  I actually don't like that because it
doesn't seem very elegant to me and just leads to maintainability
headaches, if that is what we wanted then we should move the std library
into a sub module of mercury.

> Please explain in more detail what the naming convention is, including
> what happens for nested modules, procedures, types, pragma foreign_proc /
> pragma foreign_code.
> 
I only know the convention for nested modules which I explained above,
the rest you will have to ask tyson.

> (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).
> 
Definately something to think about.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------