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

[John D. Mitchell]

>>>>> "lgcraymer" == lgcraymer  <lgc at mail1.jpl.nasa.gov> writes:
>>>>>> <johnm-antlr at n...> wrote:
[...]

[...dynamically scope attributes...]

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

Um, er, doing symbol tables is a pretty fundamental need in doing
non-trivial translators.  The dynamically scoped attribute support is, at
the very least, the building block of symbol table management.

Um, er, variations of symbol table management such as def-use chaining
abound in non-trivial translation tasks.

As a personal data point that's completely current... In my current gig,
I'm doing a lot of tree mutation that involves splitting and splicing the
existing tree parts along with completely new parts.  All of the bookeeping
to make that work is, alas, all manually implemented dynamic attributes
(various incestuous combinations of inherited attributes, rule return
values, and propagated standard and manual tree construction).  The
"natural" solution to every single one of the non-trivial transformation
tasks came to mind using dynamically scoped attributes -- then I had to
make it work in the current Antlr.


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

Capability and Simplicity are the two driving forces in Antlr v3.
Sometimes they coincide and sometimes they are in direct opposition and
usually the reality is somewhere in the middle.

An underlying question that I keep hearing in your posts is the question of
where do we draw the line as to what goes into the Antlr core and what is
left to add-ons, libraries, the whim of the code generators and runtimes,
etc.  I think that's the question that we need to be ruthless in always
asking and ruthlessly honest in pursuing the answers.

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

I hear ya.

I'm less paranoid because the pervasive backbone provided by the grammars
themselves makes dynamically scoped attributes in Antlr qualitatively
constrained as compared to dynamically scoped variables in general purpose
programming languages.

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/