[antlr-interest] translation of $x references in v3.0
Loring Craymer
Loring.G.Craymer at jpl.nasa.gov
Mon May 2 16:44:04 PDT 2005
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
More information about the antlr-interest
mailing list