Alex Shinn writes:
> On Sun, Jan 6, 2013 at 8:45 PM, Jussi Piitulainen wrote:
> >
> > I don't care about the result. I care about the tail recursion.
> > However, adding the "otherwise" seems good to me. I think of "unless"
> > and "when" as short-hand for (if ... (begin ...)) anyway, and would
> > like to continue thinking so.
>
> And I think it's distracting and misleading to think of when/unless
> returning a result.

Losing the tail-position for the last expression is a high price to
pay. Saying that (1) the last expression is in a tail position wrt the
whole, (2) yet the values passed to the continuation may not be the
values of that expression, is mildly confusing to me, but I can live
with that.

> You're confusing the implementation with the specification.  It's
> fine to implement these forms as you suggest.  But there's no reason
> to require the result, and in fact every reason not to.

You are suggesting that it would also be fine to define them as
(call-with-values (lambda () (if ... (begin ...))) (lambda _ /)),
right?

If the specification does not say that the last expression is in a
tail position wrt the whole, relying on it is not portable.

To get the guaranteed space behaviour, I could easily implement these
forms myself, even on the fly, but if I need to do that, it would be
better to not have them in the report at all.

> The tail call is an orthogonal issue, let's please forget it.

Surely it's not an orthogonal issue. The values of an expression in a
tail position are passed to the continuation. But as I said, I'm fine
as long as I can have the bounded-space behaviour.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports