Grammatica TODO-List
Known Issues
This is a list of the known issues as of the release of
version 1.0 (2003-05-14). Please
verify that any new problem found is not in this list before
sending a bug report.
-
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. (Bug #3597)
-
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. (Bug #3598)
-
Documentation: The C# API is not documented
The Java API documentation is very similar, but there
are important differences in name casing and similar. Proper
C# API documentation in HTML should be generated as part of
the build process. (Bug #3612)
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.
(Bug #3599)
-
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++). (Bug #3600)
-
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. (Bug #3601)
-
Grammar: Identical productions 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. (Bug #3602)
-
Tokenizer: Improve processing speed
There are probably still substantial parsing speed
improvements to gain by improving the tokenizer performance.
All the obvious optimizations have already been done, however.
The next step is probably to create a DFA. (Bug #3603)
-
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. (Bug #3604)
-
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. (Bug #3605)
-
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. (Bug #3606)
-
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. (Bug #3607)
-
Analyzer: Allow node values propagating downwards
Improve the analyzer framework to handle node values
propagating downwards or sideways in the tree as well.
(Bug #3608)
-
Code Generation: Support creation of a C parser
This requires the writing of a C runtime library plus
appropriate code generation classes. (Bug #3609)
-
Code Generation: Support creation of a C++ parser
This requires the writing of a C++ runtime library plus
appropriate code generation classes. (Bug #3610)