Hi Damien,
I reply to the Moose list because this might be interesting to other people too.
I have some question/remarks about PetitParser:
- it is not clear what PPParser>match* are used for. After reading the
source code of the implementors, it looks like you want to know if two parsers are equal. Why would you do that? Why are the methods called match* and not equal*?
I guess you are referring to the extension methods in the package 'PetitAnalyzer'? The methods #matches:, #matchesIn:. #matchingRangesIn:, ... are part of the core package 'PetitParser' and are well commented (I think).
The methods in the package 'PetitAnalyzer' are called match*, because this is not an equality operation. They do not only support the comparison of two parsers, but can also compare patterns with parser instances (essentially this is a little Prolog engine, very similar to the refactoring engine). The matching and rewriting of parsers is explained in my PhD (http://scg.unibe.ch/archive/phd/renggli-phd.pdf) in Section "6.2.5 Declarative Grammar Rewriting".
For example:
" matches a sequence of any two parsers that are the same " any := PPPattern any. pattern := any , any.
pattern asParser match: $a asParser , $b inContext: Dictionary new. " --> false, because $a and $b are different "
pattern asParser match: $a asParser , $a asParser inContext: Dictionary new. " --> true, because $a and $a are the same "
If the match is successful, the patterns are bound to the matching parsers. In the example above the dictionary would contain an entry:
any -> $a asParser
There are many tests in PPSearcherTest. Fancy patterns you can also see in PPRewriterTest and PPOptimizer.
- PPParser>>matchList* do never refer to self (but to call themselves
recursively).
This looks correct to me. This is to recurse into the graph of parsers.
- Why is #def: not defined in PPUnresolvedParser? You implemented it
in PPParser. It might be useful for other parsers, but do you have an example?
PPParser is a superclass of PPUnresolvedParser, therefore you can send #def: to any instance of PPUnresolvedParser.
PPUnresolvedParser and #def: are nice to quickly hack something ugly together, better not (over)use them ...
Lukas
On Tue, Jul 12, 2011 at 8:51 AM, Lukas Renggli renggli@gmail.com wrote:
I guess you are referring to the extension methods in the package 'PetitAnalyzer'? The methods #matches:, #matchesIn:. #matchingRangesIn:, ... are part of the core package 'PetitParser' and are well commented (I think).
The methods in the package 'PetitAnalyzer' are called match*, because this is not an equality operation. They do not only support the comparison of two parsers, but can also compare patterns with parser instances (essentially this is a little Prolog engine, very similar to the refactoring engine). The matching and rewriting of parsers is explained in my PhD (http://scg.unibe.ch/archive/phd/renggli-phd.pdf) in Section "6.2.5 Declarative Grammar Rewriting".
I will have a look, thank you
- PPParser>>matchList* do never refer to self (but to call themselves
recursively).
This looks correct to me. This is to recurse into the graph of parsers.
Because these methods do not refer to self, they could be implemented in a different class to avoid cluttering the already large PPParser. I think Kent Beck is talking about that in the Best Practice Patterns :-)
- Why is #def: not defined in PPUnresolvedParser? You implemented it
in PPParser. It might be useful for other parsers, but do you have an example?
PPParser is a superclass of PPUnresolvedParser, therefore you can send #def: to any instance of PPUnresolvedParser.
Sure. But why did you put #def: in PPParser and not directly in PPUnresolvedParser? For example, what is the meaning of
#digit asParser star def: #letter asParser
?
- PPParser>>matchList* do never refer to self (but to call themselves
recursively).
This looks correct to me. This is to recurse into the graph of parsers.
Because these methods do not refer to self, they could be implemented in a different class to avoid cluttering the already large PPParser. I think Kent Beck is talking about that in the Best Practice Patterns :-)
Yes, but I prefer to have things that work together at the same place.
- Why is #def: not defined in PPUnresolvedParser? You implemented it
in PPParser. It might be useful for other parsers, but do you have an example?
PPParser is a superclass of PPUnresolvedParser, therefore you can send #def: to any instance of PPUnresolvedParser.
Sure. But why did you put #def: in PPParser and not directly in PPUnresolvedParser?
It makes sense on other parsers too.
I would like to get rid of #def: and PPUnresolvedParser. Do not use them.
For example, what is the meaning of
#digit asParser star def: #letter asParser
?
PPUnresolvedParser new def: #letter asParser
has no meaning in the same way your example has no meaning. #def: only makes sense on a parser instances that are referred to elsewhere (look at the examples in the tests). Again, there are better ways to do the same without using the H-bomb of Smalltalk (#def: is a #become:). It made sense in the beginning of PetitParser, but it is not longer much useful today.
Lukas
On Tue, Jul 12, 2011 at 10:46 AM, Lukas Renggli renggli@gmail.com wrote:
Again, there are better ways to do the same without using the H-bomb of Smalltalk (#def: is a #become:). It made sense in the beginning of PetitParser, but it is not longer much useful today.
Is it possible to follow http://www.lukas-renggli.ch/blog/petitparser-1#176701716 without using PPUnresolvedParser?
Yes, use PPDelegateParser and #setParser: instead.
Lukas
On Saturday, 16 July 2011, Damien Cassou damien.cassou@gmail.com wrote:
On Tue, Jul 12, 2011 at 10:46 AM, Lukas Renggli renggli@gmail.com wrote:
Again, there are better ways to do the same without using the H-bomb of Smalltalk (#def: is a #become:). It made sense in the beginning of PetitParser, but it is not longer much useful today.
Is it possible to follow http://www.lukas-renggli.ch/blog/petitparser-1#176701716 without using PPUnresolvedParser?
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
-
Damien Cassou -
Lukas Renggli