The optimizer will simplify this to the equivalent of
go a = f a && go (a + 1)
Which TCO doesn't understand. We should either not simplify this case or teach TCO to understand this. If we choose to not simplify this case, we should move this simplification rule to the JS backend after TCO. It's difficult to simplify this conditionally on the recursive call, because bottom-up we don't have the context to know that go is recursive unless we thread the environment though to build, which is not ideal.
@MonoidMusician @f-f Do you know if erl and scheme will eliminate the boolean and as a tail call? If not, then I'll probably move this rule to JS.
Given a TCO function like:
The optimizer will simplify this to the equivalent of
Which TCO doesn't understand. We should either not simplify this case or teach TCO to understand this. If we choose to not simplify this case, we should move this simplification rule to the JS backend after TCO. It's difficult to simplify this conditionally on the recursive call, because bottom-up we don't have the context to know that
gois recursive unless we thread the environment though tobuild, which is not ideal.@MonoidMusician @f-f Do you know if erl and scheme will eliminate the boolean and as a tail call? If not, then I'll probably move this rule to JS.