[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