deduplicating lambda methods

Brian Goetz brian.goetz at
Sat Mar 17 19:00:36 UTC 2018

>> I don't think we want to be duplicating the constant folding logic in 
>> multiple places, but I also don't think we have to -- doesn't L2M run 
>> after constant folding already?  I ask because I've already seen 
>> constant propagation turn capturing lambdas into noncapturing.
> I don't think we need to duplicate the constant folding logic for 
> this, I just think that the hasher and the differ should be blind 
> regarding the substructure of a tree as soon as a constant is found, 
> be it in a variable or as the constant value of a tree. Liam has a 
> good point, if our new constant folding phase were rewriting the trees 
> then the differ and the hasher he is proposing would have this for 
> free. I guess that this is a use case that can make us consider doing 
> tree rewriting as part of the new constant folding phase, but we are 
> not doing it right now, only for some trees: basically ldc() indy() 
> and condys. That's why I was saying that considering constants in the 
> tree differ / hasher could wait and that it don't have to be part of 
> this patch.

When you say blind, obviously it has to take the constants into account, 
since x -> x+2 and x->x+3 are different lambdas.  I think for now, not 
trying to do anything special here is the right move; this could 
conceivably fail to deduplicate x -> x + 2  and x -> x + TWO  when TWO 
is a static final, but that's an acceptable loss, since deduplication is 
merely optimistic.

More information about the amber-dev mailing list