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

[John D. Mitchell]

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

Sigh.  This is going to be my last post on this thread.

[...dynamically scoped attributes...]

> That is certainly true, but it is also clear that you assume that
> dictionaries/hash tables are fundamental to providing dynamic attribute
> support.

I think that I've been explicitly clear on the fact that I don't care how a
given code generator & runtime implement the model.  Just that they
implement the model with fidelity. I.e., I'm a firm advocate for the "as
if" rule.

> I don't; in fact I think that that approach would lead to poor
> performance in the hands of typical developers and should be avoided for
> that reason.  From my perspective, symbol table support is almost
> orthogonal to the dynamically scoped attributes.

And driving things to an overly static model is certainly something that
I'm worried about in the face of too much "performance at all costs"
whining and complaining prior to serious profiling [and folks please be
clear that I'm talking about Antlr v3 -- we all know that v2 has serious
problems in terms of e.g., performance.]

[...]

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

> You have left out Performance; that was the driver that got Ter started
> on DFAs for lexers and from there to the LL(*) model.  "Capability" has
> differing interpretations: the real goal is fast turnaround of language
> processors, not to try to incorporate all features which might be useful.
> Simplicity actually just sort of crept in; I would say that it is present
> "only" as a matter of good design practice.

No, you're missing a key point that performance as a requirement is just
another capability.

Simplicity is not a side-issue. It's absolutely essential.  For one, it's
one of the things that keeps the "creeping featuritis" from taking over.
Also, true simplicity (from a systemic perspective, not just myopically :-)
increases performance, reliability, robustness, and power.


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

> There are too many custom classes in ANTLR 2--lists, bit arrays,
> etc.--that could be done away with.

Yep, and many of them won't be coming back in v3.  Yee haa!

> There are also features like AST class generation which could be easily
> supported but are not.  Incorporating these would significantly improve
> usability.

I, for one, am certainly interested in hearing such ideas.  [Up until the
last week or so, Ter has been pretty ruthless in staying away from thinking
(let alone talking) about trees so that he could stay focused on lexing and
parsing.]  In terms of generating AST classes that would help deal with the
whole homogeneous vs. heterogeneous tree war. :-)


> I would definitely quibble with the idea that things are left up to the
> whim of the code generators.  ANTLR 2 proved that code generation was
> very much at the mercy of the implementation model.  I don't really think
> that ANTLR 3 will be much different, and that is especially true for
> attribute support.

I wouldn't use the word "whim" as the code generators (at least any that
want to become "official") have to support all of the Antlr core model.

[...]

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

> I've seen too many cases of "if it can be abused, it will be abused
> whole-heartedly; FUBAR is a way of life".  You should be very paranoid.

Colloquially, I am paranoid but not petrified. Precisely, I deal in
balancing consequences.  Heck, I've worked on mission- and life-critical
systems: embedded, medical, and financial systems so I have a wee bit of an
idea about software quality. I've also written testing software and taught
software testing and development processes.  But, we do need to be clear
that (production) use of Antlr is not targeted at incompetent people and
therefore my calibration is different.

As I noted, the structure of a grammar literally provides a backbone to
(each phase of a translation) system and that fundamentally changes the
basis against which the dynamically scoped attributes will be used
(especially in comparison to the wild west nightmare of old-school
dynamically scoped variables in general purpose programming languages).
Can they be abused?  Of course.  But is that risk in the context of Antlr
fundamentally any different than letting people manipulate trees (or heck,
giving people the ability to lex and parse in the first place)?
Manipulating code is non-trivial.

Leaving out a fundamental, enabling capability from Antlr is, IMNSHO,
unacceptable.  Again, as I've noted, people manually build their own takes
on dynamically scoped attributes over and over and over again for a wide
variety of uses.  Adding capacity for allowing the dynamic attributes to
exist is very cheap in both time and space. So, the bang for the buck is a
no brainer.  If you have better ways of providing this capability, I'm all
ears.

Thanks,
	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/