epsilon parser not
Locked
 
|
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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> > 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Moose-dev mailing list > [hidden email] > 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> 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 <[hidden email]> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Moose-dev mailing list > [hidden email] > 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> >> 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Value is always contextual." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
In reply to this post by Tudor Girba
On 8/4/10 5:49 PM, Lukas Renggli wrote:
> 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 ] Thanks to both of you for the suggestions, now the keyword parser (and similarly the separator) is implemented using: keywordParsers := keywords keysSortedSafely collect: [:eachKey | keywords at: eachKey ]. ^ (keywordParsers reduce: [ :a :b | a / b ]) token trimBlanks Since I already have a dictionary "keywords" with each keyword as a key, and the corresponding parser (not tokenized) as a value. Should these parsers be caseInsensitive? I thought keywords are case sensitive. Maybe that was another story? Ciao, Alberto _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba
On Thursday, August 5, 2010, Tudor Girba <[hidden email]> 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 <[hidden email]> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Moose-dev mailing list > [hidden email] > 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > -- > www.tudorgirba.com > > "Value is always contextual." > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Alberto Bacchelli
Hi Alberto,
On 5 Aug 2010, at 09:45, Alberto Bacchelli wrote: > On 8/4/10 5:49 PM, Lukas Renggli wrote: >> 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 ] > > Thanks to both of you for the suggestions, > now the keyword parser (and similarly the separator) > is implemented using: > > keywordParsers := keywords keysSortedSafely > collect: [:eachKey | keywords at: eachKey ]. > > ^ (keywordParsers reduce: [ :a :b | a / b ]) token trimBlanks > > Since I already have a dictionary "keywords" with each keyword > as a key, and the corresponding parser (not tokenized) > as a value. This looks better. > Should these parsers be caseInsensitive? > I thought keywords are case sensitive. > Maybe that was another story? The Java keywords are not caseInsensitive :). I was talking about other situations when you might need that. Cheers, Doru > > Ciao, > Alberto > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Lukas Renggli
Hi Lukas,
On 5 Aug 2010, at 09:48, Lukas Renggli wrote: > On Thursday, August 5, 2010, Tudor Girba <[hidden email]> > 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 <[hidden email]> >> 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> -- >> www.tudorgirba.com >> >> "Value is always contextual." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |