Unfortunately it's very easy to introduce bugs when working on this code, so I think we need to be really careful about this (searching through this repo's issue history for TCO should provide a bit more context). It's unfortunately quite possible that our tests don't cover as many cases here as they should, so the fact that the tests are passing is not enough for me to be confident. The tests in this PR only check that the program finishes; they don't check the results of the TCO-transformed functions, which I think is also needed.

For me, this would need a much more developed justification of why it works and would not break existing programs before we can consider it. In any case I think this needs to wait until 0.14.0 has been released.

In any case I think this needs to wait until 0.14.0 has been released.

I agree with this.

I couldn't find any semantics testing suite. Do we have such a thing? If so, I can write some tests to make it more clear that this approach doesn't break anything.

I’m not sure what you mean by “semantics testing suite.” More tests might help but they aren’t really a substitute for an explanation of your reasoning and approach.

(Attempting to move discussion of the proposal, as distinct from this implementation, to#3967.)

My approach is just to alter the conditions for the TCO to trigger while leaving the present loopifier unchanged. Indeed, the only thing I changed was replacing "allInTailPosition" with "anyInTailPosition". The algorithm for resolving the tail calls remains as it was before – so if it was working back then, then should it work now as well. The only issue I can think of is that it may be a bit too much of artificial loops, but this discussion is continued in#3967

By "semantics teseting suite" I meant some already defined way of validating if the generated code evaluates in a desired way. I suspect I could do it by throwing errors on failing assertions in thepassing set, but I didn't see this approach around the code, so I haven't decided to go for it.

I suspect I could do it by throwing errors on failing assertions in thepassing set, but I didn't see this approach around the code, so I haven't decided to go for it.

They're in the minority, but a number of tests do use the functions frompurescript-assert; you can grep forTest.Assert to see which ones.