pyparsing and 'keywords'

Paul McGuire ptmcg at austin.rr._bogus_.com
Tue Dec 14 15:21:05 EST 2004


"Berteun Damman" <berteun at NO_SPAMdds.nl> wrote in message
news:slrncruece.a97.berteun at cal005302.student.utwente.nl...
> On Tue, 14 Dec 2004 18:39:19 GMT, Paul McGuire
> <ptmcg at austin.rr._bogus_.com> wrote:
> >> If I try however to parse the String "if test; testagain; fi;", it does
> >> not work, because the fi is interpreted as an expr, not as the end of
> >> the if statement, and of course, adding another fi doesn't solve this
> >> either.
> > The simplest way I can think of for this grammar off the top of my head
is
> > to use a parse action to reject keywords.
>
> Thank you for your quick and good solution, that did the trick indeed.
>
> But I'm wondering, isn't it possible to have some sort of lexing phase
> which already identifies keywords as such? Or to provide a table with
> keywords, which pyparsing is able to automatically recognize?
>
> So you would be able to do IF = Keyword("if"), just as a Literal now is
> created, but now the parser knows this word shouldn't be interpreted any
> other way than as a keyword. Or would that be a bad idea?
>
> Berteun
Berteun -

This is not a bad idea in and of itself, as I mentioned earlier, I had
similar problems with the idl parser.  For example, if in the body of your
if block you had a statement:

    ifThisWorksItsAMiracle;

The leading "if" would match the Literal("if"), although the statement is
actually the complete 'ifThisWorksItsAMiracle' method call.  That is,
Literals are not automatically assumed to be whitespace-terminated.  This is
part of pyparsing's philosophy of being whitespace-blind.

It's been a while since v 1.2.2 was released, I think adding a Keyword class
much as you describe (on top of the other bug-fixes and additions since
then) would be sufficient material for coming up with a 1.3 release.  I'll
work on it over the holiday "break," assuming I get one!

-- Paul





More information about the Python-list mailing list