> 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
