[antlr-interest] Re: trees with payloads??

lgcraymer lgc at mail1.jpl.nasa.gov
Fri Nov 12 14:26:49 PST 2004



--- In antlr-interest at yahoogroups.com, "John D. Mitchell"
<johnm-antlr at n...> wrote:
> >>>>> "lgcraymer" == lgcraymer  <lgc at m...> writes:
> >>>>>> In antlr-interest at yahoogroups.com, "John D. Mitchell"
> [...]
> 
> >> IMNSHO, the dynamic attributes support is a fundamental feature of
> >> Antlr v3.
> 
> > Well, maybe.  It is a feature that has not yet been put to
experimental
> > test.  It might turn out to be extremely valuable, or it might be just
> > another bit of glitz.
> 
> It's more than just glitz.
> 
> Coming from a language designer's perspective, dynamically scoped
> attributes fill a capability niche that is not provided for by any
of the
> statically scope capabilities.
> 
> In terms of praxis, look at how many times people have written their own
> (buggy :-) version of dynamic attributes.  Heck, I've done it a
handful of
> times myself on different translation projects.

As have I, which is why I am in the believers camp.  However, it could
still be a feature which is only occasionally useful; until we try it
out, we won't know otherwise.

> 
> > Also, while Hashmaps might be required by ANTLR to support dynamic
> > attributes, that does not mean that they should be present in the
> > generated code.  Generating attribute classes or structures should be
> > pretty straightforward, and the runtime attribute containers should
> > probably be implemented as fields in the generated lexers,
parsers, and
> > treewalkers so that they are accessible within rules.  That would
> > certainly help to ensure that analysis passes (most of the work
done in
> > actions) can have good performance.  And the ANTLR 3 output templates
> > should make the code generation even easier.
> 
> Again, in terms of implementation, I'm extremely open to allowing the
> different code generators & runtime combinations to do whatever they
want
> as long as they provide all of the capabilities.
> 
> As I noted for the notes from the workshop, the dynamically scoped
> attributes need to support cabilities for things like LIFO & FIFO
access;
> specification of things like at most one/n, exactly one/n, at least
one/n;
> pushing/popping bundles of attributes; search current scope for
attribute,
> search up stack for attribute; etc.

This is an area where implementation is likely to have significant
impact on performance.  Yes, we should probably support multi-valued
attributes directly as well as the dynamic scoping, but "capability
first!" is the wrong mantra.  We also need to look at what disciplines
are necessary when using dynamically scoped attributes for
understandability and maintainability.  There are issues of data
typing for generated code, context (which scopes should be searched?)
management, and grammar maintainability (what scopes might apply) that
need to be considered in the design.  Otherwise, dynamically scoped
attributes can have as much negative impact as templates have for C++
as well as having equivalent positive impact.  "I can do everything"
can translate to "I can maintain nothing":  the range of
implementation models allowed can have a great deal of impact. 
Debugging usage of dynamically scoped attributes could be a nightmare.

--Loring

> Take care,
> 	John





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





More information about the antlr-interest mailing list