[antlr-interest] translation of $x references in v3.0

[Loring Craymer]

At 01:36 PM 5/2/2005, John D. Mitchell wrote:
> >>>>> "Loring" == Loring Craymer <Loring.G.Craymer at jpl.nasa.gov> writes:
>[...]
>
> > To the user, having two special characters converts the simple question
> > of "what is a.b.c.d" to "Should I write $a.b.c.d or @a.b.c.d here?  For
> > that matter, what is $a.b.c.d and how does it differ functionally from
> > @a.b.c.d?  And what is @a.b.c.d, anyway?"  Unless these are used in
> > wildly different ways--which seems inconceivable except as a design
> > failing--the user should only have to worry about one consistent
> > interface to data (attributes).
>
>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.

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.]

--Loring


>@x.y are always, only dynamic attributes.
>
>$i are always, only the various local, statically-scoped variables.
>
>Take care,
>         John