[antlr-interest] translation of $x references in v3.0
Loring Craymer
Loring.G.Craymer at jpl.nasa.gov
Tue May 3 01:49:09 PDT 2005
John--
Your modesty is overwhelming. Don't you think that you should have quoted
your own statement
At 01:36 PM 5/2/2005, John D. Mitchell wrote:
>One reason is that this makes it harder to accidentally use those
>dangerous dynamic attributes by accident. Which, I believe was part of
>your argument for not building them into Antlr v3 in the first place.
Geez.
to which I was replying? Somehow I prefer to be quoted in context.
--Loring
> -----Original Message-----
> From: John D. Mitchell [mailto:johnm-antlr at non.net]
> Sent: Monday, May 02, 2005 11:52 PM
> To: Loring Craymer
> Cc: 'ANTLR Interest'
> Subject: Re: [antlr-interest] translation of $x references in v3.0
>
> >>>>> "Loring" == Loring Craymer <Loring.G.Craymer at jpl.nasa.gov> writes:
> [...]
>
> > Nope--I objected to locking the implementation of them into a dictionary
> > (keyword lookup) and still do. The analysis cost of class construction
> > for classes containing attributes is not that onerous, and the set of
> > attributes can be determined from the grammar at the time it is
> processed
> > by ANTLR. "Dynamic" (as in hash table) is an implementation choice with
> > an associated performance cost. For Java, you pay the implementation
> > cost of hashing up front--all objects have hash codes, so the
> performance
> > cost of a hash table for attribute lookup is at worst a factor of 2 or
> so
> > (access overhead should be on the order of a factor of 2--less if access
> > is through method calls, more if fields are directly dereferenced--but
> > that limit is approached only when attributes are not used much for
> > computing)- [This is not a diatribe against hash tables, just where they
> > are placed. ANTLR should use hash tables to gather attributes during
> > analysis, but generate classes with attributes defined as fields; the
> > user should not suffer a performance hit because hash tables are
> > generated for his code automatically. At issue is the tradeoff between
> > performance and functionality: in this case, there is no differential in
> > functionality, but the performance differential could be significant.]
>
> I'm confused by your harangue. What does this implementation detail have
> to do with the topic of @ being used to refer to dynamically-scoped
> attributes?
>
> Thanks,
> John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20050503/4e5fa5f3/attachment.html
More information about the antlr-interest
mailing list