78 lines
2.9 KiB
Text
78 lines
2.9 KiB
Text
[Last updated August 11, 2003]
|
|
|
|
Notes for myself:
|
|
|
|
Document the LINENO trick
|
|
|
|
Add a way to have a self-contained mode that doesn't require yappsrt?
|
|
|
|
Add a debugging mode that helps you understand how the grammar
|
|
is constructed and how things are being parsed
|
|
|
|
Optimize (remove) unused variables
|
|
|
|
Yapps produces a bunch of inline list literals. We should be able to
|
|
instead create these lists as class variables (but this makes it
|
|
harder to read the code). Also, 'A in X' could be written
|
|
'X.has_key(A)' if we can convert the lists into dictionaries ahead
|
|
of time.
|
|
|
|
Add a convenience to automatically gather up the values returned
|
|
from subpatterns, put them into a list, and return them
|
|
|
|
"Gather" mode that simply outputs the return values for certain nodes.
|
|
For example, if you just want all expressions, you could ask yapps
|
|
to gather the results of the 'expr' rule into a list. This would
|
|
ignore all the higher level structure.
|
|
|
|
Improve the documentation
|
|
|
|
Write some larger examples (probably XML/HTML)
|
|
|
|
EOF needs to be dealt with. It's probably a token that can match anywhere.
|
|
|
|
Get rid of old-style regex support
|
|
|
|
Use SRE's lex support to speed up lexing (this may be hard given that
|
|
yapps allows for context-sensitive lexers)
|
|
|
|
Look over Dan Connoly's experience with Yapps (bugs, frustrations, etc.)
|
|
and see what improvements could be made
|
|
|
|
Add something to pretty-print the grammar (without the actions)
|
|
|
|
Maybe conditionals? Follow this rule only if <condition> holds.
|
|
But this would be useful mainly when multiple rules match, and we
|
|
want the first matching rule. The conditional would mean we skip to
|
|
the next rule. Maybe this is part of the attribute grammar system,
|
|
where rule X<0> can be specified separately from X<N>.
|
|
|
|
Convenience functions that could build return values for all rules
|
|
without specifying the code for each rule individually
|
|
|
|
Patterns (abstractions over rules) -- for example, comma separated values
|
|
have a certain rule pattern that gets replicated all over the place
|
|
|
|
These are rules that take other rules as parameters.
|
|
|
|
rule list<separator,element>: {{ result = [] }}
|
|
[ element {{ result.append(element) }}
|
|
( separator element {{ result.append(element) }}
|
|
)*
|
|
] {{ return result }}
|
|
|
|
Inheritance of parser and scanner classes. The base class (Parser)
|
|
may define common tokens like ID, STR, NUM, space, comments, EOF,
|
|
etc., and common rules/patterns like optional, sequence,
|
|
delimiter-separated sequence.
|
|
|
|
Why do A? and (A | ) produce different code? It seems that they
|
|
should produce the very same code.
|
|
|
|
Look at everyone's Yapps grammars, and come up with larger examples
|
|
http://www.w3.org/2000/10/swap/SemEnglish.g
|
|
http://www.w3.org/2000/10/swap/kifExpr.g
|
|
http://www.w3.org/2000/10/swap/rdfn3.g
|
|
|
|
Construct lots of erroneous grammars and see what Yapps does with them
|
|
(improve error reporting)
|