Grammatica TODO-List
Known Issues
This is a list of the known issues as of the release of
version 0.4 (2003-05-08). Please
verify that any new problem found is not in this list before
sending a bug report.
-
General: Error messages needs improvement
Error messages printed by Grammatica could be much
improved in various ways. First, the faulting line could be
printed (as done by javac). Secondly, many of the error texts
should be clarified to something more simple to
understand. Thirdly, errors in syntetic productions are
reported to their syntetic names, which is very confusing and
hard to understand.
-
Regular Expressions: Not fully JDK 1.4 compatible
The regular expression library is still lacking in some
ways compared to the implementation in JDK 1.4 (or Perl 5).
The library should be extended to support as many constructs
as possible.
-
Documentation: Reference manual not complete
The reference manual is still very much incomplete.
Most issues are touched with extreme brevity and need further
elaboration to be readily understandable.
Suggested Improvements
This is a list of the currently known suggested
improvements.
-
Grammar: Add support for modular grammars
By allowing one grammar to reference another, it
would be possible to create more complex modular parsers.
This feature also requires support for modular tokenizers
and parses, as well as the generation of modular code.
-
Grammar: Add localization support
This includes finding an architecture that works for
grammar files, making it possible to localize the error
messages without rewriting the grammar file. This
architecture must support different methods depending on
generated source (ResourceBundles in Java, Gnu Gettext in C
& C++).
-
Grammar: Add support for error recovery
Error recovery or fallback productions should be
possible to add to the grammar. This would make it possible
to report various syntax errors. This also requires some sort
of error log.
-
Grammar: Identical production should be unified
Identical syntetic productions are not indentified as
such. Instead, a new syntetic production is added in each
case. This will cause problems for LR parsers, and is
generally inefficient. Identical syntetic productions should
be unified.
-
Tokenizer: Speed improvements
There might still be substantial gains in the tokenizer
performance by various optimizations. All the obvious
optimizations have already been done, however. The next step
is probably to create a DFA.
-
Tokenizer: Add support for modes
When reading certain tokens the tokenizer should be
able to enter some kind of "mode", limiting the set of tokens
that are considered for a match. This is highly useful in
some grammars, where the token syntax isn't easily
represented with regular expressions.
-
Tokenizer: Add support for "hidden" tokens
This feature could be used to parse source code while
maintaining the whitespace tokens accessible in some way,
very useful for writing a code style checker.
-
Parser: Add support for LR grammars
This probably means writing at least an LALR(1) parser,
and probably also some kind of LR(k) parser.
-
Parser: Add parsing through code callbacks
This would allow more complex grammars to be parsed
where some productions cannot be expressed in EBNF. Instead a
callback method would be called to parse some specific
productions.
-
Analyzer: Allow node values propagating downwards
Improve the analyzer framework to handle node values
propagating downwards or sideways in the tree as well.
-
Code Generation: Support creation of a C parser
This requires the writing of a C runtime library plus
appropriate code generation classes.
-
Code Generation: Support creation of a C++ parser
This requires the writing of a C++ runtime library plus
appropriate code generation classes.