Marpa::R2 To Do -- "To Do" list for Marpa

About this document

This list needs to be revisted in light of the Kollos project. Most of its items will probably never been done in Marpa::R2.

Items to do

Add pseudo-symbols: :null, :empty -- sugar for empty RHS alternative

Add pseudo-symbols: :external, :never -- sugar for [^\d\D]


Add the ability to switch lexers.

To think about


marpa_r_progress_report_reset() was documented, but is no longer used. I probably should put it into the test suite.


This is a list of ideas with real merit, but also with issues. The issues are described for each. I will not prioritize any item on this list until I've figured out how to deal with the issue.

'?' quantifier for SLIF rules


    lhs ::= optional_symbol?

This is a natural addition to the Kleene star ("*")and plus sign ("+"). The issue is that this would be implemented as a rewrite into two rules, like so:

    lhs ::= optional_symbol
    lhs ::= # empty

If I create the rules internally, there's a problem in describing them for tracing and debugging. This issue does not exist if the user writes the rules himself. I take the naming issue very seriously, because Marpa's tracing and debugging ability is one of its important advantages.

Perl anonymous subroutines as SLIF actions

Allowing Perl anonymous subs as semantics would tie the SLIF more heavily to Perl than I am inclined to at this point. In particular, I am not sure, whether there should be a default semantics, and whether if there is one it should be Perl or something more targeted.

A disadvantage of allowing Perl code is that problems (compile-time warnings, compile-time errors, run-time warnings, run-time exceptions and run-time errors) all must be handled inside Marpa. This is hard to handle well, and even when handled well, makes debugging harder for the application. It is for this reason that action names are used in Marpa.

More syntax for RHS subexpressions

There are various suggestions for RHS sub-expressions, which share a common issue. There's a hidden tradeoff for cool syntax -- it usually involves grammar rewrites internally. In the tracing and debugging output, internal rules need programmatically-concocted names for special symbols, and these are hard to read. Users find symbol names easier to read if they named the symbols themselves.

People don't get grammars right the first time, and I currently think it better to force the application to spread things over multiple lines. That way, when the tracing and debugging reports about a rule, the programmer knows what that rule is because the programmer wrote the rules out himself, long-hand.

I am currently pleasantly surprised at how well Marpa users cope with the current level of rule rewriting. Nonetheless, I do not want to push my luck.

Copyright and License

  Copyright 2014 Jeffrey Kegler
  This file is part of Marpa::R2.  Marpa::R2 is free software: you can
  redistribute it and/or modify it under the terms of the GNU Lesser
  General Public License as published by the Free Software Foundation,
  either version 3 of the License, or (at your option) any later version.

  Marpa::R2 is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser
  General Public License along with Marpa::R2.  If not, see