Yeah, but yours is nicer. The only contribution mine might make over yours is an implicit so that non-tail calls can be expressed directly.
implicit def done[X](x: => X) = Done(x)
def foo : TailRec[Int]{
if (condition)
tailCall(bar)
else
42
}
Whether that's useful or causes confusion I don't know.
Also, my base case used call-by-name in its construction. I did that to ensure side effects always occur in the expected order, but the more I think about it the more I think that strict evaluation achieves that too.
On Wed, Nov 26, 2008 at 10:34 AM, martin odersky
<martin.odersky@...> wrote:
On Wed, Nov 26, 2008 at 7:01 PM, James Iry <
jamesiry@...> wrote:
> The phrase "tail call optimization" often confuses because it sounds like
> proponents primarily want things to be "faster" - after all speed is the
> most common target of optimizations. But while faster is certainly nicer,
> what we really want from TCO is for things to not explode in the face of
> large or even infinite sequences of tail calls. It's a space optimization
> rather than a time optimization. In the right circumstances is optimizes
> O(n) memory stack usage to O(1). That's often far more important than a
> mere constant factor loss in time performance.
>
> Hickey made an interesting choice. He makes the user do the work to
> indicate when trampolining should be used. That means the user gets to make
> the choice about the trade-offs involved.
>
> A variation in Scala
>
solution and mine are pretty much equivalent.
Cheers
-- Martin
