[antlr-interest] ANTLRWorks GUI dev environment videos

[Loring Craymer]

Ter--

I don't think that modifying the codegen template at the user level makes
sense for routine use, although that's an implementation approach.  I think
that the better implementation approach is to provide a facility for
regenerating the source grammar while adding annotations.  Leaving it at the
codegen level makes it a "for experts only" feature, and I think that the
feature set at the GUI level would end up being fairly minimal (EBNF is a
simple language, after all).  Bringing a generated grammar to the surface
(where the GUI is aware of it) makes it possible to use diff tools, insert
actions, and use the grammar refactoring support.

You're right on the "remove left recursion".  Also, the "left factor" should
probably be generalized to "consolidate factors" or some such.  Those,
however, are the features which have noticeable implementation cost--for the
others, I expect that most of the implementation is doing the dialog boxes.

--Loring

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Terence Parr
> Sent: Sunday, April 10, 2005 1:51 PM
> To: 'ANTLR Interest'
> Subject: Re: [antlr-interest] ANTLRWorks GUI dev environment videos
> 
> 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
>