Christophe Rhodes <csr21@...> writes:
> So to get your tail call optimization back, you need to tell SBCL that
> you are more interested in SPACE than in DEBUGability, or that you are
> more interested in SPEED than in DEBUGability. You can do that with, for
> (declaim (optimize (space 2) (debug 1)))
> to get this behaviour at file level, or
> (declare (optimize (space 2) (debug 1)))
> at block level.
> Note also that cmucl also doesn't elide tail calls for debug values
> greater than 2; it just so happens that cmucl's default debug
> optimization policy is not greater than 2.
FWIW, when we added the option of disabling TCE (people where
screaming and jumping up and down that that was very important for
debugability, and CMUCL until 18d didn't have a way of turning TCE
off!), people actually wanted the default to be disabled TCE
(something that I have great sympathy for, and think is the right
thing, for SBCL). Since I'm such a dull stickler for stability, and
not changing documented (see CMUCL user-manual on TCE) behaviour, I
was adamant that the default behaviour should not change. I prevailed
(so Marco can thank me now ;), which is why TCE is only disabled for
debug > 2 (debug = 2 is the default in CMUCL).
[ The test is debug > 2 and not debug = 3, because other people
screamed that they wanted disabled TCE, but not the heavy-duty
stuff that debug = 3 entails ]
So why am I posting this?
a) It didn't just so happen, but took quite a bit of effort ;)
b) It illustrates quite nicely that depending on TCE being done is
quite dangerous, even when only porting between releases of a
fairly conservative implementation, that actually documented when
it does TCE.
c) It also illustrates why I personally think that having both SBCL
and CMUCL alive and kicking is the best thing since sliced bread,
even if it entails a bit more work overall. The existence of SBCL
makes it easier for CMUCL maintainers to be conservative, without
thwarting the development of the CMU/SBCL code base, and the
existence of CMUCL allows SBCL maintainers to be more progressive,
without alienating all those conservative users.
At least that's the theory, which practice tends to screw up on
Pierre R. Mai <pmai@...> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein