[antlr-interest] Re: Annotation tool best practices

[micheal_jor]

--- In antlr-interest at yahoogroups.com, "John D. Mitchell"
<johnm-antlr at n...> wrote:
 
> For a concrete and available example, check out what Monty did with the
> GnuC project with "literate programming" (ala Knuth via noweb).  That
> allows for nice, cross-phase locality (i.e., all of those versions of
> expression right next to each other).  One of my dislikes for that
approach
> is that the intermingling makes in more difficult to just look at all of
> the rules for a single phase (in the editor).  On my play-with to-do
list
> is to investigate using a "literate" approach with a good outline
editor so
> that I could fold out all of the stuff that I didn't want to deal
with at
> any given point in time (think: different, editable views of a single
> master source file).

I looked into that and the inability to "extract" the view of a single
pass forced me to move on.

> Another "trick" you can do with the tree phases is to create a single,
> super-set tree definition that encompasess all of the needs of all
of the
> different phases.

Thought about that but the performance implications of all those
unneccessary activation record operations keeps me looking for another
option. Still, it remains the 2nd choice after the default of
maintaining each grammar separately.

> In the majority of my experience, I keep it simple (if not
simplistic :-)

Same here. Unless multiple output langauges are involved. In that case
each phase gets the annotation tool treatment.

> IME, the issue for me is much less dealing
> consciously with the isolated, individual (sets of) rules across
multiple
> files but rather needing a true grammar level "diff" tool to catch those
> cases where I wasn't conscious (or smart) enough to realize that a
> particular change in one spot needed to be account for in other spots.

If there was a tool that separates the grammar (and it's editing) from
the noise (i.e. action code, method signatures, etc) that real
lifework adds to it, then the diff tool won't be needed ;-)

> Finally, on a related subject, there seems to be two schools of thought
> on how to use grammar based approaches.  One is the "pure" school which
> says that the grammar drives the system.  The other is that the
grammar is
> a slave to the rest of the system.  The argument, IMHO, isn't one versus
> the other but rather (a) which one to use for which needs and (b)
whether
> or not it's acceptable to mix the approaches.
> 
> In terms of (b), I'm unsure of but am concerned about your dottedNameXYZ
> example as it's unclear to me why you (feel that you) need to take that
> variation approach.  I.e., why isn't there only a single rule in the
> grammar that provides the underlying information such that whatever is
> consuming that information can extract it as appropriate?

I guess I could write auxiliary routines to walk the sub-tree as
needed and extract the information. Or I could write a generic rule
that extracts all info from the tree pass it to other routines to work
on it. It just felt more natural to define alternative walks of the
same subtree as alternative rules. Helps my understanding loads and,
since results are often written back as attributes, I am in the
"right" place to do everything if I use the rule's srructure.

Micheal




 
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/