|loops in bison firstname.lastname@example.org (Aaron Jewell) (2000-08-04)|
|Re: loops in bison email@example.com (Chris F Clark) (2000-08-05)|
|Re: loops in bison firstname.lastname@example.org (Aaron Jewell) (2000-08-10)|
|Re: loops in bison email@example.com (Chris F Clark) (2000-08-13)|
|From:||Aaron Jewell <firstname.lastname@example.org>|
|Date:||10 Aug 2000 00:10:17 -0400|
|Organization:||Willowglen Systems Inc|
Thanks Chris, John!
Unfortunately, the script must work closely with my company's product
in a way not easily done with perl et al.. (and between you and me,
most people where are work struggle enough as it is with C++, so
forcing them to learn another language to maintain my code would not
make me popular)
Almost immediately after posting my original question I did decide to
use a tree in the manner described (after following someone's advice
to look over the ksh code) and managed to throw one together over the
weekend (its very small and simple language).
I am curious though.. what is this parser generator that will build an
AST for me and where can I find it?
Chris F Clark wrote:
> The following message is a courtesy copy of an article
> that has been posted to comp.compilers as well.
> > One idea I had is to redirect yylex()'s input from a string and then
> > feed the parser a series of strings read line by line from the
> > script file. That way I could buffer those strings corresponding to
> > the statement_list within the loop and run them through the lexer
> > again 'n' times. However, I'm not sure if this will work - for
> > example, if the END_LOOP token falls on the same line as the last
> > statement in the statement_list. It may also be alot of work and
> > unfortunately a have limited time to implement this.
> > [Once again, my advice is "don't do that". . . . -John]
> Even if you ignore the moderators sound advice of not inventing your
> own scripting language, don't implement it by reparsing the input to
> implement loops (nor by skipping around in the input to implement
> Parse your input exactly once, build a "tree" that represents the
> input, and walk the tree to execute the program. You will save
> yourself considerable grief over the long run. ...
Return to the
Search the comp.compilers archives again.