[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