1. in PPMSEGrammar, start is encoded ad ^elements end

is that a good habit to include end in start method? Somehow this is counter intuitive to me since it seems it would make such grammar non embeddable in another parser, or I am mistaken?

Yeah, I think this is like a pattern. #start is just the default production when the parser is used standalone. When you compose it with some other parser you could directly go with whatever other production you want, i.e.

PPMSEGrammar new elements

2. can ==> be cascaded in a sense that if we have parser A, its subclass

parser B which calls supper and then adds ==>. Can we then have C which is subclass of B, and adds its ==> on top of the one added by B?

It is always cascaded. #==> just wraps the receiver with the action block, so if you write

p := (#word asParser ==> [ :each | each asUppercase ]) ==> [ :each | each asciiValue ]. p parse: 'a' --> returns 65, the ascii code of $A

3. What do you think, could PettitParser be reasonably used to de-marshal

some (binary) network protocol. By reasonably I mean that it would not be an order of magnitude slower than some code hacked from the scratch (but not terribly optimized).

Definitely. You would probably need to implement some special stream that works on the bit-level. Marcus and I once started to write a bytecode decompiler, that worked reasonably well but I don't know the status.

An optimized hand written parser is certainly faster. For performance I typically compare the hand written parser of the refactoring engine (RBParser) and the strictly equivalent one in PetitParser (PPSmalltalkParser). The hand written one is about 3.3 times faster.

Lukas