[m-dev.] Signature of generated JAVA methods

[Holger Krug]

Good morning ;-)

Following your last review messages I've got the impression, that the
Java port of Mercury now is really in the main focus. That is fine !

Andree just now showed me his first generated Java code. As I
understand his work up to now he achieved to remove all the hindrances
from the Mercury compiler which "protect" the user from generated Java
code. Having taken a look at the Java code and after discussion with
Andree I have some questions concerning the signature of generated
Java code.

As I understand, Andree has to generate Code for `det' and `semidet'
procedures, because the other determinisms will be transformed away by
a HLDS transformation. Andree proposed the following signatures for
genereted Java procedures:

A) det/semidet:       Object[] name(InType1 in1, .... , InTypen inn);
   In the `semidet' case the array of Objects forming the return
   value gets one additional output parameter of boolean type.

My first proposal after Andree's presentation was:

B) det/semidet:       Object[] name(InType1 in1, .... , InTypen inn);
   For the `semidet' determinism failure is indicated by returning `null'.
   (Whereas an empty number of output parameters is indicated by
    returning an empty array.)

A third version (C) would be to include the output parameters in the
parameter list using boxing if necessary. But Andree told me that this
was already discussed and declined.

Following the approach taken in (A) and (B) I think the generated code
should contain the construction of the array of output parameters on
the users behalf, using a fixed name (e.g. `ret'). Andree told me,
that he ask you already about the name of this array, so this seems to
be on track. As a consequence of this, I deem, Andree should generate
a `return ret;' statement at the end of the method body.

Better than having a fixed name of the array of output parameters
would be the use of the same names as in the Mercury signature of the
foreign proc not only for input parameters but also for output
parameters. This would come for free with approach (C) and could be
realized in approaches (A) and (B) by parsing the Java code (what
seems to be out of the current task).

Approach (C) would have the additional advantage that the Java
compiler could type-check the code.

My questions now are:

1) Signatures (A), (B) or (C) or something different ?
2) In cases (A) and (B):
   2.1) Generate the declaration `Object[] ret = new Object[NumOutParams];'
   2.2) If 2.1 is answered by yes: what name to use for `ret'
   2.3) If 2.1 is answered by yes: generate `return ret;' at the end of
        the body
3) In the mid-term: Do you plan parsing embedded foreign language
   code or is this strictly excluded. (Grammars for the Java language are
   available for free for several parser generators, so it should not be
   too expensive to implement some simple code transformations.)
4) What thoughts exist concerning debugging Java code ? Unfortunately the
   approach taken for C code (indicate the line numbers of the originial
   code to the preprocessor) does not work for Java.

-- 
Holger Krug
hkrug at rationalizer.com
The Rationalizer Intelligent Software AG
Rudower Chaussee 29, 12489 Berlin, Germany
Tel: +49 30 678060-24
Fax: +49 30 678060-25
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------