On Jan 20, 2008, at 02:17 , Nikodemus Siivola wrote:
> On 1/20/08, Marco Antoniotti <marcoxa@...> wrote:
>> On Jan 19, 2008, at 21:32 , Nikodemus Siivola wrote:
>>> On 1/19/08, Marco Antoniotti <marcoxa@...> wrote:
>>>> BTW. I know that SBCL and CMUCL are already doing TCO with
>>>> (declaim (optimize (debug 2)))
>>> I won't comment on CMUCL, but for SBCL this is not quite so. TCO
>>> (tail call merging in SBCL parlance) happens when _either_ SPACE
>>> or SPEED is greater then DEBUG. Declaiming DEBUG 2 is more likely
>>> to inhibit then enable TCO...
>> That's not what the manual says or at least how I understand it.
>> It seems to me that it is pretty much what you find in the CMUCL
>> manual. I don't know if the internals of SBCL have changed w.r.t.
> What the manual says is this (referring to DEBUG):
> "> 2
> Any level greater than 2 gives level 2 and in addition disables
> tail-call optimization, so that the backtrace will contain frames for
> all invoked functions, even those in tail positions."
> Which is (I hesitate to say wrong) a tad misleading. It never ment to
> say that TCO _always_ happens if DEBUG is 2 or less. I ment to say
> that TCO _never_ happens if DEBUG is more then 2...
> At any rate, (or (> speed debug) (> space debug)) is the current
> default policy, and the oft-mentioned sb-c::merge-tail-calls is a way
> to explicitly request TCO regardless of other policies.
Yes. That is what I understood. SB-C::MERGE-TAIL-CALLS is the thing
that was escaping me yesterday.
Apart from that, the CMUCL manual has a section (5.5.1) that
explicitly talks about the exceptions (which are very similar to LW
exceptions), but I do not find it in the SBCL manual.
In any case, I still think that going the optimization quality way
instead of the macro way is best.