[antlr-interest] Re: Annotation tool best practices

[matthew ford]

Hi,
After reading noweb I coded CodeSections (attached, see the CodeSections.cs
for details)
It has the advantage that it is runs under ANT and is much simplier.  Still
no editor but should
not be too hard to do one.
I use CS to handle mutiple Tree parsers and to handle in-house versus
release versions of code (the in-house code has extra stuff)
matthew

----- Original Message ----- 
From: "micheal_jor" <open.zone at virgin.net>
To: <antlr-interest at yahoogroups.com>
Sent: Thursday, April 29, 2004 6:15 AM
Subject: [antlr-interest] Re: Annotation tool best practices


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


 
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/
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CodeSectionsV1_1.zip
Type: application/x-zip-compressed
Size: 13670 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20040430/70c55dc9/CodeSectionsV1_1.bin