Skip to content
Francis Galiegue edited this page Apr 29, 2014 · 14 revisions

First of all...

There is a lot of [c(h)ore stuff to do]!

(nearly) Basic stuff

More base rules

Right now there are no such basic rules as digit(), asciiLetters() or ws() (for whitespace) defined! This is rather painful since it means you have to write them all each time.

The plan is to add all rules defined by section 1, appendix B of RFC 5234, since they are very, very widely used (among others in other RFCs).

And also a join() rule:

join(rule()).with(joiningRule()).times(3);
join(rule()).with(joiningRule()).atLeast(3);
join(rule()).with(joiningRule()).times(4, 9);
// etc

Those are the basics. Maybe some more Unicode related rules would be nice as well -- though what would be supported would depend on your JVM. Still, could be useful...

Advanced stuff

"Fluent" rule building; easier to consume values

I have attempted it but have failed so far. It would be nice to be able to do stuff like this:

Rule myRule()
{
    return store(some(), rules(), here()).into(someConsumer);
}

But all my attempts so far have failed at sharing the context appropriately...

Very advanced stuff...

Java 7 and invokedynamic

Right now, the generated parser passes through ProxyMatcher instances (sometimes recursively so!) to delay rule building; for instance, consider this grammar:

public MyParser<V>
    extends BaseParser<V>
{
    Rule delegating()
    {
        return sequence("hello", delegate());
    }

    Rule delegate()
    {
        return String(" world");
    }
}

In this case, when the delegating rule byte code is generated, it will first generate a proxy for delegate; this proxy will be unwrapped and delegate will be replaced with the unwrap only when the time comes.

If I understand indy (invokedynamic's "nickname") correctly, proxies can be replaced with indy.