While we're at it, I committed a tiny change to the assertions in PPAbstractParserTest, so that assertions return the parse result. I needed it for cases where I don't want to compare to an expected result, but still make further assertions than just "yup, it parses". For Coral I also wrote a simple PPDelegateParser subclass that applies its inner parser to the stream first element. It's like: PPPredicateObjectParser>>matching: elementParser message: aString ^ self on: [ :each | elementParser matches: each ] message: aString BUT: it will return the parse result of its inner parser, rather than the accepted element as-is. I use it to parse the argument array in a Coral script, some arguments are expected to be integers or other parseable. It allows me to predefine a bunch of utility parsers for simple argument types, that return a ready-to-use object. If you want to see the code, it's PPElementParser in the Coral package http://www.squeaksource.com/Coral.html but mostly it looks like this: parseOn: aStream | result | aStream atEnd ifTrue: [ ^ PPFailure message: 'element expected' at: aStream position ]. result := parser "end" parse: aStream uncheckedPeek. ^ result isPetitFailure ifFalse: [ aStream next. result ] ifTrue: [ PPFailure message: (message ifNil: ['error: ' , result printString , ' in element']) at: aStream position ] What do you think? I'm still not sure what the best way is. I hesitated between subclassing PPDelegateParser, PPLiteralParser⦠maybe a factory method in PPPredicateObjectParser would work as well: -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet