[antlr-interest] Re: What's the SLK Parser Generator?

mzukowski at yci.com mzukowski at yci.com
Tue Oct 8 15:36:43 PDT 2002


Cook & Welsh's approach is kinda hacky too in that they assume you want to
work with a parse tree and not an AST.  If you're sticking with antlr then
take the antlr attitude of asking "how would I do it by hand?" and then
automating it if it is worth the effort.  

For instance in java you could make an entry point into the java grammar to
recognize methods.  As they edit the method just keep running that rule and
replacing the AST and updating the symbol table.  LL is nice that way.  Note
that you can't just call the existing method rule because antlr "knows" that
that rule is never called by itself, only from other rules.  Create a new
rule that calls method follwed by EOF and you won't have any problems with
the follow set.

Monty

> -----Original Message-----
> From: mrosgood [mailto:mrosgood at yahoo.com]
> Sent: Tuesday, October 08, 2002 1:01 PM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Re: What's the SLK Parser Generator?
> 
> 
> Terence Parr-
> 
> 
> Thanks for humoring me.  You may recall that, having only ever used
> ANTLR, I don't know a whole lot about this domain.
> 
> The real reason I asked is because I need one of those super duper
> text editors that's smart enough to recognize the language 
> and all that.  
> 
> I've got this GUI description language called Giraffe.  It's a mush of
> ideas, borrowing notions from XUL, VRML, RELAX-NG, and some other
> stuff.  The Big Idea is to have "live" Giraffe source code in one
> window and the real live GUI in other.  Change the source and --
> voila! -- the GUI changes.  Drop a new control onto the GUI and --
> voila! -- the source changes.  (Ever since my LISP days, I've nurtured
> a deep hate for edit-compile-debug loop style development.)
> 
> So...
> 
> These papers appear to be the best thing going on:
> 
> "An Incremental Lr Parse Strategy for Language-Based Editors"
> http://citeseer.nj.nec.com/320795.html
> 
> "Incremental parsing in language-based editors: user needs and how to
> meet them"  P. Cook and J. Welsh 
> Software: Practice and Experience 2001; Vol 31: 1461-1486.  
> John Wiley & Sons.
> 
> 
> I contacted Phil Cook and apparently the algorithm in the second paper
> fixes some problems.  Alas, it's not available online.
> 
> 
> Anyway, Cook's work uses a tweaked version of YACC (adds more stuff to
> the parse table).  They determined that LL(k)'s backtracking is too
> inefficient to be used interactively.  So when I saw SLK, and its
> claim of being table driven, I thought maybe there's an opportunity.
> 
> You can see that I'm grasping at straws here... <grin>
> 
> 
> Cheers, Jason Osgood / Seattle WA
> 
> 
> 
>  
> 
> 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/ 



More information about the antlr-interest mailing list