deduplicating lambda methods

John Rose john.r.rose at
Sat Mar 3 01:57:10 UTC 2018

On Mar 2, 2018, at 5:17 PM, Brian Goetz <brian.goetz at> wrote:
> Is there any trickiness with capturing lambdas?  I don't think so -- I think we can merge these too, although I suspect the return on that effort is lower.  I'll bet the most common case is lambdas like e -> e, x -> System.out.println(x), etc.

A good extension to Liam's proposal, that should arise naturally
from his AST matching work, would be to recognize the top ten
(or so) AST patterns, like the above and also e -> k and k::m
(for constants k).  The desugared methods for these a trivial,
and as such should deduplicated *across compilation units*.
They could be defined as part of this work as new members
of the LMF class.

Another good extension to consider is to evaluate the body
of a capturing (but non-constant) lambda and detect whether
the lambda capture point can be moved out of a loop.
That's tricky because you don't want to trigger a capture
for a zero-trip loop.  But it's worthwhile because users
frequently write loop-invariant lambdas without realizing it.

(The latter problem is one of de-duplication for duplicates
created by loop iterations.  So it's not de-duplication in
the same sense.  But it does require an AST analysis
of a lambda body, in context of a containing loop.)

— John

More information about the amber-dev mailing list