PPCompositeParser has its limits. I hate the instance variable mess, but it kind of makes it convenient to refer to other productions. In Helvetia there is a different implementation of PPCompositeParser that works with the same grammar source but compiles variable accesses to use a dictionary instead. This then scales to an almost infinite number of productions. I agree that introducing the Helvetia dependendency is not feasible though. I wonder if we could use some other trick that wouldn't require a custom compiler and that would work across platforms? That is a possiblity, if they don't depend on each other circularly and if you don't mind the object duplication. Also you can build your productions more imperatively (like in many examples and the tests you see floating around) instead of purely declaratively as it is mostly done with PPCompositeParser. Typically grammars are quite clustered and have complex leaf nodes (the tokens in general, string and number literals, comments, etc.) that can be factored out. Cheers, Lukas -- Lukas Renggli www.lukas-renggli.ch

CUCompositeParser. It performs a series of transformations on all production methods, so 1. it automatically adds the return statement 2. it automatically converts literals to their respective parsers 3. it automatically converts variable accesses to dictionary accesses That has different semantics, so I don't think that this is a good solution. If you don't mind writing something like self @ #otherProd or with some heavy meta-programming #otherProd ref to refer to other productions, one could use the dictionary approach from the Helvetia image. With a rewrite rule you could quickly fix the existing code. Lukas -- Lukas Renggli www.lukas-renggli.ch