Bob Rogers <[EMAIL PROTECTED]> wrote: > From: Leopold Toetsch <[EMAIL PROTECTED]>
> I'd pass one argument array around. With C<foldup/.flatten_arg) you are > doing that anyway. > Well, the example I showed you was a bit contrived. I'm working on > implementing Common Lisp call/return semantics, where functions often > take variable numbers of arguments, and can return zero or more values, > and it's the caller's responsibility to sort out what it got back. In > fact, CL multiple return values are quite similar to optional arguments > by design. Furthermore, there are numerous places in the spec where it > says that "expression X returns all the values of its final subform" -- > hence my interest in tail calling. (Just like Perl5, as a matter of > fact, but without context propagation.) I see. > It had seemed otherwise, looking at imcc/pcc.c yesterday, but I must not > have been looking closely enough. Is that what the "&& !tmp->next" in > line 583 does (CVS 1.86)? Is there a rationale behind limiting it this > way? Yep - No, I don't see a rationale behind it. Just remove the test and try it ;) > But yep. Such a construct should be there. And additionally maybe > .tail_call (rets) = func(...) > Actually, if that *is* a tail call, then you can't possibly be > interested in "(rets)". Yep. I've just used the full call syntax, because there's a parser rule for it. > ... But this syntax is clearly much easier to use > for cases that don't require .flatten_arg or other .pcc_begin/.pcc_end > magic. So how about > .tail_call func(...) Ok. > for something that *must* use the tailcall op, and > .return_call func(...) > as a shorthand for other calls in tail position that return all values? > Having two separate constructions helps to avoid confusion between > required semantics and permitted optimization. I don't see much need for the latter. If the compiler wants tail calls it just emits the former. If not, the plain call syntax does it, e.g. for debugging. > ... For consistency, there > must be two .pcc_* constructs: .pcc_tail_call and .pcc_return_call, > with corresponding semantics. Just .pcc_tail_call. > The extra syntax also provides detailed control over tail-call > optimization. I'd say: .tail_call always does a tail call. The check_tail_call() can be dropped then. leo
