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."
I think this parser is called PPFailingParser. It is useful to generate custom error messages. It always fails without consuming anything.
However for the given example I would use
keywords reduce: [ :a :b | a asParser / b asParser ]
for a shorter and more performant implementation.
Lukas
On Wednesday, August 4, 2010, Tudor Girba tudor.girba@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@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."
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 ]
Aha, i missed that part. What about
(keywords collect: [ :k | k asParser caseInsensitive ]) reduce: #/
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
That's a bit ugly :-)
Lukas
?
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@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."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On 5 Aug 2010, at 08:24, Lukas Renggli wrote:
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 ]
Aha, i missed that part. What about
(keywords collect: [ :k | k asParser caseInsensitive ]) reduce: #/
Yes, that would work.
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
That's a bit ugly :-)
Why? Is it because you want to preserve the structure of parsers? I would just like to have the equivalent of 0 for addition and 1 for multiplication. Perhaps we can introduce another Parser class, but still I think it would make sense.
Cheers, Doru
Lukas
?
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@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."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Value is always contextual."
On Thursday, August 5, 2010, Tudor Girba tudor.girba@gmail.com wrote:
Hi,
On 5 Aug 2010, at 08:24, Lukas Renggli wrote:
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 ]
Aha, i missed that part. What about
(keywords collect: [ :k | k asParser caseInsensitive ]) reduce: #/
Yes, that would work.
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
That's a bit ugly :-)
Why? Is it because you want to preserve the structure of parsers? I would just like to have the equivalent of 0 for addition and 1 for multiplication. Perhaps we can introduce another Parser class, but still I think it would make sense.
Because it mixes optimization magic and building (which unfortunately is already done to some extent). Either way, I think adding the new selector is better than adding a new parser class.
I would avoid adding new parser classes, unless there is a real covenience/performance benefit. In this case it is fairly easy to build a correct and efficient grammar though.
Lukas
Cheers, Doru
Lukas
?
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@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."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Value is always contextual."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Lukas,
On 5 Aug 2010, at 09:48, Lukas Renggli wrote:
On Thursday, August 5, 2010, Tudor Girba tudor.girba@gmail.com wrote:
Hi,
On 5 Aug 2010, at 08:24, Lukas Renggli wrote:
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 ]
Aha, i missed that part. What about
(keywords collect: [ :k | k asParser caseInsensitive ]) reduce: #/
Yes, that would work.
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
That's a bit ugly :-)
Why? Is it because you want to preserve the structure of parsers? I would just like to have the equivalent of 0 for addition and 1 for multiplication. Perhaps we can introduce another Parser class, but still I think it would make sense.
Because it mixes optimization magic and building (which unfortunately is already done to some extent). Either way, I think adding the new selector is better than adding a new parser class.
I agree that you do not want to have too much magic. That is why I raised it as a point :).
I would avoid adding new parser classes, unless there is a real covenience/performance benefit. In this case it is fairly easy to build a correct and efficient grammar though.
I agree. Then I will add this new selectors.
Cheers, Doru
Lukas
Cheers, Doru
Lukas
?
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@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."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Value is always contextual."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow."
-
Lukas Renggli -
Tudor Girba