Disable Tail Call Optimizations (When Developer Tools are open)

[fselcukcan]

Instead of syntactic tail call optimizations or no TCO, can we not have a Developer Tools option to toggle TCO, for a function, a block of code, or entire program. We have similar Developer Tool switches like Disable Cache (When Developer Tools are open). Disable Tail Call Optimizations (When Developer Tools are open) checkbox, and context menu option on functions, code blocks to toggle TCO when devtools are open.

That would give programmer complete control over the TCO while debugging even on the 3rd party code (for that case disabling globally by using Disable TCO checkbox, or by right clicking a script file and selecting disable TCO from devtools resources).

I think that would eliminate the concern for loosing stack info for debugging when TCO applied. We need that info only when we debug, not when we run. We debug when we debug. We do not debug when we run. So, instead of dropping a very good feature for a programming language like TCO for debugging reasons, we can toggle it when we debug.

Many features have been shipped that will not be used by masses necessarily. Some of them bring value and benefit for sure, it is not always for the majority. Even though TCO will not be used by masses it will bring value and benefit, even without knowing that optimization in there causes some of the performance bump in your function.

[ljharb]

This is up to each individual browser; since only safari ships tail calls, you’ll have to file a bug with them.

Also, PTC or STC, not TCO; it’s not an optimization.

[ljharb]

Having such behavior would actually be quite harmful - because it would mean your site behaves very differently when dev tools is open than when it’s closed.

[fselcukcan]

Agh, sorry if I have lead to confusion but I meant some sorts of optimizations, defined by a spec, for recursive functions (procedures) that is written with tail calls. And they are known to be optimizable relatively easier.

I do not much refer to the way recursive code is written here, Proper Tail Calls or Syntactical Tail Calls. It is just the way you write the code. Though, I definitely do not favor syntactical tail calls (STC), also they kind of defeats, at least the lexical, purpose of TCO. I mean the system should recognize taill calls (PTC) and optimize it confined to the spec definitions.

Again, we have this in exactly same sort of feature in Disable Cache (when developer tools open) checkbox, and we can currently uncheck it and enable/disable cache when developer tools are open depending on your debugging purpose, so no behaviour changes unless you want it to. Same can be achieved for TCO. Develoepr Tools are there to be used when debugging th code and not when running the code as in production. So there is no harm in there. Harm can be done with current set of tools as well unless one does not know what one does with them.

[TiddoLangerak]

I think that would eliminate the concern for loosing stack info for debugging when TCO applied. We need that info only when we debug, not when we run.

We definitely need stack information when running. If a user triggers an error in production, then we typically want the error with full stack trace to be send back to a monitoring system for investigation.

---

Also, disabling PTC/STC/TCO is very different from disabling cache. Websites are expected to work with a cold cache, hence disabling cache is just triggering a "normal" state which is not expected to break your website. This is not the case for TCO: TCO allows us to write functions that are otherwise impossible to write, e.g. infinite recursive functions. This means that disabling TCO will break these functions, we cannot debug them by simply disabling TCO.