[m-dev.] Re: Signature of generated JAVA methods

[Fergus Henderson]

On 19-Feb-2002, Holger Krug <hkrug at rationalizer.com> wrote:
> On Tue, Feb 19, 2002 at 11:52:40PM +1100, Fergus Henderson wrote:
> > > As I understand, Andre has to generate Code for `det' and `semidet'
> > > procedures, because the other determinisms will be transformed away by
> > > a HLDS transformation.
> > 
> > For `pragma foreign_proc', yes, that's correct.
> 
> That is our current focus.
> 
> > > Andre proposed the following signatures for genereted Java procedures:
> > 
> > Do you mean these signatures should be used for Java procedures imported
> > to Mercury or exported from Mercury with the Java interface equivalents of
> > `pragma import' and `pragma export'?
> 
> I spoke about the code generated from `pragma foreign_proc'.

Then what you said doesn't make sense, since there are no function
signatures involved in `pragma foreign_proc'.

After inlining (an HLDS->HLDS optimization), a `pragma foreign_proc'
HLDS goal can occur anywhere in the body of any procedure.
And the Java code that the foreign_proc goal contains need
not call any functions.  Executing such a goal does not
involve any Java function calls.

The input and output parameters and the success indicator are
communicated with the Java code fragment via named local variables.

Talking about signatures only makes sense for (a) `pragma export',
(b) `pragma import', and (c) ordinary code generation.
It doesn't make sense for `pragma foreign_proc'.

> > > 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.)
> > 
> > This is a good idea.  It is both more efficient and more natural
> > (for Java programmers) than `A'.
> > 
> > Unfortunately it is hard to make this work nicely given the current design
> > of the MLDS back-end, where we map HLDS->MLDS->Java, rather than going
> > directly from HLDS->Java.  The trouble is that the information about
> > determinism is lost when converting HLDS->MLDS, but the conversion from
> > multiple outputs to an array happens when converting from MLDS->Java.
> 
> I do not understand this fully. Do you speak about generating a) the
> method definition or b) the method call in Java ? 

Both.  For both of these, the signature is recorded as an mlds__func_signature.

> If you meant a), so I cannot understand, why the MLDS->Java conversion
> must know about the determinism. It should simply wrap the code
> provided by the user. The user calls `return null;' whenever she wants
> to indicate failure. 

I disagree.  That approach would prevent the Mercury compiler from
inlining the user's Java code.

Instead, the user should set `SUCCESS_INDICATOR = false;' to indicate
failure.

> Hence we should add the line number of the mercury could as comments:
...
>  			/* start foreign proc at users_mercury.m:10452 */

That would be a good idea, yes.

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