Re:Hyperpolyglot Lisp: Common Lisp, Racket, Clojure, Emacs Lisp
by aidenn0 on Tuesday May 19, 2026 @12:16AM
(#48189116)
I think it is fair to say that the CL community is divided on whether or not relying on TCO is idiomatic.
I prefer to write my state-machines as transitioning with tail-calls, and I do get called for it. It's relatively easy to switch something written in that manner to using a loop with a trampoline, so I do so when my collaborators request it.
Re:Hyperpolyglot Lisp: Common Lisp, Racket, Clojure, Emacs Lisp
by ludston on Tuesday May 19, 2026 @12:35AM
(#48189209)
I wouldn't argue about things that are a matter of taste normally, except that I've had the experience where I've turned down optimizer settings in order to debug some code better and then the had stack overflow.
Re:Hyperpolyglot Lisp: Common Lisp, Racket, Clojure, Emacs Lisp
by ludston on Monday May 18, 2026 @11:27PM
(#48188848)
Sigh and yet it continues to be true. You can make a pragmatic decision and rely on tail call optimisation for your specific case, but if you are writing a CL library, then it is not idiomatic to use recursion in the same way that you would for Clojure or Scheme.
Even with SBCL, for example, it doesn't have tail-call optimisation for all architectures at all optimisation levels.
All major Common Lisps support tail call optimization with proper declarations, with the exception of ABCL because it runs on the JVM.
And those declarations are all identical or almost identical, so it's easy to write an implementation-specific macro to guarantee TCO if you need to do so.
Some algorithms are easiest to express and read with looping constructs. For those algorithms, use looping constructs. Other algorithms are easiest to express and read with recursion. For those, use recursion. You shouldn't be afraid of recursion just because ANSI doesn't say TCO is guaranteed. You should be afraid of it if your code needs to run on ABCL, but otherwise, recur on.