The Spirit Parser Library

Joel de Guzman <joel@...> writes:

> Hi,
>
> Hi. Here's a preview of Phoenix V2. This will probably be the last
> release of the library. Phoenix V2 will be the basis of the Phoenix
> and Boost.Lambda merger.


    val(3)
    val("Hello, World")

  The first evaluates to a nullary function (a function taking no
  arguments) that returns an int, 3. The second evaluates to a nullary
  function that returns a char const*, "Hello, World".

Really?  I'd have expected a char const(&)[13].  No?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

David Abrahams wrote:
> Joel de Guzman <joel@...> writes:
> 
> 
>>Hi. Here's a preview of Phoenix V2. This will probably be the last
>>release of the library. Phoenix V2 will be the basis of the Phoenix
>>and Boost.Lambda merger.
> 
> 
> 
>   If these basic rules are not followed, the result is either in
>   error, or is immediately evaluated. Some examples:
> 
>     var(x) = 123 // good (lazy)
>     x = 123 // oops (immediate)
>     var(x)[0] // good (lazy)
>     x[0] // oops (immediate)
>     var(x)[var(i)] // good (lazy)
>     x[var(i)] // bad and illegal (x is not a phoenix primitive or composite)
>     var(x[var(i)]) // bad and illegal (x is not a phoenix primitive or composite)
> 
> I would avoid attaching value judgements, and in this case,
> vertically align the comments:
> 
>     x = 123          // immediate
>     var(x) = 123     // lazy
> 
>     x[0]             // immediate
>     var(x)[0]        // lazy
> 
>     var(x)[var(i)]   // lazy
>     x[var(i)]        // illegal (x is not a phoenix primitive or composite)
>     var(x[var(i)])   // illegal (x is not a phoenix primitive or composite)

Done. Thanks!

> And this leaves me wondering what about:
> 
>     var(x)[i]

Lazy. Equivalent to:

     var(x)[val(i)]

Added to the examples.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

David Abrahams wrote:
> Joel de Guzman <joel@...> writes:
> 
> 
>>Hi,
>>
>>Hi. Here's a preview of Phoenix V2. This will probably be the last
>>release of the library. Phoenix V2 will be the basis of the Phoenix
>>and Boost.Lambda merger.
> 
> 
> 
>     val(3)
>     val("Hello, World")
> 
>   The first evaluates to a nullary function (a function taking no
>   arguments) that returns an int, 3. The second evaluates to a nullary
>   function that returns a char const*, "Hello, World".
> 
> Really?  I'd have expected a char const(&)[13].  No?

You are right of course. My bad! Fixed.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

Zhuo Qiang wrote:
> I've just tried it and there's a question:
> 
>  int i = 1;
> 
>  let(_a = _1)
>  [
>   cout << --_a << ' '
>  ](i);
>  cout << i << endl;
> 
> the output of above is : 0 0
> and I expected it to be "0 1"
> seems _a hold a "reference" to _1 which in turn is just a reference of i.Is 
> it right?
> I thought _a = _1 had some value semantic.


That's right. That's the correct behavior. As noted in the docs:

The type of the local variable assumes the type of the
lambda-expression. Type deduction is reference preserving.
For example:

let(_a = arg1, _b = 456)

_a assumes the type of arg1: a reference to an argument,
while _b has type int.

This is necessary because otherwise, we won't have l-value
access to outer lambda-scopes.

> though the following code gives what I expect:
>  int i = 1;
> 
>  let(_a = val(_1))
>  [
>   cout << --_a << ' '
>  ](i);
>  cout << i << endl;

Exactly! args are L-values. vals are R-values.

I'll emphasize that in the docs. Mind if I steal your example?

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

Joel <joel@...> writes:

In my original posting, there were blank lines

>> I would avoid attaching value judgements, and in this case,
>> vertically align the comments:
-------------here------------------
>>     x = 123          // immediate
>>     var(x) = 123     // lazy
-------------here------------------
>>     x[0]             // immediate
>>     var(x)[0]        // lazy
-------------and here------------------
>>     var(x)[var(i)]   // lazy
>>     x[var(i)]        // illegal (x is not a phoenix primitive or composite)
>>     var(x[var(i)])   // illegal (x is not a phoenix primitive or composite)
>
> Done. Thanks!

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Zhuo Qiang wrote:
> 
> what about _a = var(arg1) which IMO is more explicit

I considered that syntax too. Unecessarily verbose, IMO.
The argN (like var(x)) already has reference semantics.
That is why you can write:

     ++arg1

for example, instead of the more verbose:

     ++var(arg1).

IMO, argN should always be implicitly an L-value, for
consistency.

>>>though the following code gives what I expect:
>>> int i = 1;
>>>
>>> let(_a = val(_1))
>>> [
>>>  cout << --_a << ' '
>>> ](i);
>>> cout << i << endl;
>>
>>Exactly! args are L-values. vals are R-values.
>>
>>I'll emphasize that in the docs. Mind if I steal your example?
> 
> 
> Sure! As you wish. 

Done :-)

Thanks!
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

David Abrahams wrote:
> Joel <joel@...> writes:
> 
> In my original posting, there were blank lines

[...]

Done. Thanks!

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

David Abrahams wrote:
> Joel <joel@...> writes:
> 
> In my original posting, there were blank lines

[...]

Done. Thanks!

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

Joel de Guzman wrote:
> Hi,
> 
> Hi. Here's a preview of Phoenix V2. This will probably be the last
> release of the library. Phoenix V2 will be the basis of the Phoenix
> and Boost.Lambda merger.
> 
> You can get it here:
> http://spirit.sourceforge.net/dl_more/phoenix-2.zip

I like it!

> You can browse the draft docs here:
> http://tinyurl.com/6crgp

There is a typeo in the table at composite.html#phoenix.operator:

Include Files:

    #include <boost/spirit/phoenix/operator/self.hppp>
---------------------------------------------------^

> What's new? A lot. This is a total rewrite based on earlier
> discussions with Jaakko Jarvi. The library's is built on
> top of Fusion and of course MPL.
> 
> Of particular interest are local variables and lambda-lambda
> scopes: http://tinyurl.com/3mn6w
> 
> There is also a set of lazy functions that work on STL
> sequences (e.g. push_back etc.): http://tinyurl.com/46bbm
> 
> and pretty soon, a final TODO item (built on top of scopes/
> lambda), lazy STL algorithms (e.g. find_if, etc). The scopes
> section (link provided above) in the docs illustrates how to
> write lazy functions that accept higher order functions
> (e.g. for_each).

I have written lazy veraions of pair.first and pair.second (see attachment).

Regards,
Reece

Joel de Guzman <joel@...> writes:

> Hi,
>
> Hi. Here's a preview of Phoenix V2. This will probably be the last
> release of the library. Phoenix V2 will be the basis of the Phoenix
> and Boost.Lambda merger.

I've been wondering, now that result_of is semi-standard, whether we
really should have used apply<> in the Lazy function interface, rather
than result<>, as that is compatible with result_of.  Maybe there's a
SFINAE way to make either one work?

-- 
Dave Abrahams
Boost Consulting
 http://www.boost-consulting.com

Joel de Guzman <joel@...> writes:

> David Abrahams wrote:
>> Joel de Guzman <joel@...> writes:
>> 
>> 
>>>Hi,
>>>
>>>Hi. Here's a preview of Phoenix V2. This will probably be the last
>>>release of the library. Phoenix V2 will be the basis of the Phoenix
>>>and Boost.Lambda merger.
>> 
>> 
>> I've been wondering, now that result_of is semi-standard, whether we
>> really should have used apply<> in the Lazy function interface, rather
>> than result<>, as that is compatible with result_of.  Maybe there's a
>> SFINAE way to make either one work?
>
> :) Phoenix used to use result<>. Yes, "result" has certain
> advantages. Another is backward compatibility with Phoenix-1.
> However, compatibility with MPL is important too. So, I don't
> really know what to say. Have them both?

Seems to me that for Phoneix, result<>/result_type is much more
useful/appropriate than apply<>/type.  I now lean toward the same
for Fusion.  Yes, I know I was the one who suggested you go the other
way :(

You can make adapters that help when you need both.

> ... Oh BTW, Dave: Dan Marsden has incorporated most of your
> review issues into the documentation. Thanks Dan! And Thanks
> for your review Dave! I shall upload an updated copy as soon
> as possible.

Looking forward to it.

-- 
Dave Abrahams
Boost Consulting
 http://www.boost-consulting.com