| ▲ | Tail-call optimization in C is relatively recent(lwn.net) |
| 55 points by prakashqwerty 3 hours ago | 25 comments |
| |
|
| ▲ | nyeah 2 hours ago | parent | next [-] |
| >That quote is the article, and it's a little surprising that it's buried so far into the content Is it really surprising in 2026? Today's online writing style is not primarily designed to communicate. It's designed to keep the reader 'engaged' for as long as possible. The reader's time is a resource to be extracted. I'm absolutely not poking this author individually. It's the writing style of the net. |
|
| ▲ | hnfvovpje4 3 minutes ago | parent | prev | next [-] |
| Clear, useful, done |
|
| ▲ | kenjin4096 2 hours ago | parent | prev | next [-] |
| I think Anton is replying to me in that LWN article IIRC. I personally didn't know C only had tail calls that late and learnt something new there! On the other hand, I am pretty new to the compiler space myself, and I count early 2000s as a pretty long time ago, though again it is not that far back considering how long other language implementations had tail calls like in ML or variants since 1980-90s. |
| |
|
| ▲ | swiftcoder 33 minutes ago | parent | prev | next [-] |
| > In 2001 Mark Probst implemented tail-call optimization in GCC MSVC didn't add tail-call optimisation until sometime in the 2010s, IIRC. I distinctly remember sending a tail-recursive C++ program to someone who developed on Windows, and it crashing, in the late mid-to-late 2000s. |
| |
| ▲ | throw-qqqqq 13 minutes ago | parent [-] | | MSVC stands for MicroSoft Visual C++ compiler AFAIK. It famously doesn’t support a few features of C99. They don’t really seem to care much about regular C support (non-C++). | | |
| ▲ | pjmlp 3 minutes ago | parent [-] | | They officially saw no need for C support going forward. https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... Note, "If you really need either of the following.....then we recommend that you consider using a different compiler such as Intel or gcc (short-term) and/or pressure your standards committee representatives to have ISO C++ include more of the C standard (longer-term)." Which is kind of why nowadays clang is part of Visual Studio as well. However, after Satya got into the whole Microsoft <3 FOSS, this changed a bit, https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-... There are a few blogs after that, so at least up to C17 minus the optional parts from C11, the support is there. It remains to be seen if anything C23 or later will ever come into MSVC, and then again, clang is part of VS installer. |
|
|
|
| ▲ | mmsc 2 hours ago | parent | prev | next [-] |
| and TCO was added then removed from js! https://stackoverflow.com/a/54721813 This leads to fun stack-overflow bugs too in a lot of js code (one solution is to flatten: https://joshua.hu/javascript-infinite-tail-call-recursion-st...) |
| |
| ▲ | groundzeros2015 an hour ago | parent | next [-] | | Js really should have it. I think the shift in style from functional and manual prototype chains to Java classes is quite disappointing. | |
| ▲ | pfdietz 2 hours ago | parent | prev [-] | | Lack of TCO is also a common footgun for Scheme programmers using Common Lisp. | | |
| ▲ | tialaramex an hour ago | parent | next [-] | | This footgun is the reason I'm so enthusiastic about the Rust `become` keyword. This proposal would give Rust a specific keyword which says that you intend TCO and so two things happen: 1. The compiler goes to more length to deliver TCO even where it wouldn't "just work" and 2. If it cannot deliver TCO your code doesn't compile, because you asked for TCO. | | |
| ▲ | chriswarbo an hour ago | parent | next [-] | | Sounds similar to @tailrec in Scala I personally use the phrase "tail call elimination" when it's a requirement that can be relied on; and "tail call optimisation" when it might be implementation-dependent, context-dependent, limited (e.g. to immediate self-calls), etc. | |
| ▲ | StilesCrisis an hour ago | parent | prev [-] | | Sounds like clang::must_tail? | | |
| ▲ | tialaramex 31 minutes ago | parent [-] | | I am not a Clang expert, but first, obviously that's a C++ attribute and so while Clang can decide what it means in Clang in the programming language itself it has no semantic weight because the ISO document says attributes are always ignorable. Secondly however in these languages you often won't naively get TCO because you have at least one local variable which C++ would say has a "non-trivial destructor" or Rust would say "implements Drop". These both mean that naively the "tail call" wasn't actually the last thing to happen, the destructor / Drop::drop happen at the end of the function, after the tail call. The proposed become keyword tries to core::mem::drop any such variables, if it succeeds now that tail call is last and we can do TCO, if it fails [e.g. because the variables it wants to drop are needed for the tail call] we can diagnose the problem. I believe the Clang attribute doesn't have this behaviour. |
|
| |
| ▲ | pjmlp 42 minutes ago | parent | prev | next [-] | | Mostly because they forget Scheme is one of the few languages where TCO is part of the language standard, making it a required feature for any compliant implementation. This has always been an issue regarding TCO support across programming languages. | | |
| ▲ | pfdietz 19 minutes ago | parent [-] | | Well, and also because of the "I've been told in Scheme you should do it this way, so by gum I'm going to do it this way!" |
| |
| ▲ | guenthert an hour ago | parent | prev [-] | | Only if they are using an insufficiently smart compiler. SBCL handles TCO just fine, as do a number of other implementations, see : https://0branch.com/notes/tco-cl.html | | |
| ▲ | pfdietz an hour ago | parent [-] | | Even SBCL doesn't do TCO at all times. Compiling at (debug 3) means no TCO. Another related footgun is deep recursion of other kinds, for example when recursively traversing down lists. For long lists it's easy to exceed the stack size limit. The common idiom is to recur on list elements, but iterate or map to go along a list. | | |
| ▲ | guenthert an hour ago | parent [-] | | > Even SBCL doesn't do TCO at all times. Compiling at (debug 3) means no TCO. Presumably one intends to debug the code, when setting (debug 3). Then it'll be helpful to see the stack, no? > Another related footgun is deep recursion of other kinds, for example when recursively traversing down lists. For long lists it's easy to exceed the stack size limit. The common idiom is to recur on list elements, but iterate or map to go along a list. Not going to argue with seasoned lispers here, but IMHO recursive code makes most sense when accessing recursive data structures. | | |
| ▲ | pfdietz 23 minutes ago | parent [-] | | One place where this shows up is in parse trees. The grammar for a list of things may involve productions that look like list constructors. This, directly translated into a data structure, would give a very long chain of parse tree nodes dangling off to the right. It's a recursive data structure, but a very deep one for large lists, and traversing it recursively can use a lot of stack. This can also be seen as an argument against building parse trees that way. Instead, have a node with an unbounded number of children, the elements of the list. |
|
|
|
|
|
|
| ▲ | messe 2 hours ago | parent | prev [-] |
| > In 2001 Mark Probst implemented tail-call optimization in GCC with a separate calling convention; he lists the limitations of the then-existing tail-call optimization in GCC in section 6.4, among them: "It cannot handle indirect calls" (which would have been used in tail calls for interpreter dispatch). Relatively recent being a quarter of century? Or at least a fifth of a century for indirect calls[1] (GCC 3.4.6 is the earliest I see on Compiler Explorer, released March 2006). [1]: https://godbolt.org/z/vvcnn54oM |
| |
| ▲ | coliveira 5 minutes ago | parent | next [-] | | For people who passed their 30s, everything that happened after their 20th birthday is recent. For me, September 11 is recent memory, as well as the 2008 great recession. | |
| ▲ | derdi 8 minutes ago | parent | prev [-] | | Given that GCC was first released in 1987, that would mean that tail call optimization, including of indirect calls, has been around for more than half of GCC's lifetime. So it's indeed fair for the parent article to say that "[GCC has] had tail-call optimizations for most of [its] existence". |
|
