> From: William Harold Newman <william.newman@...>
> Content-Disposition: inline
> Sender: sbcl-devel-admin@...
> X-Original-Date: Mon, 13 May 2002 17:33:39 -0500
> Date: Mon, 13 May 2002 17:33:39 -0500
> X-Filter-Version: 1.8 (cat)
> On Mon, May 13, 2002 at 04:36:12AM -0500, Jonathan Hseu wrote:
> > SBCL doesn't seem to optimize tail-recursion. It seems like such an
> > important optimization for lisps... is there a good reason why?
> If I were on the ANSI CL committee 15 years ago, I'd be agitating for
> tail recursion support. But instead, it's not part of the standard,
> and so writing code which depends on it is arguably a bad idea.
> I'm one of the people who would argue that it is in fact a bad idea.
> I've been through numerous changes of computer and o/s in my checkered
> career. It's ever so nice to have code that just keeps on working no
> matter where it goes; and definitely nice enough that I prefer just to
> bite the bullet and write the code iteratively if the tail recursive
> code would go more than a few thousand levels deep.
> > CMUCL, in contrast, handles tail-recursion well.
> > If there's not a good reason why SBCL shouldn't include it, perhaps I
> > can begin helping the project by adding it :)
Well, you get lazy and happily confident that your quality CL
I have code written in a full tail recursive manner (it is Schemeish!
:) ). It is a beauty to look at and easy to maintain.
It works flawlessly under CMUCL for very large data sets (very "deep"
I ported it to LW (and I did some preliminary tests on ACL), where it
bombs (stack overflows) extremely easily.
So now I have to rewrite a lot of code (that has worked for years under CMUCL)
with an explicit heap allocated stack handling component. This is
> To the extent that tail recursion can be supported with no compromises
> of anything else, it's still good. But since in practice it tends to
> complicate other things (especially debugging), and since code which
> depends on it is unportable, I'm not very enthusiastic about it.
> To the extent that you want to work on tail recursion specifically,
> you might do better to write a portable package which provides it on
> top of stock common Lisp. (See Screamer for a package which ports
> another Schemely feature into CL, providing portable continuation-like
From what you say here, it seems to me that you have departed quite a
way from the CMUCL code base. I am not privy to the guts of SBCL, but
I did not think that you had to go so far. It is you choice to dump
full tail recursion. But in this case I think you are throwing the
baby with the bathwater.
> To the extent that you want to work on unportable extensions, I'd
> suggest something that increases the expressiveness of the language
> more than tail recursion does, e.g. weak pointers or multithreading.
> (Both of these seem as though they'd be unreasonably difficult to
> implement as a portable layer atop ANSI CL.)
Why is CMUCL full tail recursion not portable? AFAIK, there is
nothing in the standard that prevents it.
Your suggestion that it should be implemented as a "portable layer"
implies that it is something that should not be transparent to the
user. IMO this is not the case.
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.