[antlr-interest] Appropriate use of honey badger listeners

[Kyle Ferrio]

Hi Gavin,

I may be missing something (I often do) but as best I can tell, we're
concerned with identity v. non-identity only, and not history, of trees.
So I don't understand how a version number is safer than a flag.  Sure, a
flag can be erroneously flipped back, but as version number can be
erroneously set to anything.  I'm not sure either is more likely than the
other.  But I completely agree that a version number works at least as well
as a flag.  Both reduce the comparison from O(n) to O(1).  And if a version
number is safer, great!

Meanwhile, I'm really having a hard time coming up with any elegant answer
to the challenge in Part 1 of Ter's original post.  I'm not yet resigned to
a "conservation of ugliness" principle (in the grammar v. in the listener)
but I admit I don't have anything better at the moment.  You guys who live
in the belly of antlr will know better than me.

Kyle

On Wed, Jan 11, 2012 at 10:30 PM, Gavin Lambert <antlr at mirality.co.nz>wrote:

> At 17:39 12/01/2012, Kyle Ferrio wrote:
> >If all we care about is detecting changes, a significant
> >speedup is possible if the interface for a tree object (or
> >for listeners acting on trees?) includes a flag that gets
> >flipped by any operation which has the possibility of
> >changing the tree.  (N.B. Possibility, not guarantee.  A
> >guarantee would require the eval we're trying to avoid.)
>
> The usual solution for that is a version number, initialised to zero and
> incremented on any operation that alters the tree.  Much safer than a flag.
> :)
>
> --
> Gavin Lambert, Mirality Systems
> <http://www.mirality.co.nz/>
> <http://lambert.geek.nz/>
> ----
> Anyone who goes to a psychiatrist ought to have their head examined.
>
> Few women admit their age.  Few men act theirs.
>
>