upvote

points

by mort9618 hours ago |
comments
upvoteby leni53615 hours ago|
next
[-]
Precisely. ISO C and C++ have a notion of various implementation limits, one of which is nested function calls due to exhausting the stack. TCO could be about a carveout on this limit.

Having said that the standards give way too much leeway for the limits, so a conforming implementation might have arbitrary limits for loops as well (at least in C++, I'm not that familiar with the C standard's wording).

reply
upvoteby cmovq17 hours ago|
prev|
next
[-]
Note that compilers are more than happy to delete 'while (true)' if the loop doesn't have side-effects.
reply
upvoteby mpyne13 hours ago|
parent|
next
[-]
I think this is no longer true. C++26 implemented a change to make trivial loops like these defined behavior (and therefore will loop endlessly as you'd expect). And this example was always defined behavior in C.

Both languages continue to have examples of slightly more complicated loops that can be assumed to terminate in the absence of side effects, but `while(true)` isn't one of those any longer.

reply
upvoteby mort9617 hours ago|
parent|
prev|
[-]
Of course. I wasn't talking about empty loops.

But also, I wouldn't rely on a compiler to remove empty 'while (true)' loops.

reply
upvoteby layer816 hours ago|
prev|
[-]
It’s precisely not the semantics of the program that will crash the program, but the behavior of the language implementation. It’s similar to when a program in a GC language fails with OOM because the language implementation uses a no-op collector. That’s usually not part of programming language semantics.
reply
upvoteby tuveson10 hours ago|
parent|
next
[-]
Tail call elimination often is part of the language semantics though, for the reason others in this thread have described. E.g. Scheme specifies when a conformant implementation is required to eliminate tail calls: https://conservatory.scheme.org/schemers/Documents/Standards...
reply
upvoteby drdexebtjl15 hours ago|
parent|
prev|
next
[-]
If you wrote a correct binary search algorithm and you observed that, under one language implementation, the time complexity scaled linearly with the size of the input instead of logarithmically, you would think the semantics of the program were changed.

If you used an in-place sort algorithm and observed memory requirements that scale super-linearly with the size of the input, you would think the semantics of the program were changed.

In languages with such tail call guarantees, tail recursion _is_ a loop. It semantically encodes constant space complexity.

reply
upvoteby layer810 hours ago|
parent|
[-]
Programming language semantics as in https://en.wikipedia.org/wiki/Semantics_(programming_languag... is usually decoupled from space complexity. An interpreter or emulator is considered to preserve language semantics even if it changes time or space complexity.
reply
upvoteby drdexebtjl8 hours ago|
parent|
[-]
We're talking about the same thing. I disagree. Such interpreter or emulator would preserve _some_ language semantics, but not all.
reply
upvoteby mort9616 hours ago|
parent|
prev|
[-]
The specification allows implementations to have limits on maximum call stack depth and all sorts of other things. It's absolutely semantically meaningful in C to allocate a new stack frame.
reply
upvoteby layer810 hours ago|
parent|
[-]
The details of how a stack is managed isn't normally part of programming language semantics.
reply