3 ms·
Okay, but you're still doing the twisting with recur. The only difference is that the compiler checks that recur is actually in a tail position. That's probab
by jfager 17y ago
Okay, but you're still doing the twisting with recur. The only difference is that the compiler checks that recur is actually in a tail position. That's probably nice to a newcomer, sure, but once you do it a few times, it's pretty simple to tell whether you're making a tail call or not.
- ubernostrum 17y agoI addressed some of this in a comment on the reddit thread: http://www.reddit.com/r/programming/comments/9ye8o/tail_call_amputation/c0f0kcx http://www.reddit.com/r/programming/comments/9ye8o/tail_call...
- jfager 17y agoYou're changing the topic of conversation from 'recur' to 'tail-call elimination', but I'll bite. I don't understand your argument. How is the decision to take advantage of tail-call elimination any less a part of an algorithm's implementation than the decision to, say, use a lazy iterator rather than read into an intermediate array? If it's not the best tool for what you're trying to do, certainly, don't use it, but there are plenty of legitimate places where it is needed, so why argue against it?
- Confusion 17y agoIt's pretty simple to tell when you are looking at it. However, you may forget/overlook that you are influencing a tail call. If it was optional, I would still opt to use it all the time.