Hi,
On 4 Aug 2010, at 17:49, Lukas Renggli wrote:
I think this parser is called PPFailingParser. It is
useful to
generate custom error messages. It always fails without consuming
anything.
Aha, indeed.
However for the given example I would use
keywords reduce: [ :a :b | a asParser / b asParser ]
I tried this one, but the problem is that caseInsensitive is not
understood by all parser (and in particular by PPChoiceParser), so I
cannot write:
keywords reduce: [ :a :b | a asParser caseInsensitive / b asParser
caseInsensitive ]
In this case, inject:into: can be a choice, but indeed with the
current implementation we get one parser too many in the choice. Now
the question is if it would not make sense to implement:
PPFailingParser>>/ aParser
^ aParser
?
Like this you can inject it in a collection without creating an extra
parser at the beginning. In the same spirit, we could also implement
PPEpsilonParser>>, in a similar way.
Is there an argument against that?
Cheers,
Doru
for a shorter and more performant implementation.
Lukas
On Wednesday, August 4, 2010, Tudor Girba <tudor.girba(a)gmail.com>
wrote:
Hi,
I went quickly through the PetitJava implementation and I stumbled
across the keywords implementation. I would propose a simpler
solution:
keyword
^ (arrayOfKeywords inject: PPEpsilonParser new not into:
[:p :key | p / key asParser ]) token trimBlanks .
Now the question is if it makes sense to have a separate parser
class equivalent to PPEpsilonParser new not. If yes, what would a
good name be?
Cheers,
Doru
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."