> [After doing some inlining] we have the ability to loopify the function, but we keep from doing so unless the user specifies the [@@loop] attribute on the function definition.
I don't understand why anyone wouldn't want to convert the recursion to a loop? Surely it's always an improvement.
If you search for @@loop in TFA the last occurrence is in this paragraph:
>if a function is not purely tail-recursive, but contains some tail-recursive calls then the transformation will rewrite those calls but not the other ones. This may result in better code but it's hard to be sure in advance. In such cases (and cases where functions become purely tail-recursive only after inlining), users can force the transformation by using the [@@loop] attribute
Unfortunately this doesn't answer the OP's question. OK, it may not result in better code. But in which cases, and for what reason? EDIT: And for that matter, does "not better" mean "neutral" or "actually worse"? To be clear, this is a flaw in the article, not a criticism of your response to the OP.
Conceptually, a tail recursive function represents the body of a loop and we wouldn’t expect a stack trace from a loop either, so this is less of an issue. Am I seeing this incorrectly?
This is correct, however JS/Python pundits expect a stack metaphor when debugging even with an iterative process which can execute in constant space. This leaves us with trampolines as Guido prescribes [1].
> [After doing some inlining] we have the ability to loopify the function, but we keep from doing so unless the user specifies the [@@loop] attribute on the function definition.
I don't understand why anyone wouldn't want to convert the recursion to a loop? Surely it's always an improvement.
If you search for @@loop in TFA the last occurrence is in this paragraph:
>if a function is not purely tail-recursive, but contains some tail-recursive calls then the transformation will rewrite those calls but not the other ones. This may result in better code but it's hard to be sure in advance. In such cases (and cases where functions become purely tail-recursive only after inlining), users can force the transformation by using the [@@loop] attribute
Unfortunately this doesn't answer the OP's question. OK, it may not result in better code. But in which cases, and for what reason? EDIT: And for that matter, does "not better" mean "neutral" or "actually worse"? To be clear, this is a flaw in the article, not a criticism of your response to the OP.
One argument I heard some time ago for V8 not implementing TCO is that it results in bad stack traces for debugging.
Conceptually, a tail recursive function represents the body of a loop and we wouldn’t expect a stack trace from a loop either, so this is less of an issue. Am I seeing this incorrectly?
This is correct, however JS/Python pundits expect a stack metaphor when debugging even with an iterative process which can execute in constant space. This leaves us with trampolines as Guido prescribes [1].
[1]: https://neopythonic.blogspot.com/2009/04/final-words-on-tail...
[dead]