[m-rev.] Java back-end milestone

[Fergus Henderson]

On 02-Dec-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> Using the low-level representation on the IL backend is painful, which
> is why I devoted a lot of time to writing the algorithms for RTTI in
> Mercury and using only C# to access the actual fields in the RTTI.  I
> assumed that this work would also have been useful for the Java backend.

It still will be, I think.
But a fair bit of work is still required before we get to that point.

> > Secondly, there are 50 different procedures defined in C# in
> > rtti_implementation.m.  That's quite a lot.  So implementing all of
> > those in Java would be quite a bit of work, even if it wasn't for the
> > issue of low-level vs high-level data.
>
> They are essentially all accessor functions,

Yes.

> and the Java implementation
> should simply be the same as the C# implementation
> so IMO the implementation work should be on the order of 1 day.

The Java implementation will not be the same as the C# implementation
unless we change compiler/mlds_to_java.m to use a low-level data
representation for the RTTI types, but that in itself would probably
be a considerable effort (and going backwards).

However, that said, the Java implementation should not be _too_
complicated -- it's just that the accessor functions would need to
access the Java definitions of the RTTI types, rather than using
the low-level definitions.  However, for that to work, the class
hierarchy for the Java RTTI types needs some restructuring so that it
actually works, and we may perhaps also need some changes to the way
mlds_to_java.m generates code to construct the RTTI data.

> In summary, it appears that you have an implementation decision for the
> Java backend.
>     * Keep developing a high level RTTI.
>     * Reuse the work done for the IL backend.

These two are not necessarily mutually exclusive.  I think we can reuse
much of the work done for the IL backend while using a high level RTTI.

>     * Wait for zs to implement outputting the RTTI structures in Mercury.
> 
> My personal preference is the third option.

Mine too, in the long run.  But in the short run, I prefer the first one/two;
that way, we can start implementing the rest of the Mercury standard
library in Java without needing to get RTTI working first.

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