Comment 9 for bug 551227

Revision history for this message
Alastair Bridgewater (alastair-bridgewater) wrote :

Continuing from that keyboard fumble...

The actual logic in CONSTRAIN-REF-TYPE appears to be checking an EQLity constraint between two LEAFs (LEAVes?) that are somehow similar-but-not-too-similar, and substituting one for the other in a given REF. The problem comes when the OTHER LEAF is no longer visible. Preventing the substitution is one possible (and easy) alternative, but another could be to promote the OTHER LEAF to a sufficiently outer lambda (if there is one) so that it is still available in the context of the REF.

I'm a lot happier with these patches now than when I posted my original version, even if I still don't know what's going on during constraint propagation. Will commit "soonish".