/ 
Marpa-0.001_020
/ Marpa::Doc::To_Do

NAME

Marpa::Doc::To_Do - Marpa's To Do List

PRINCIPLES

MDLex and MDL will know about Marpa, but not vice versa.

ORDERED TASKS

  • Or_map's should be hashes instead of arrays.

  • Add tokens() call, to allow multiple earlemes in cookie/incremental form, to be added at once.

    Add complete() call, to allow completions up to an earleme specified in the arg. Default is up to the furthest earleme, which is identical to the present end_input. In array context, this should return the predicted terminals.

  • Allow action options to be changed when evaluator is created, but not afterwards.

  • Create a "stress test" for zero-width and-nodes and or-nodes: A grammar with two rules in a cycle. Each rule is all nulling (nullable?) symbols except for the last symbol, which must be non-nulling.

  • I may assume in several places and zero-length and-nodes have no cause or predecessor. I have to find any places where this assumption is being made, and change it. In addition to the above test, I may want to reread the relevant evaluator code.

  • Create HTML Parser.

HIGH PRIORITY

  • After MDL is factored out, and stripping & cloning is fully functional, create a matrix of tests of valid grammars vs. their result. Matrix is

    grammars X inputs X clone grammar X clone recognizer X strip grammar X strip recognizer

    Do just one or two inputs per grammar.

  • Implement an recognizer option to simply skip ahead spans where no terminal can possibly be found. This means coming up with some way of passing Marpa's idea of where the next terminal should be expected to the lexer. Also the lexer should be able to inform Marpa which earleme a token is at.

    Use PREDICTIVE flag to the Recognizer to enable this?

  • I should start to assume that anyone explicitly using separate recognizer and evaluator stages knows what they are doing. Revise the documentation accordingly. Just because they are using the plumbing interface does not mean they want to know about the recognizer/evaluator distinction.

  • Add optimizations when max_parses <= 1 For example, no need to prune duplicate parses

  • Add MAX_COUNT for rules. Implement on one of left- and right- recursion only. No immediate need for both.

MEDIUM PRIORITY

  • Add a SYNOPSIS to the Plumbing document.

  • When rereading Internals doc, check if parse bocage creation can probably be made a bit slightly cleaner.

  • Make sure that nulling symbols can never be terminals

LOW PRIORITY

  • Add a trace_choices option? There was an option to trace non-trivial evaluation choices in the old evaluator, and the new trace_iterations doesn't entirely replace it.

  • Add a show_derivation option.

MAYBE, MAYBE NOT

  • Allow call to show_tree before first call to value? Should it cause an error message? How about after unsuccessful call to value?

MDLex

  • MDLex currently does not sort terminals by priority. This means terminal priorities are totally unused. Change this?

MDL

MDL is EOL'd.

  • In the MDL grammar, concatenate_lines is called uselessly in a number of places. Eliminate this, for efficiency's sake?

  • bin/mdl in parsing equation.marpa (which is used for many examples in the author.t/Makefile) takes a final return and parses past it, but does not fail.

    The return is NOT in the grammar. What happens is that the call to ::text() is not recognized as a failure, and then the evaluator looks at the last successful parse.

    What to do here? It should be failing, probably. And does the current behavior of the evaluator, (taking the default end as FURTHEST_EARLEME) set the user up for spurious successes.

SUPPORT

See the support section in the main module.

AUTHOR

Jeffrey Kegler

LICENSE AND COPYRIGHT

Copyright 2007 - 2009 Jeffrey Kegler

This program is free software; you can redistribute it and/or modify it under the same terms as Perl 5.10.0.