| |
| ▲ | tialaramex 2 hours 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 2 hours ago | parent | prev [-] | | Sounds like clang::must_tail? | | |
| ▲ | tialaramex an hour 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 an hour 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 36 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 2 hours 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 40 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. |
|
|
|
|
