> On May 19, 2021, at 6:43 AM, fo...@univ-mlv.fr wrote:
> 
> . ..\ .
> This remember me something, tail call optimization is not the only 
> optimization that avoid the stack to grow.
> 
> If you have calls like
>  g(a, () -> h(a, () -> f(a)))
> 
> with 'a' being the same arguments, you can transform them to
>  r1 = f(a)
>  r2 = h(a, () -> r1)
>  r3 = g(a, () -> r2)
> 
> Here the calls can be at any location in the method, but the argument should 
> not depend on the values computed by the function.
> 
> The interceptors of Spring or CDI exhibit calls like this, they are using the 
> same arguments so the result do not depend on the order of which the 
> functions/interceptors are executed,
> but as far as i know, there is not implementation that do that transformation 
> so when an exception occurs we see long stack traces.
> 
> Asking for a friend, is this transformation have already a name ?

Interesting!  No, I don’t recognize this transformation, and don’t have a name 
for it.  It reminds me a little bit of “code hoisting”, that is, moving code 
earlier (typically so as to lift, or “hoist”, it out of a loop), because a 
prerequisite for this transformation is that side effects in f, g, and h may be 
reordered.  In effect, f(a) is being computed earlier than normal, and 
similarly for h.  In fact, if g and h invoke their second arguments only 
conditionally, then f(a) may be called even in situations where it might not 
have been called in the original code.

—Guy

Reply via email to