3 ms·
You're explaining TCO. I understand how TCO works. I'm going to rephrase my own argument because it doesn't appear you interacted with it: what part of your ar
by lvh 7y ago
You're explaining TCO. I understand how TCO works.
I'm going to rephrase my own argument because it doesn't appear you interacted with it: what part of your argument doesn't work for x86_64? "One would need to compile the code in complex ways: function calls would no longer map directly to CALL/RET instructions." Sure! That's arguably what makes it an optimization. Who cares? CPUs can loop, and so can the JVM.
I would maybe see your point if Clojure didn't already know how to do tail calls (and so would need to implement the allegedly complicated compilation step), but as I have pointed out several times: it already has `recur`, which lets you call a function without the JVM thinking there is a function call going on.
- deleted 7y ago[deleted]
- lispm 7y agoTail recursion optimization would be when the compiler on its own would recognize tail recursion calls and generate special code for that. That one needs to manually annotate it in Clojure just means that the compiler is manually instructed to generate a loop-like construct instead of a function call. The advantage in Clojure is that these loops are explicitly marked, which IMHO improves readablity. Many Lisps don't bother to implement tail recursion optimization, because they support the more general tail call optimization - by adjusting/reusing the current stack frame and using a JMP instruction.