[m-dev.] for review: Java backend

[Julien Fischer]

I've finished addressing the review comments and I'll repost the Java
backend shortly.

There were a few things raised in the review:

On Fri, 16 Feb 2001, Fergus Henderson wrote:

> On 14-Feb-2001, Julien Fischer <juliensf at students.cs.mu.oz.au> wrote:
> > 
> 
> > +mlds_output_initializer_body(init_struct(FieldInits)) --> 
> > +	io__write_list(FieldInits, ",\n\t\t", 
> > +		mlds_output_initializer_body).
> 
> Do you need to wrap curly braces around the fields, like you do
> for init_array?

No, because structs are represented as objects.  So we need to create a
new object at this point.
e.g      <class_type> <name> = new <class_type>(field1, ... ,fieldN);
In at the moment, excepting RTTI data, we just assign values to the fields
directly (this situation will probably be reversed eventually as the RTTI
data will probably be need be assigned directly to the fields, to avoid
problems with forward references, while we should be generating (Java) 
constructors for every other object)  

> > +:- pred mlds_output_module_name(mercury_module_name, io__state, io__state).
> > +:- mode mlds_output_module_name(in, di, uo) is det.
> > +
> > +mlds_output_module_name(ModuleName) -->
> > +	{ llds_out__sym_name_mangle(ModuleName, MangledModuleName) },
> > +	io__write_string(MangledModuleName).
> 
> That looks wrong; llds_out__sym_name_mangle will qualify names
> with `__', but for Java they should be qualified with `.'.
> 
> If this is needed at all, it should probably be named something
> different, e.g. `output_module_name_as_single_identifier'
> or `output_mangled_module_name' or something like that.
> But I think you need to look at all of the callers to this
> to see whether it is appropriate to use `.' or `__'.
> 
> You should try some of the tests of nested modules (e.g.
> see tests/hard_coded/sub-modules), and if they don't succeed,
> then you should add nested modules to the list of things that
> don't work.

You're right, it is wrong but at the moment it only used to output
unqualified names (with one exception) .  I'm not sure that fixing it
specifically for the Java backend would be particularly helpful. I think
that the name mangling code should be extracted from the
LLDS backend and wherever else it is hiding and put in its own module,
preferably with predicates that allow the caller to specifiy whether to
use `.' or `__'. 
 
> > +mlds_output_stmt(Indent, FuncInfo, return(Results), _) -->
> ...
> > +	; { Results = [Rval] } ->
> > +		io__write_char(' '),
> > +		% XXX the ml code generator should not generate these.
> > +		( { Rval = mlds__lval(Lval),
> > +		    Lval = var(VarName, _),
> > +		    VarName = qual(_, UnqualName),
> > +		    UnqualName = "dummy_var" } 
> > +		
> > +		->
> > +			[]
> > +		;
> > +			mlds_output_rval(Rval)
> > +		)
> 
> Fix the layout of the condition of that if-then-else.
> 
> Why is that code needed? 
> When does the ml code generator generate such assignments?

Assignments? I'm not sure I know what you mean by that.  This relates to
generating return statements.  The code generator generates the
dummy_var's in ml_code_util.

> > +	%
> > +	% heap management
> > +	%
> > +mlds_output_atomic_stmt(_Indent, _FuncInfo, delete_object(_Lval), _) -->
> > +	{ error("mlds_to_java.m: delete_object not supported in Java.") }.
> 
> Why not just use `delete'?

Because Java doesn't have `delete'.  I think this should be implemented
just by setting the reference to null.  See:

http://developer.java.sun.com/developer/TechTips/1997/tt0903.html#tip2

for a slightly contrived example of why this might be useful.

> > +mlds_output_rval_const(string_const(String)) -->
> > +	io__write_string(""""),
> > +	c_util__output_quoted_string(String),
> > +	io__write_string("""").
> 
> Likewise here.
> 
> > +mlds_output_rval_const(multi_string_const(Length, String)) -->
> > +	io__write_string(""""),
> > +	c_util__output_quoted_multi_string(Length, String),
> > +	io__write_string("""").
> 
> And here.
 
With regards to these two, c_util__binary_infix_op and the other stuff
from c_util.m.  I've created java versions of most of them in the file
java_util.m.  Since Java and C are almost identical at this level anyway
I'm not sure that it is strictly necessary, although it probably is nicer
to have the Java backend independent of the C one.  I've added creating
java_util__output_quoted_string/multi_string to the TODO list but as the C
versions work perfectly well it isn't a priority at the moment.

Julien




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