[m-rev.] for review: Box no-tag types in the Java back-end

[Michael Wybrow]

On Mon, 13 Jan 2003, Fergus Henderson wrote:
> 
> On 13-Jan-2003, Michael Wybrow <mjwybrow at cs.mu.OZ.AU> wrote:
> > 
> > +++ handle_options.m	13 Jan 2003 03:09:29 -0000
> > @@ -411,6 +411,11 @@
> > +	%   - box no-tag types
> > +	%         We require no-tag types to be boxed since in Java there
> > +	%         are some types (such as java.lang.String) that can't be
> > +	%         cast to another type and then successfully cast back to
> > +	%         their original type.
> 
> Could you please explain in more detail?

Ok, that didn't make a lot sense.  The problem actually comes about
because for a type

	:- type domain_error ---> domain_error(string).

the Java back-end generates something like:

	public static class domain_error_0
	{
	    public static class domain_error_1 extends m.domain_error_0
	    {
	        public java.lang.String F1 = null;

	        public domain_error_1(java.lang.String F1)
	        {
	            ((domain_error_0.domain_error_1) (this)).F1 = F1;
	        }
	    }
	}

This is fine, though with unboxed no-tag types it generates code that
attempts not to use this boxing.  Something like the following:

	mercury.math.domain_error_0 V_7_59 = null;
	java.lang.String V_8_60 = (java.lang.String) "int:'//'";

	V_7_59 = (mercury.math.domain_error_0) V_8_60;

The final line is a compile time error since the String cannot be cast to
mercury.math.domain_error_0.


> What's the problem with casting from java.lang.String to
> java.lang.Object and back again?

Nothing.  This is the only type you can cast java.lang.String to and back
again.  But you can't cast the java.lang.Object to something else between
and then cast it back to java.lang.Object before finally casting it back
to a String -- the compiler doesn't consider this a problem but you get a
ClassCastException at runtime from the java.lang.Object back to
java.lang.String cast.

Preventing unboxing of no-tag types generates code that makes use of
domain_error_1 instead of trying to cast to domain_error_0.  I assumed
this was the correct solution to the problem.  As suggested, we could
theoretically represent no-tag types with a java.lang.Object and this
would allow us not to do boxing.  Having looked at the mlds though, it
does not appear there is enough information to identify these types at
the point of code generation.  My guess is that implementing this would
require changes to the mlds rather than the back-end, which is probably
a bit out of my league ATM.  Personally I think it might be easier just
turn on boxed no-tag types for the Java back-end.  Thoughts?


Michael

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