[antlr-interest] ANTLRWorks GUI dev environment videos
Terence Parr
parrt at cs.usfca.edu
Sun Apr 10 13:50:44 PDT 2005
On Apr 10, 2005, at 1:27 AM, Loring Craymer wrote:
Hi Loring,
Yep, I definitely have been thinking about refactoring and such. I am
also thinking about exemplar-based grammar development; got some cool
ideas.
Thanks for the list of stuff...need to add "remove left-recursion" i
think.
As for the aspect stuff, I think Monty may be right that simply
modifying the code gen template locally could be promising. You might
have some standard mods in a lib dir somewhere then use
target=TraceJava instead of target=Java or something.
Ter
> REFACTORING SUPPORT
> The basic refactorings for parser/lexer grammars (they also apply to
> tree
> grammars, but I can identify a much richer set of tree refactorings)
> that
> can be easily implemented include
> 1.) Rule renaming (all references are renamed)
> 2.) Extract rule (replaces "all" instances of a given token sequence
> with a
> rule reference--user should get yes/no choices for each instance)
> 3.) Inline rule (case-by-case or global)
> 4.) Clone rule (Copies and renames a rule definition; user is given
> opportunity to select which version applies for every reference to the
> original rule). Usually, the cloned rule will then be "specialized"
> to have
> a different set of actions and/or attributes from the original rule.
> 5.) Transform loop to recursion
> 6.) Transform recursion to loop.
>
> And, with only a little more effort
> 7.) Left factor alternatives in rule.
>
> One big advantage grammars have for refactoring is that you do not
> have much
> semantic state to worry about; I'd be very surprised if it took more
> than a
> few days to implement all of the above functionality--especially
> considering
> that most of the underlying support routines are probably already
> present.
>
> SOURCE-TO-SOURCE manipulations
> There is quite a bit that can be done simply by regenerating grammars
> with
> addition/subtraction of features with what should be minimal effort.
> It
> would be nice if some of these were supported at the editing level.
> 1.) Extract/import target source: This would be to enable
> refactoring of
> action code. Basically, the idea is to extract the usual block of
> action
> code (methods) plus all actions (including semantic predicates). The
> action
> snippets would be extracted as methods, perhaps named <rule>action<n>
> (the
> naming should make re-import easy).
> 2.) pre-Aspect ANTLR: Insert actions after ':' or before ';',
> before/after
> '(', ')', ')+', ')*', ')?' in cloned grammar. This, coupled with
> extract/inline rule, encompasses most of the functionality of an Aspect
> ANTLR; additionally making the insertion dependent on finding a
> sequence of
> token types would provide most of the remaining support needed. (Note
> that
> this provides a simple mechanism for the "traceIn/traceOut" feature of
> ANTLR
> 2 and PCCTS). Monty might have some further suggestions.
> 3.) Test rule generator: clone the grammar, adding a top-level rule
> which
> has each rule as an alternative, with a preamble. (The preamble might
> recognize "test" <rule> and then a sequence of tokens representing a
> test
> case.
>
> These require more effort than the refactoring support, but the added
> capability would probably be more than worth the effort.
>
> --Loring
--
CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Cofounder, http://www.jguru.com
More information about the antlr-interest
mailing list