3 ms·

I had a few discussions with some guys at #lisp, they looked over some code I'd written that was recursion-heavy, and they were of the mind that since Tail-Call

I had a few discussions with some guys at #lisp, they looked over some code I'd written that was recursion-heavy, and they were of the mind that since Tail-Call Optimization is not in the ANSI standard and therefore implementation dependent one should be careful when using them. Now that totally changes if you're writing Scheme...

dschiptsov 13y ago
All non-toy CL implementations do TCO nowadays. http://0branch.com/notes/tco-cl.html http://0branch.com/notes/tco-cl.html Anyway, it is worthwhile to practice writing recursive solutions (beginning with Scheme) to understand possible pitfalls in case of non-tail recursion, and then, proudly, switch to fixed-space looping techniques.)
- momo-reina 13y ago
  Yeah I've blown the stack more times than I can recall when using non-tail recursion. I do enjoy recursion, it seems like a clean and elegant solution, though I'm ridiculously preoccupied with writing non idiomatic code. Pascal Costanza has an interesting opinion[1] on why TCO wasn't included in the ANSI standard. [1]http://www.p-cos.net/lisp/guide.html http://www.p-cos.net/lisp/guide.html
- lispm 13y ago
  There are a few problems with TCO in Common Lisp: * some platforms don't provide useful support (in the History it were some stack-oriented Lisp Machines, nowadays it is the JVM - see ABCL) * there is no consensus how it should be invoked, how its effect should be reported by a compiler, how the user should be noted about limitations (example: LispWorks limits the number of variables), ... * it is not a good fit with Common Lisp, since the language supports all kinds of dynamic constructs: dynamic binding, unwind-protect, ... It is not clear how this should interoperate with TCO in CL. * it makes debugging more diffcult (backtraces, trace, ...)
  - momo-reina 13y ago
    These were the exact points raised at #lisp. They also tried to explain the CL idiom to a recursive problem which I don't really recall except the fact that I didn't understand it...

dschiptsov 13y ago

All non-toy CL implementations do TCO nowadays. http://0branch.com/notes/tco-cl.html http://0branch.com/notes/tco-cl.html Anyway, it is worthwhile to practice writing recursive solutions (beginning with Scheme) to understand possible pitfalls in case of non-tail recursion, and then, proudly, switch to fixed-space looping techniques.)

momo-reina 13y ago
Yeah I've blown the stack more times than I can recall when using non-tail recursion. I do enjoy recursion, it seems like a clean and elegant solution, though I'm ridiculously preoccupied with writing non idiomatic code. Pascal Costanza has an interesting opinion[1] on why TCO wasn't included in the ANSI standard. [1]http://www.p-cos.net/lisp/guide.html http://www.p-cos.net/lisp/guide.html
lispm 13y ago
There are a few problems with TCO in Common Lisp: * some platforms don't provide useful support (in the History it were some stack-oriented Lisp Machines, nowadays it is the JVM - see ABCL) * there is no consensus how it should be invoked, how its effect should be reported by a compiler, how the user should be noted about limitations (example: LispWorks limits the number of variables), ... * it is not a good fit with Common Lisp, since the language supports all kinds of dynamic constructs: dynamic binding, unwind-protect, ... It is not clear how this should interoperate with TCO in CL. * it makes debugging more diffcult (backtraces, trace, ...)
- momo-reina 13y ago
  These were the exact points raised at #lisp. They also tried to explain the CL idiom to a recursive problem which I don't really recall except the fact that I didn't understand it...