I apologize for taking so long to reply to John's thoughtful post re Marpa and its interface. My excuse is that, while researching the issue and mulling over what John had to say, my answer changed several times.

I'm much more sympathetic to the idea of incorporating inheritance into Marpa's semantics than I was at first, for two reasons. First, grammars in Perl 6 allow inheritance. When it comes to interfaces I try to imitate Larry Wall, even when I'm not at all sure why he's doing what he's doing. I find if I don't imitate Larry, I often end up learning that he was right the hard way.

Second, rereading John's post, I do see his point -- the interface really does seem to beg to be extended just that teensy extra step to methods and objects. And these days, once you've added methods and objects, the nose of the proverbial camel is under the flap of the tent and you may as well start figuring out where to put the rest of the animal.

I have four reasons not to head down this road immediately:

1.) It would definitely add complexity to the interface for the semantics, already the most complex part of Marpa's interface. For a new module especially, a dauntingly complex interface is a sure-fire way to delay acceptance.

2.) Object-oriented is not a major research interest of mine. I am quite happy to let others take the lead in it. When it comes to inheritance, I am even less enthusiastic. I have no desire to impose these preferences on others, especially if doing so would delay the acceptance of Marpa, but it is my research interests which guide my priorities.

3.) Marpa currently allows even anonymous subroutines in its semantics, via an override mechanism. In fact, anonymous closures, generated at run time, play a major role in at least one Marpa application. For this override mechanism, it is very handy to have a well-known and easily determined name for every function used in the semantics. What John (with a certain irony) terms the "brutal directness" of my naming mechanism is, in this context, a feature. This feature would need to be preserved or replaced with something just as good.

4.) At this point, the internals of Marpa are likely to develop in a way that offers new opportunities for interface experimentation. Most of my work is on putting the core algorithm of Marpa into a highly optimized C library -- libmarpa. libmarpa is almost totally agnostic on interface issues. An obvious step beyond this would be to create a new, "thin" Perl XS interface to libmarpa, so that users can create their own Marpa-based parser generators. If in doing this I wound up out of the interface business, I would deem it an outcome that was devoutly to be wished.

Here's a suggestion for someone interested in experimenting with a new semantics for Marpa: As John notes, all Marpa's semantic actions have a first argument which can be created by a package constructor, and this is already a kind of "self" argument. A package constructor in Perl can in fact return anything -- including an arbitrarily overloaded object blessed into a package which has nothing to do with the package that contains the constructor. It could be arranged that all semantic actions call another method on this object, passing on their arguments. All this comes at a modest cost in time and a higher one in elegance, but it would allow someone so inclined to experiment with arbitrary complex inheritance object-orientation schemes while using the Marpa parse engine.