[antlr-interest] Re: ACE C preprocessor by Gosling

[mzukowski at yci.com]

I would add 

    9.)  Error history.  Some errors and warnings can't be turned off, even
when you want to.  It'd be nice to know what are only 'new' errors and
warnings.
    10.)  Built in version control.  I do an RCS checkin with every compile
because it's so easy to lose a semicolon or whatnot.  This should persist
across invocations of the editor, (persistent undo, basically) but not rely
on the normal version control someone is using for the whole project.

Monty
www.codetransform.com

> -----Original Message-----
> From: lgcraymer [mailto:lgc at mail1.jpl.nasa.gov]
> Sent: Friday, May 31, 2002 2:48 PM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Re: ACE C preprocessor by Gosling
> 
> 
> --- In antlr-interest at y..., Bogdan Mitu <bogdan_mt at y...> wrote:
> > 
> > --- Terence Parr <parrt at j...> wrote:
> > > Cool.  There should be lots of work for all...Loring is talking 
> about an 
> > > editor that highlights ambiguities etc... ;)
> > 
> > Here I might be able to help. I already have an editor with syntax 
> highlight
> > for ANTLR, an improved Ant task, and kind of "unit test" framework 
> for ANTLR
> > grammars. If someone needs them, just let me know.
> 
> That would help.  What I've actually been thinking about is an 
> interactive development environment for ANTLR with
>     1.)  Rule database.  This would make it easier to reuse pieces of 
> grammars.
>     2.)  Refactoring support.  This would include ordering 
> alternatives to minimize "k" within a rule, computation of minimal 
> syntactic predicates, etc.
>     3.)  Tree grammar generation and storage of rewrites:  
> the idea is 
> that you generate a tree grammar from a predecessor parse or tree 
> grammar, and refactor the generated grammar.  After the predecessor 
> grammar is changed, a new version of the tree grammar is 
> generated and 
> the refactorings applied automatically.
>     4.)  Interactive grammar analysis and editing support for a 
> multi-grammar chain (lexer, parser, multiple tree grammars).
>     5.)  Output "grammar" support.  This is the last painful part of 
> building ANTLR translators.
>     6.)  Full LL(k) analysis and predicate hoisting (just to 
> point out 
> that John Mitchell has the right idea here).
>     7.)  Testing support.
>     8.)  Whatever else makes sense.  You mentioned reverse 
> translation 
> support in a previous post; that might be possible via adding 
> "comments" on deleted nodes (! is not reversible otherwise) and 
> figuring out how to generate an ANTLR grammar as output--I suspect 
> that that would not be too difficult.
> 
> Except for the output grammar stuff (Ter's working on that), most of 
> this is either an extension of the current ANTLR engine or borrows 
> from other efforts.  My guess is that this would drastically reduce 
> turnaround for developing a language translator.  I suspect that such 
> an environment would make development of domain specific languages 
> into ordinary programming practice.
> 
> --Loring
> 
> > 
> > Bogdan 
> > 
> > > Ter
> 
> 
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 



 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/