interesting that a non-tail-recursive function bring annotated as tail recursive is a warning and not an error. I suppose the rationale is that it doesn’t change the “correctness” of the code.
So this is a fascinating topic of discussion that regularly happen between implementers and people working on compilers and interpreters.
Is Tail Call Optimisation an Optimisation or a fundamental behaviour of the programming model. For lot of practical reasons, implementers tend to consider it an optimisation. Which means that no, it is not considered violating correctness. The code still do as asked. Just happened that without the optimisation, it blows up.
Ofc, you also see implementers using TCO in their own implementation in ways that are definitely not optional. Erlang use of infinite receive loops for process come to mind.
But there really are practical reasons to consider it “just an optimisation”. This is the kind of theory vs engineering gaps which makes it complicated to see programming as a purely “mathematical” activity.
IMO Optimisiation is when a compiler decides to transform code to make it better in some metric (faster speed, lower memory footprint, whatever…) such that the promised semantics of the code are maintained.
A failure o satisfy promised semantics is an error.
If my recursive function gets unrolled to a loop, that’s an optimisation.
If my explicit tail call cannot be tail-called, that is an error.
interesting that a non-tail-recursive function bring annotated as tail recursive is a warning and not an error. I suppose the rationale is that it doesn’t change the “correctness” of the code.
Surely blowing the stack when you expected to be making tail calls violates “correctness”?
So this is a fascinating topic of discussion that regularly happen between implementers and people working on compilers and interpreters.
Is Tail Call Optimisation an Optimisation or a fundamental behaviour of the programming model. For lot of practical reasons, implementers tend to consider it an optimisation. Which means that no, it is not considered violating correctness. The code still do as asked. Just happened that without the optimisation, it blows up.
Ofc, you also see implementers using TCO in their own implementation in ways that are definitely not optional. Erlang use of infinite receive loops for process come to mind.
But there really are practical reasons to consider it “just an optimisation”. This is the kind of theory vs engineering gaps which makes it complicated to see programming as a purely “mathematical” activity.
Just an optimization in the same way that garbage collection is just an optimization!
IMO Optimisiation is when a compiler decides to transform code to make it better in some metric (faster speed, lower memory footprint, whatever…) such that the promised semantics of the code are maintained. A failure o satisfy promised semantics is an error.
If my recursive function gets unrolled to a loop, that’s an optimisation. If my explicit tail call cannot be tail-called, that is an error.
Thing is, both of these things can break or explode on the wrong hardware.
Wonder why the function, not the call site, is labelled? What if some calls are expected to be in tail position, others not?