deduplicating lambda methods

Brian Goetz brian.goetz at
Thu Mar 15 19:00:28 UTC 2018

This seems pleasantly straightforward.

I think we wanted to exclude serializable lambdas from being 
deduplicated?  Hopefully that's one more test here:

  369         if (existing != null) {
  370             sym = existing.symbol;

Stats on its effectiveness on a representative corpus would be useful.

Hopefully the hash code is discriminative enough that TreeDiffer doesn't 
actually run that often.

On 3/15/2018 2:52 PM, Liam Miller-Cushon wrote:
> I uploaded a webrev with the current sketch:
> <>
> * Nothing here is intended to be final, I'm interested in feedback on 
> the direction and any suggestions for next steps.
> * It shows the approach used for ast comparison, including the lambda 
> parameter handling I described. The lambda parameter handling is 
> currently baked-in, but it could easily be refactored to allow the ast 
> diffing to be used in other contexts.
> * There is no handling of debug info yet.
> On Sun, Mar 4, 2018 at 7:59 PM Liam Miller-Cushon <cushon at 
> <mailto:cushon at>> wrote:
>     On Fri, Mar 2, 2018 at 8:01 PM, Vicente Romero
>     <vicente.romero at <mailto:vicente.romero at>> wrote:
>             1) How to identifying duplicates: I have a prototype that
>             runs during lambda desugaring and identifies duplicates by
>             diffing ASTs. Is that the best place for deduplication, or
>             it worth considering comparing generated code instead of ASTs?
>         are you doing an exact diff? I assume that we want: s -> s to
>         be equal to z -> z provided that the target is the same
>     Lambda parameters are currently handled as a special case. The
>     diff tests that the syntax for the two trees is the same, and that
>     the symbols associated with identifier and select nodes are
>     equivalent. It accepts symbols that correspond to the same
>     parameter in each of the associated lambda methods.
>     E.g. when diffing the lambda bodies for `s -> s` and `x -> x` it
>     sees that `s` and `x` are both the first parameter of their
>     enclosing lambdas.

More information about the amber-dev mailing list