Symbol table

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

Symbol table

Vee Kay
Hello,

Could someone explain why the following code will output 0 instead of
the expected 2?

#include <boost/spirit/include/qi.hpp>
#include <iostream>

using namespace boost::spirit::qi;

struct Foo : symbols<char, int>
{
    Foo(){
        add
                ("Apple", 1)
                ("Banana", 2)
                ("Orange", 3)
                ;
    }
};

Foo foo;

struct Bar : grammar<std::string::iterator, int>{
    rule<std::string::iterator, int> start;

    Bar():base_type(start){
        start = foo;
    }
};

int main()
{  
    std::string s = "Banana";
    int i=0;
    Bar bar;
    bool success = parse(s.begin(), s.end(), bar, i);
    std::cout << std::boolalpha << success << ' ' << i << '\n';
}

Note that if foo itself was passed instead as the grammar to parse(),
then i would hold the correct value. I have succesfully used symbol maps
in more elaborate grammars, yet a problematic one was reduced to this.
Now I am not even sure I understand how it works.

Furthermore, I was wondering if there is a better way to create a symbol
table that will not be added to at runtime - am I paying for something I
don't use? I tried this:

start = (lit("Apple") >> attr(1)) |
                (lit("Banana") >> attr(2)) |
                (lit("Orange") >> attr(3));

However, this also failed to set the correct value to the attribute. Any
insight would be appreciated,

Albert

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

Re: Symbol table

Agustín K-ballo Bergé
On 11/8/2014 9:48 PM, Albert Yiamakis wrote:
> Hello,
>
> Could someone explain why the following code will output 0 instead of
> the expected 2?

[snip]

> struct Bar : grammar<std::string::iterator, int>{

That is supposed to read `int()` to identify a rule with an `int`
attribute and no inherited attributes.

This keeps biting people over and over, and I no longer remember the
reason why this is not enforced at compile time (your `int` is simply
ignored). I'd like to encourage you to file a bug or feature request.

Regards,
--
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com

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

Re: Symbol table

Vee Kay
Ah, of course. And I kept looking at the wrong place convinced the
symbol table was the problem.
Thanks,

Albert

On 09/11/14 04:07, Agustín K-ballo Bergé wrote:

> On 11/8/2014 9:48 PM, Albert Yiamakis wrote:
>> Hello,
>>
>> Could someone explain why the following code will output 0 instead of
>> the expected 2?
> [snip]
>
>> struct Bar : grammar<std::string::iterator, int>{
> That is supposed to read `int()` to identify a rule with an `int`
> attribute and no inherited attributes.
>
> This keeps biting people over and over, and I no longer remember the
> reason why this is not enforced at compile time (your `int` is simply
> ignored). I'd like to encourage you to file a bug or feature request.
>
> Regards,


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

Re: Symbol table

Joel de Guzman
In reply to this post by Agustín K-ballo Bergé
On 11/9/14, 12:07 PM, Agustín K-ballo Bergé wrote:

> On 11/8/2014 9:48 PM, Albert Yiamakis wrote:
>> Hello,
>>
>> Could someone explain why the following code will output 0 instead of
>> the expected 2?
>
> [snip]
>
>> struct Bar : grammar<std::string::iterator, int>{
>
> That is supposed to read `int()` to identify a rule with an `int`
> attribute and no inherited attributes.
>
> This keeps biting people over and over, and I no longer remember the
> reason why this is not enforced at compile time (your `int` is simply
> ignored). I'd like to encourage you to file a bug or feature request.

It's about time we do something about it and I did. It's Sunday, and I
am bored, so I committed a fix that allows plain attributes of the form
T, instead of strictly requiring T().

See: https://github.com/boostorg/spirit/commit/e34a955f2fbbf374870dee3329f89805cd775e6c

Your test code now works without modifications. The fix works for both Qi
and Karma. This adds some more TMP, but heck, the additional metaprogramming
is all worth the trouble.

Good riddance for this long standing bug/feature. All tests pass.

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


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

Major Feature Changes [ was Re: Symbol table ]

Joel de Guzman
Hi Y'all

Many of us here have been bitten by the bug/feature of the rule
requiring a signature of the form T(Arg...) for the inheritted
and synthesized attributes. IN MOST OF the cases (emphasized),
you need only the synthesized attribute. So, we tend to just provide
an attribute without the empty parentheses. But hah! The parentheses
are required and worse, the code silently compiles and gives the
rule a wrong unused_type attribute, just like not having an attribute
at all. This is error prone and quirky and needs to be fixed.

It's about time we do something about it and I did. It's Sunday, and I
am bored, so I committed a fix that allows plain attributes of the form
T, instead of strictly requiring T().

See: https://github.com/boostorg/spirit/commit/e34a955f2fbbf374870dee3329f89805cd775e6c

The fix works for both Qi and Karma. This adds some more TMP, but heck,
the additional metaprogramming is all worth the trouble.

Good riddance for this long standing bug/feature. All tests pass.

PS> Now that I got your attention, I also fixed another long standing
bug with the real number parsers not having enough precision for the
corner cases with the float_ and double_ parsers. That is now fixed.
Extreme cases such as 2.2204460492503131e-16 (DBL_EPSILON),
2.2250738585072014e-308 (DBL_MIN), for double_ and 1.192092896e-07
(FLT_EPSILON), 1.175494351e-38 (FLT_MIN) for float_ are now correctly
parsed with exact precision. Big exponents such as 123e1234000000
and 123e-1234000000 are also now doing the right thing.

PPS> We'll have a version bump in the next release.

--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/




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

Re: Major Feature Changes [ was Re: Symbol table ]

Michael Powell-2


On November 9, 2014 3:32:33 AM CST, Joel de Guzman <[hidden email]> wrote:

>Hi Y'all
>
>Many of us here have been bitten by the bug/feature of the rule
>requiring a signature of the form T(Arg...) for the inheritted
>and synthesized attributes. IN MOST OF the cases (emphasized),
>you need only the synthesized attribute. So, we tend to just provide
>an attribute without the empty parentheses. But hah! The parentheses
>are required and worse, the code silently compiles and gives the
>rule a wrong unused_type attribute, just like not having an attribute
>at all. This is error prone and quirky and needs to be fixed.
>
>It's about time we do something about it and I did.

Not to sound skeptical, but, er, nicely done?

This is in future versions? Especially as delivers with Boost?

Sounds like breaking, albeit welcome, change(s)?

Thank you...

> It's Sunday, and I
>am bored, so I committed a fix that allows plain attributes of the form
>T, instead of strictly requiring T().
>
>See:
>https://github.com/boostorg/spirit/commit/e34a955f2fbbf374870dee3329f89805cd775e6c
>
>The fix works for both Qi and Karma. This adds some more TMP, but heck,
>the additional metaprogramming is all worth the trouble.
>
>Good riddance for this long standing bug/feature. All tests pass.
>
>PS> Now that I got your attention, I also fixed another long standing
>bug with the real number parsers not having enough precision for the
>corner cases with the float_ and double_ parsers. That is now fixed.
>Extreme cases such as 2.2204460492503131e-16 (DBL_EPSILON),
>2.2250738585072014e-308 (DBL_MIN), for double_ and 1.192092896e-07
>(FLT_EPSILON), 1.175494351e-38 (FLT_MIN) for float_ are now correctly
>parsed with exact precision. Big exponents such as 123e1234000000
>and 123e-1234000000 are also now doing the right thing.
>
>PPS> We'll have a version bump in the next release.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: Major Feature Changes [ was Re: Symbol table ]

MM
In reply to this post by Joel de Guzman
On 9 November 2014 09:32, Joel de Guzman <[hidden email]> wrote:
Hi Y'all

Many of us here have been bitten by the bug/feature of the rule
requiring a signature of the form T(Arg...) for the inheritted
and synthesized attributes. IN MOST OF the cases (emphasized),
you need only the synthesized attribute. So, we tend to just provide
an attribute without the empty parentheses. But hah! The parentheses
are required and worse, the code silently compiles and gives the
rule a wrong unused_type attribute, just like not having an attribute
at all. This is error prone and quirky and needs to be fixed.

It's about time we do something about it and I did. It's Sunday, and I
am bored, so I committed a fix that allows plain attributes of the form
T, instead of strictly requiring T().

See: https://github.com/boostorg/spirit/commit/e34a955f2fbbf374870dee3329f89805cd775e6c

The fix works for both Qi and Karma. This adds some more TMP, but heck,
the additional metaprogramming is all worth the trouble.

Good riddance for this long standing bug/feature. All tests pass.

PS> Now that I got your attention, I also fixed another long standing
bug with the real number parsers not having enough precision for the
corner cases with the float_ and double_ parsers. That is now fixed.
Extreme cases such as 2.2204460492503131e-16 (DBL_EPSILON),
2.2250738585072014e-308 (DBL_MIN), for double_ and 1.192092896e-07
(FLT_EPSILON), 1.175494351e-38 (FLT_MIN) for float_ are now correctly
parsed with exact precision. Big exponents such as 123e1234000000
and 123e-1234000000 are also now doing the right thing.

PPS> We'll have a version bump in the next release.

--
Joel de Guzman
 
But will T() still work after this push? 

------------------------------------------------------------------------------

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

Re: Major Feature Changes [ was Re: Symbol table ]

Michael Powell-2
On Sun, Nov 9, 2014 at 10:53 AM, MM <[hidden email]> wrote:

> On 9 November 2014 09:32, Joel de Guzman <[hidden email]> wrote:
>>
>> Hi Y'all
>>
>> Many of us here have been bitten by the bug/feature of the rule
>> requiring a signature of the form T(Arg...) for the inheritted
>> and synthesized attributes. IN MOST OF the cases (emphasized),
>> you need only the synthesized attribute. So, we tend to just provide
>> an attribute without the empty parentheses. But hah! The parentheses
>> are required and worse, the code silently compiles and gives the
>> rule a wrong unused_type attribute, just like not having an attribute
>> at all. This is error prone and quirky and needs to be fixed.
>>
>> It's about time we do something about it and I did. It's Sunday, and I
>> am bored, so I committed a fix that allows plain attributes of the form
>> T, instead of strictly requiring T().
>>
>> See:
>> https://github.com/boostorg/spirit/commit/e34a955f2fbbf374870dee3329f89805cd775e6c
>>
>> The fix works for both Qi and Karma. This adds some more TMP, but heck,
>> the additional metaprogramming is all worth the trouble.
>>
>> Good riddance for this long standing bug/feature. All tests pass.
>>
>> PS> Now that I got your attention, I also fixed another long standing
>> bug with the real number parsers not having enough precision for the
>> corner cases with the float_ and double_ parsers. That is now fixed.
>> Extreme cases such as 2.2204460492503131e-16 (DBL_EPSILON),
>> 2.2250738585072014e-308 (DBL_MIN), for double_ and 1.192092896e-07
>> (FLT_EPSILON), 1.175494351e-38 (FLT_MIN) for float_ are now correctly
>> parsed with exact precision. Big exponents such as 123e1234000000
>> and 123e-1234000000 are also now doing the right thing.
>>
>> PPS> We'll have a version bump in the next release.
>>
>> --
>> Joel de Guzman
>>
>
> But will T() still work after this push?

I could be wrong, but this sounded like a breaking change.

> ------------------------------------------------------------------------------
>
> _______________________________________________
> Spirit-general mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/spirit-general
>

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

Re: Major Feature Changes [ was Re: Symbol table ]

llonesmiz
Michael Powell-2 wrote
On Sun, Nov 9, 2014 at 10:53 AM, MM <[hidden email]> wrote:
> On 9 November 2014 09:32, Joel de Guzman <[hidden email]> wrote:
...
>> It's about time we do something about it and I did. It's Sunday, and I
>> am bored, so I committed a fix that allows plain attributes of the form
>> T, instead of strictly requiring T().
>>
>> See:
>> https://github.com/boostorg/spirit/commit/e34a955f2fbbf374870dee3329f89805cd775e6c
>>
...
>> --
>> Joel de Guzman
>>
>
> But will T() still work after this push?

I could be wrong, but this sounded like a breaking change.
If I understand the code correctly if you use "T" the metafunction adds the "()" and passes "T()" forward, and if you use "T()" nothing is changed and "T()" is passed forward. Note the "allows" and "strictly requiring" in Joel de Guzman's original message.
Reply | Threaded
Open this post in threaded view
|

Re: Symbol table

sehe
In reply to this post by Joel de Guzman
On 09-11-14 10:18, Joel de Guzman wrote:
> Good riddance for this long standing bug/feature. All tests pass.
FWIW I think the consistency made it a feature.

But yeah, if a diagnostic on "spurious template arguments" was not
feasible, then this is the next best thing !

Thanks,
Seth

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

Re: Major Feature Changes [ was Re: Symbol table ]

sehe
In reply to this post by Joel de Guzman
On 09-11-14 10:32, Joel de Guzman wrote:
> PS> Now that I got your attention, I also fixed another long standing
> bug with the real number parsers not having enough precision for the
> corner cases with the float_ and double_ parsers. That is now fixed.
> Extreme cases such as 2.2204460492503131e-16 (DBL_EPSILON),
> 2.2250738585072014e-308 (DBL_MIN), for double_ and 1.192092896e-07
> (FLT_EPSILON), 1.175494351e-38 (FLT_MIN) for float_ are now correctly
> parsed with exact precision. Big exponents such as 123e1234000000
> and 123e-1234000000 are also now doing the right thing.
Awesome! Leaving notes on SO too (e.g.
http://stackoverflow.com/questions/17391348/boost-spirit-floating-number-parser-precision
which was also discussed here)


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

Re: Major Feature Changes [ was Re: Symbol table ]

Joel de Guzman
In reply to this post by llonesmiz
On 11/10/14, 3:32 AM, llonesmiz wrote:

> Michael Powell-2 wrote
>> On Sun, Nov 9, 2014 at 10:53 AM, MM &lt;
>
>> finjulhich@
>
>> &gt; wrote:
>>> On 9 November 2014 09:32, Joel de Guzman &lt;
>
>> djowel@
>
>> &gt; wrote:
>> ...
>>>> It's about time we do something about it and I did. It's Sunday, and I
>>>> am bored, so I committed a fix that allows plain attributes of the form
>>>> T, instead of strictly requiring T().
>>>>
>>>> See:
>>>> https://github.com/boostorg/spirit/commit/e34a955f2fbbf374870dee3329f89805cd775e6c
>>>>
>> ...
>>>> --
>>>> Joel de Guzman
>>>>
>>>
>>> But will T() still work after this push?
>>
>> I could be wrong, but this sounded like a breaking change.
>
> If I understand the code correctly if you use "T" the metafunction adds the
> "()" and passes "T()" forward, and if you use "T()" nothing is changed and
> "T()" is passed forward. Note the "allows" and "strictly requiring" in Joel
> de Guzman's original message.

Yes, no breaking change here. Both T and T() will work. It will be a nightmare
if Spirit starts to break T()! I will not allow that to happen. All our tests
work as-is (no changes to the tests).

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


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

Re: Major Feature Changes [ was Re: Symbol table ]

Joel de Guzman
In reply to this post by MM
On 11/10/14, 12:53 AM, MM wrote:

> On 9 November 2014 09:32, Joel de Guzman <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi Y'all
>
>     Many of us here have been bitten by the bug/feature of the rule
>     requiring a signature of the form T(Arg...) for the inheritted
>     and synthesized attributes. IN MOST OF the cases (emphasized),
>     you need only the synthesized attribute. So, we tend to just provide
>     an attribute without the empty parentheses. But hah! The parentheses
>     are required and worse, the code silently compiles and gives the
>     rule a wrong unused_type attribute, just like not having an attribute
>     at all. This is error prone and quirky and needs to be fixed.
>
>     It's about time we do something about it and I did. It's Sunday, and I
>     am bored, so I committed a fix that allows plain attributes of the form
>     T, instead of strictly requiring T().
>
>     See: https://github.com/boostorg/spirit/commit/e34a955f2fbbf374870dee3329f89805cd775e6c
>
>     The fix works for both Qi and Karma. This adds some more TMP, but heck,
>     the additional metaprogramming is all worth the trouble.
>
>     Good riddance for this long standing bug/feature. All tests pass.
>
>     PS> Now that I got your attention, I also fixed another long standing
>     bug with the real number parsers not having enough precision for the
>     corner cases with the float_ and double_ parsers. That is now fixed.
>     Extreme cases such as 2.2204460492503131e-16 (DBL_EPSILON),
>     2.2250738585072014e-308 (DBL_MIN), for double_ and 1.192092896e-07
>     (FLT_EPSILON), 1.175494351e-38 (FLT_MIN) for float_ are now correctly
>     parsed with exact precision. Big exponents such as 123e1234000000
>     and 123e-1234000000 are also now doing the right thing.
>
>     PPS> We'll have a version bump in the next release.
>
>     --
>     Joel de Guzman
>
> But will T() still work after this push?

Yes of course T() will work as usual.

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


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

Major Feature Changes [ was Re: Symbol table ]

Joel de Guzman
In reply to this post by sehe
On 11/10/14, 6:59 AM, Seth Heeren wrote:
> On 09-11-14 10:18, Joel de Guzman wrote:
>> Good riddance for this long standing bug/feature. All tests pass.
> FWIW I think the consistency made it a feature.
>
> But yeah, if a diagnostic on "spurious template arguments" was not
> feasible, then this is the next best thing !

Actually, making it an error is possible. However, 1) I thought
it will be a good introduction to X3 which should allow naked T
attributes and 2) It follows the intent of the user intuitively.

That said, I can change it and make it an error instead, if that
will be the consensus here.

So... What do y'all want? Do you want this:

     rule<Iter, T> r;

to be an error (static assert)? Or do you want it to be equivalent to
this:

     rule<Iter, T()> r;

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


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

Re: Major Feature Changes [ was Re: Symbol table ]

Richard-45

In article <m3osr4$73l$[hidden email]>,
    Joel de Guzman <[hidden email]> writes:

> to be an error (static assert)? Or do you want it to be equivalent to
> this:
>
>      rule<Iter, T()> r;

+1 for T implying T().
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

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

Re: Major Feature Changes [ was Re: Symbol table ]

Joel de Guzman
In reply to this post by sehe
On 11/10/14, 7:05 AM, Seth Heeren wrote:
> On 09-11-14 10:32, Joel de Guzman wrote:
>> PS> Now that I got your attention, I also fixed another long standing
>> bug with the real number parsers not having enough precision for the
>> corner cases with the float_ and double_ parsers. That is now fixed.
>> Extreme cases such as 2.2204460492503131e-16 (DBL_EPSILON),
>> 2.2250738585072014e-308 (DBL_MIN), for double_ and 1.192092896e-07
>> (FLT_EPSILON), 1.175494351e-38 (FLT_MIN) for float_ are now correctly
>> parsed with exact precision. Big exponents such as 123e1234000000
>> and 123e-1234000000 are also now doing the right thing.

> Awesome! Leaving notes on SO too (e.g.
> http://stackoverflow.com/questions/17391348/boost-spirit-floating-number-parser-precision
> which was also discussed here)

Yes, this is one of the test cases now:

   BOOST_TEST(test_attr("219721.03839999999", float_, f));
   BOOST_TEST(f == 219721.03839999999f); // inexact

It's as good as the float precision can go.

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


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

Re: Major Feature Changes [ was Re: Symbol table ]

Jeroen Habraken
In reply to this post by Joel de Guzman
Hi,

On 9 November 2014 15:20, Joel de Guzman <[hidden email]> wrote:
On 11/10/14, 6:59 AM, Seth Heeren wrote:
> On 09-11-14 10:18, Joel de Guzman wrote:
>> Good riddance for this long standing bug/feature. All tests pass.
> FWIW I think the consistency made it a feature.
>
> But yeah, if a diagnostic on "spurious template arguments" was not
> feasible, then this is the next best thing !

Actually, making it an error is possible. However, 1) I thought
it will be a good introduction to X3 which should allow naked T
attributes and 2) It follows the intent of the user intuitively.

That said, I can change it and make it an error instead, if that
will be the consensus here.

So... What do y'all want? Do you want this:

     rule<Iter, T> r;

to be an error (static assert)? Or do you want it to be equivalent to
this:

     rule<Iter, T()> r;

Let me start by saying that whatever option we choose, it'll be a huge improvement compared to the old situation! My personal preference is with rule<Iter, T> implying rule<Iter, T()> for several reasons:

- All other parameters are optional as well, if you don't need a skipper or locals you're not forced to specify unused_type or locals<> respectively,
- I can't think of any other interpretations that the user could have meant, thus it's more pragmatic to interpret it this way than to error, especially since it's a common mistake,
- rule<Iter, T> is more visually appealing, though that's arguably a matter of taste.

Jeroen

------------------------------------------------------------------------------

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

Re: Major Feature Changes [ was Re: Symbol table ]

Michael Caisse-3
In reply to this post by Joel de Guzman
On 11/09/2014 03:20 PM, Joel de Guzman wrote:

> On 11/10/14, 6:59 AM, Seth Heeren wrote:
>> On 09-11-14 10:18, Joel de Guzman wrote:
>>> Good riddance for this long standing bug/feature. All tests pass.
>> FWIW I think the consistency made it a feature.
>>
>> But yeah, if a diagnostic on "spurious template arguments" was not
>> feasible, then this is the next best thing !
>
> Actually, making it an error is possible. However, 1) I thought
> it will be a good introduction to X3 which should allow naked T
> attributes and 2) It follows the intent of the user intuitively.
>
> That said, I can change it and make it an error instead, if that
> will be the consensus here.
>
> So... What do y'all want? Do you want this:
>
>      rule<Iter, T> r;
>
> to be an error (static assert)? Or do you want it to be equivalent to
> this:
>
>      rule<Iter, T()> r;
>
> Regards,
>


I lean toward T is a detected error. Here are a couple reasons:

1. With C++11 lambdas:

     [](){ ... }
     []{ ... }

   are equivalent. I strongly think this was a mistake from
   the point of view of making the language easier to teach/learn.
   Adding more options to say the same thing doesn't make it easier
   to learn.

   T() explicitly says that the rule will synthesize a T but has
   no inherited attributes.

2. A parser rule in Spirit 2 is:

   template <typename Iter, typename A1, typename A2, typename A3>
   struct rule;

   where A1, A2, and A3 are the Signature, Skipper, and Locals.
   They can be specified in any order. That is cute, except as a reader
   it can become confusing. From a code writer/reviewer point-of-view
   I'm looking for the function declarator syntax to key me into the
   rule's Signature. When I don't see, there is often a red flag raised.


   I find:

       rule<iter, T> my_rule;

       vs.

       rule<iter, T()> my_rule

   requires that I need to spend more time understanding what T is.


So, imho, +1 for it to be a static_assert.

michael

--
Michael Caisse
ciere consulting
ciere.com

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

Re: Major Feature Changes [ was Re: Symbol table ]

Michael Powell-2
In reply to this post by Joel de Guzman
On Sun, Nov 9, 2014 at 5:20 PM, Joel de Guzman <[hidden email]> wrote:

> On 11/10/14, 6:59 AM, Seth Heeren wrote:
>> On 09-11-14 10:18, Joel de Guzman wrote:
>>> Good riddance for this long standing bug/feature. All tests pass.
>> FWIW I think the consistency made it a feature.
>>
>> But yeah, if a diagnostic on "spurious template arguments" was not
>> feasible, then this is the next best thing !
>
> Actually, making it an error is possible. However, 1) I thought
> it will be a good introduction to X3 which should allow naked T
> attributes and 2) It follows the intent of the user intuitively.
>
> That said, I can change it and make it an error instead, if that
> will be the consensus here.
>
> So... What do y'all want? Do you want this:
>
>      rule<Iter, T> r;
>
> to be an error (static assert)? Or do you want it to be equivalent to
> this:
>
>      rule<Iter, T()> r;

Don't get me wrong, I'm not attached to the syntax either way.

Up to you. If T will help performance issues, that's great. Or if
needs be to support either and/or both, that's great too.

Do what's best for the performance of the library, compile and/or run-times.

I was just curious was it a breaking change or not.

Thanks...

> Regards,
> --
> Joel de Guzman
> http://www.ciere.com
> http://boost-spirit.com
> http://www.cycfi.com/
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Spirit-general mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/spirit-general

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

Re: Major Feature Changes [ was Re: Symbol table ]

Agustín K-ballo Bergé
In reply to this post by Jeroen Habraken
On 11/9/2014 5:49 PM, Jeroen Habraken wrote:

> On 9 November 2014 15:20, Joel de Guzman <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     So... What do y'all want? Do you want this:
>
>           rule<Iter, T> r;
>
>     to be an error (static assert)? Or do you want it to be equivalent to
>     this:
>
>           rule<Iter, T()> r;
>
> Let me start by saying that whatever option we choose, it'll be a huge
> improvement compared to the old situation! My personal preference is
> with rule<Iter, T> implying rule<Iter, T()> for several reasons:
>
> - All other parameters are optional as well, if you don't need a skipper
> or locals you're not forced to specify unused_type or locals<> respectively,
> - I can't think of any other interpretations that the user could have
> meant, thus it's more pragmatic to interpret it this way than to error,
> especially since it's a common mistake,
> - rule<Iter, T> is more visually appealing, though that's arguably a
> matter of taste.
>
> Jeroen

+1

Regards,
--
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com


------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
12