I ran into a problem trying to imitate the special-case parsing logic
that was found in an old recursive descent parser I was translating
from.
Basically, I am trying to do this:
WRITE "(" write_list ")"
where write_list is a sequence of either expr or STRING, separated by
commas, and the expr is a "standard" expression made up of the usual
binary operators (+, -, *, /), unary minus, and parentheses involving
INTEGERs and STRINGs, where STRINGs have the semantic of the ordinal
value of the first character and the rest are simply ignored (in
Python code, it is just ord((STRING[:1]+'\0')[0]) ).
The STRING in write_list should be treated differently from expr in
that all characters get output, and any subsequent operators appearing
after STRING is illegal.
If you think about it, you can see how a recursive descent parser code
would simply see a STRING as the first token, and makes a special case
for it, then search for a comma or a closing parenthesis before going
on.
So:
WRITE('Hello') is legal, and it prints Hello
WRITE('Test'+9) is illegal
WRITE(('A'+8),6+4) is legal and it prints 73 10
How do I do that in Yacc (PLY flavor, naturally)?
Now some remarks:
1) I notice that the document for PLY 3.2 has the blurb "version
3.0"...should it get updated to "version 3.2"?
2) Is it OK to access lexstate? I have a custom lexer that is a
wrapper class for ply.lex; itactually manages the token outputting and
so I need to know its state (it works beautifully, by the way). The
document doesn't say anything about accessing the state, so I browsed
the lex.py source code to find out how :)
3) While coding up that same custom lexer class, I discovered that
yacc doesn't seem to retrieve the 'tokens' keyword from the lexer
class that I pass to (e.g. yacc.parser(lexer=mylexer)), so I
eventually figured out a hack: move the tokens to outside the lexer
class, then insert a 'tokens = tokens' line inside that class. It
works...but it seems wrong somehow to me. Thoughts?
4) When I set t.type to a literal (e.g. '%') in the lexer, Yacc (or
was it Lex?) complains it doesn't recognize that token. How do I fix
that?
5) I discover that yacc.py has enumerate(), which is a Python 2.3
thing. The document says that PLY should work on Python 2.2. I guess
it's time to bump up the version number, hmm?
6) While coding up a generator written using PLY, I got a subtle and
spurious "warning" bug re: p_error(). I studied the yacc.py code and
determined that since it uses a simple minded text scanning, it
flagged the p_error being embedded in a string. I thought to make a
note of it for everyone. I elect to ignore this harmless warning.
OK that will do for now. Good job, David Beazley!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"ply-hack" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/ply-hack?hl=en
-~----------~----~----~----~------~----~------~--~---
