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".
Thank you, this is a great change.
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:
Do you have a ready made-image somewhere? I don't understand it from reading your mail only. Lukas -- Lukas Renggli www.lukas-renggli.ch