[m-rev.] diff: fix tail call outputing bug

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Feb 12 02:05:38 AEDT 2002


On 11-Feb-2002, Peter Ross <peter.ross at miscrit.be> wrote:
> Fergus wrote:
> 
> > On 08-Feb-2002, Peter Ross <peter.ross at miscrit.be> wrote:
> > > compiler/mlds_to_il.m:
> > >     The callee return type must be compatible with the caller return
> > >     type for a tail call on the IL backend, not just for verifiable
> code
> > >     but for any code.
> >
> > Not according to the ECMA spec, last time I looked.
>
> Yes, you are correct, I checked the spec but misunderstood it.
> 
> However isn't it a bug in the spec that this condition is specified in
> the verifiability section rather than as a correctness condition.

Whether or not the spec correctly reflects the designers' original
intentions in this respect is an open question.

But the spec is clear, once you read it carefully,
and the behaviour specified is not unreasonable.

> I can't see how code could possibly be correct if the tail call is allowed
> to return a different type to the one returned by the caller.  The
> caller can't return the value so the callee is responsible for doing so
> the types must have to be compatible, anything else would be a bug.

Nope.  *If* the code is executed, and *if* the callee returns, then the
behaviour is (implicitly) undefined, definitely.  But the callee might
never return, for example.  In that case, the behaviour is well-defined.

For verifiable IL, the system should err on the side of caution
by rejecting constructs that can't be proven to be safe.
But for correct IL, I think the system should err on the side
of inclusion, by allowing constructs that can't be proven to be
unsafe, unless there is some other reason (e.g. efficiency, ease of
implementation, etc.) for disallowing them.

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



More information about the reviews mailing list