deduplicating lambda methods

Vicente Romero vicente.romero at
Sat Mar 17 18:57:26 UTC 2018

On 03/17/2018 02:49 PM, Brian Goetz wrote:
>>>     Also, as a bonus, consider constant expressions, we probably want:
>>>     return 5; and return 2 + 3; to be equal.
>>>     I think that these two use cases will need a "normalization" step
>>>     to be
>>>     applied to the tree and store in the map, set, only a normalized
>>>     version
>>>     of the tree. I understand that at least considering constants 
>>> could be
>>>     out of the scope of this patch, so I can see it as a follow up
>>>     development.
> 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.

More information about the amber-dev mailing list