compare of 2 existing methods to implement grammar recursion

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

compare of 2 existing methods to implement grammar recursion

cppljevans
The repository:
   https://github.com/boostorg/spirit/tree/develop
has toy.cpp here:
   */workbench/x3/toy/toy.cpp
which connects the rule with it's rule_definition using
the context; however, it's not clear from the code how
to connect multiple rule's withe their rule_definition's.

In contrast:

   */include/boost/spirit/home/x3/nonterminal/rule.hpp

uses the BOOST_SPIRIT_DEFINE macro to do this, as illustrated by:

   */example/x3/calc/calc1.cpp

The gist:

   https://gist.github.com/cppljevans/3634cc4e8ad4da81531608e6aa847de5

shows both methods except, in contrast to toy.cpp, it uses
make_defns to link multiple rule's with their definitions.

Also, the gist uses a macro, USE_PARSE_RULE, to switch between the
2 methods to ease comparison.  It also has *plenty* of debug
prints to help clarify how it works.

It helped me understand the x3 design a bit better and
hopefully the above gist will help others do the same.

HTH.

-regards,
Larry



------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: compare of 2 existing methods to implement grammar recursion

cppljevans
On 07/29/2016 10:31 AM, Larry Evans wrote:

> The repository:
>    https://github.com/boostorg/spirit/tree/develop
> has toy.cpp here:
>    */workbench/x3/toy/toy.cpp
> which connects the rule with it's rule_definition using
> the context; however, it's not clear from the code how
> to connect multiple rule's withe their rule_definition's.
>
> In contrast:
>
>    */include/boost/spirit/home/x3/nonterminal/rule.hpp
>
> uses the BOOST_SPIRIT_DEFINE macro to do this, as illustrated by:
>
>    */example/x3/calc/calc1.cpp
>
> The gist:
>
>    https://gist.github.com/cppljevans/3634cc4e8ad4da81531608e6aa847de5
>
> shows both methods except, in contrast to toy.cpp, it uses
> make_defns to link multiple rule's with their definitions.
>
> Also, the gist uses a macro, USE_PARSE_RULE, to switch between the
> 2 methods to ease comparison.

OOPS.  Apparently the 2 methods of linking a rule with it's
rule_definition can be used together.  The decision about which
to use is done by the BOOST_SPIRIT_DEFINE; hence, the above
rationale for USE_PARSE_RULE is not valid :(

Hence, replaced the USE_PARSE_RULE macro with USE_SPIRIT_DEFINE macro.
Comments under the macros should clarify their purpose.

Also, added the USE_MIXED_DEF to decide whether to use both
BOOST_SPIRIT_DEFINE *and* rule_defns to connect the rule's with
their rule_definition's.  The example output shows where
BOOST_SPIRIT_DEFINE was used to link expr and fact with their
rule_definition's, but where rule_defns was used to link
term with it's rule_definition.
[snip]



------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: compare of 2 existing methods to implement grammar recursion

cppljevans
On 07/30/2016 01:47 PM, Larry Evans wrote:

> On 07/29/2016 10:31 AM, Larry Evans wrote:
>> The repository:
>>    https://github.com/boostorg/spirit/tree/develop
>> has toy.cpp here:
>>    */workbench/x3/toy/toy.cpp
>> which connects the rule with it's rule_definition using
>> the context; however, it's not clear from the code how
>> to connect multiple rule's withe their rule_definition's.
>>
>> In contrast:
>>
>>    */include/boost/spirit/home/x3/nonterminal/rule.hpp
>>
>> uses the BOOST_SPIRIT_DEFINE macro to do this, as illustrated by:
>>
>>    */example/x3/calc/calc1.cpp
>>
>> The gist:
>>
>>    https://gist.github.com/cppljevans/3634cc4e8ad4da81531608e6aa847de5
>>
>> shows both methods except, in contrast to toy.cpp, it uses
>> make_defns to link multiple rule's with their definitions.

OOPS, apparently the idea of make_defns (which makes a mapping
from the rule to it's definition) had already been tried here:

https://gist.github.com/jamboree/11133291

where it's called rule_map.

However, the file given in that gist:

boost/spirit/home/x3/nonterminal/grammar.hpp

is not present here:

https://github.com/djowel/spirit_x3/tree/master/include/boost/spirit/home/x3/nonterminal

The history for this directory:

https://github.com/djowel/spirit_x3/commits/master/include/boost/spirit/home/x3/nonterminal

mentions nothing about grammar.hpp.

Would someone explain why this idea was not used?

-regards,
Larry



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: compare of 2 existing methods to implement grammar recursion

TONGARI J
2016-08-09 23:09 GMT+08:00 Larry Evans <[hidden email]>:
OOPS, apparently the idea of make_defns (which makes a mapping
from the rule to it's definition) had already been tried here:

https://gist.github.com/jamboree/11133291

where it's called rule_map.

However, the file given in that gist:

boost/spirit/home/x3/nonterminal/grammar.hpp

is not present here:

https://github.com/djowel/spirit_x3/tree/master/include/boost/spirit/home/x3/nonterminal

The history for this directory:

https://github.com/djowel/spirit_x3/commits/master/include/boost/spirit/home/x3/nonterminal

mentions nothing about grammar.hpp.

Would someone explain why this idea was not used?

It was once used and finally replaced with what you see today. I can't recall the detail, but I remember that someone wrote a monster-sized grammar in one file and got some problem in compilation, for example, such a method will drive the linker very hard (especially in debug build) because it will result in crazy long mangled names for symbols, though some efforts were put into reducing the symbol size but the effects were not significant.

Before long, the ADL trick was invented and evolves to what you see today.

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: compare of 2 existing methods to implement grammar recursion

cppljevans
On 08/10/2016 08:36 AM, TONGARI J wrote:

> 2016-08-09 23:09 GMT+08:00 Larry Evans <[hidden email]
> <mailto:[hidden email]>>:
>
>     OOPS, apparently the idea of make_defns (which makes a mapping
>     from the rule to it's definition) had already been tried here:
>
>     https://gist.github.com/jamboree/11133291
>     <https://gist.github.com/jamboree/11133291>
>
>     where it's called rule_map.
>
>     However, the file given in that gist:
>
>     boost/spirit/home/x3/nonterminal/grammar.hpp
>
>     is not present here:
>
>     https://github.com/djowel/spirit_x3/tree/master/include/boost/spirit/home/x3/nonterminal
>     <https://github.com/djowel/spirit_x3/tree/master/include/boost/spirit/home/x3/nonterminal>
>
>     The history for this directory:
>
>     https://github.com/djowel/spirit_x3/commits/master/include/boost/spirit/home/x3/nonterminal
>     <https://github.com/djowel/spirit_x3/commits/master/include/boost/spirit/home/x3/nonterminal>
>
>     mentions nothing about grammar.hpp.
>
>     Would someone explain why this idea was not used?
>
>
> It was once used and finally replaced with what you see today. I can't
> recall the detail, but I remember that someone wrote a monster-sized
> grammar in one file and got some problem in compilation, for example,
> such a method will drive the linker very hard (especially in debug
> build) because it will result in crazy long mangled names for symbols,
> though some efforts were put into reducing the symbol size but the
> effects were not significant.

Ah!  That's what I suspected, as indicated by the comments starting here:

https://gist.github.com/cppljevans/3634cc4e8ad4da81531608e6aa847de5#file-rule_defns-cpp-L36

However, the default parse_rule code here:

https://github.com/djowel/spirit_x3/blob/master/include/boost/spirit/home/x3/nonterminal/rule.hpp#L34

still checks for a rule definition in the context argument.
If this method of implementing recursion by looking in the context is
no longer implemented, why is there still an attempt to find some sort
or rule_defintion in the context in this default parse_rule code?
I would think it should just fire the static_assert.

>
> Before long, the ADL trick was invented and evolves to what you see today.
>
>



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general