[External] : Re: Rehabilitating switch -- a scorecard

[Guy Steele]

> On May 19, 2021, at 6:43 AM, forax at 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