Re: PetitParser

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: PetitParser

Lukas Renggli
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

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: PetitParser

Damien Cassou
On Tue, Jul 12, 2011 at 8:51 AM, Lukas Renggli <[hidden email]> 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

?


--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: PetitParser

Lukas Renggli
>>> - 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

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: PetitParser

Damien Cassou
On Tue, Jul 12, 2011 at 10:46 AM, Lukas Renggli <[hidden email]> 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
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: PetitParser

Lukas Renggli
Yes, use PPDelegateParser and #setParser: instead.

Lukas

On Saturday, 16 July 2011, Damien Cassou <[hidden email]> wrote:

> On Tue, Jul 12, 2011 at 10:46 AM, Lukas Renggli <[hidden email]> 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
>

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev