[ This post, from the marpa parser Google group (https://groups.google.com/forum/?hl=en&fromgroups#!forum/marpa-parser) largely repeats what I believe to have been the result of a previous discussion in this group. I send it now because I know of several Marpa-based modules being created, suspect there are others, so that I think it may be timely. Thanks.]
The standard and traditional practice is, where a module or set of modules is associated with a top-level namespace, to reserve that namespace for modules controlled by a single team. The example cited most often is Moose, which top-level namespace is reserved for modules controlled by the Moose Team. Moose modules not under the control of the Moose Team often go into the MooseX namespace, which is reserved for that purpose. I feel that I need to follow this practice for Marpa. Modules going into the Marpa top-level namespace should only be those completely controlled by the Marpa Team. Among the places where other Marpa-related modules can go is into a top-level MarpaX namespace. I don't know the full history of the traditional practice, but there are at least two reasons why it is necessary in the Marpa case. The first is namespace management. The Marpa Team, to avoid collisions, and for its own expansion needs, requires a namespace that it controls fully. A second reason is least surprise when it comes to responsibility for the modules and issues with them. A user will have a reasonable expectation that, if there is an issue with a Marpa::X::Y::Z module, the Marpa Team are the people to go to about it. Under traditional practice, the Marpa Team is also entitled to control all namespaces with Marpa as a component, for example, Acme::Marpa::Widget. The Marpa Team will NOT exercise this traditional right. The Marpa Team feels that control of the top-level Marpa namespace is sufficient. The usual PAUSE and CPAN processes for granting namespaces, of course, still apply, and there may be cases where the Marpa Team wants input into those processes. In the above, I refer to the "Marpa Team". At the moment, this is simply me. Other projects of the size and complexity of Marpa are managed by multi-person teams, and I hope that will become the case with Marpa. Thanks, jeffrey kegler