On 2/2/2011 12:06 PM, Robert Ramey wrote:

Hartmut Kaiser wrote:

...

Hi List,

Phoenix V3 is nearing its completion.

With the port to Boost.Proto we tried to address the outstanding issues of the review and would like to announce that the mini-review will start on February 19th.

Feel free to preview the code at:

https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/

and the documentation at:

http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/ht ml/index.html

We are currently occupied with code cleanups and finishing of the documentation. The code itself is in a stable condition, feel free to make yourself comfortable with this new library.

Regards Hartmut Phoenix V3 Review Manager --------------- http://boost-spirit.com

I've been studying proto/fusion/phoenix. Becoming familiar with this stuff takes quite an effort. It's quite interesting though. And it seems ideal for a project I want to do. But I do have one question:

phoenix/Function objects Functional/ Proto/ PolymorphicFunctionObject

What is 'PolymorphicFunctionObject' ? Proto is for building dsels, is it not ? Boost 'functional' is kind of old. Does anybody use it much anymore ? Instead I see: boost::bind, boost::lambda, boost::phoenix all producing function objects and boost::function as a universal holder of such objects. But I have not studied Phoenix as yet although I am overjoyed it is finally being considered as an individual part of Boost. My understanding from very briefly looking at it is that it is a successor to boost::lambda.

Eric Niebler wrote:

(Cross-posting for now, but please follow up on boost-users only.)

On 2/3/2011 12:06 AM, Robert Ramey wrote:

...

I've been studying proto/fusion/phoenix. Becoming familiar with this stuff takes quite an effort. It's quite interesting though. And it seems ideal for a project I want to do. But I do have one question:

phoenix/Function objects Functional/ Proto/ PolymorphicFunctionObject ?

All seem to address function objects. There seems to be a lot of overlap and it's not clear to me which I should be using for what. That is, each library seems to address function objects from a different perspective, but there is not summary which contrasts them. I need a "function object library Decoder Ring". Are there any documents which would help me out?

Lots of libraries define function objects or tools for creating them. That's true for Phoenix and Proto (both tools for creating function objects). Phoenix helps you define general purpose function objects in-place (lambdas). Proto helps you define function objects specifically for manipulating expression trees (grammars w/ semantic actions).

PolymorphicFunctionObject is a concept that function objects must model if they are to be usable with boost::result_of. Function objects created by Phoenix and Proto all model PolymorphicFunctionObject.

I don't know anything about boost/functional.

HTH,

Amazingly, this DOES help. I should add boost/function to the above list which is also a library for defining function objects. A cursory examination would suggest to this humble reader that: boost/bind included in boost/lambda boost/lambda & boost/function included in boost/phoenix proto - able to use function objects defined by phoenix but not those defined by boost/function proto - also used to define function objects specifically for proto DSEL . As a strategy for implementing my own pet DSEL application I wanting to a) define types of the objects that I'm dealing with - no conceptual problems here. b) define concepts on the above types to catch errors - no conceptual problems here but somewhat harder. c) define functions and/or function objects which use variables of the above types. At this point the question arises as to which library would provide the best "templates" to build these funtions/function_objects. This was the motivation for my question. d) define concepts on c) to catch usage errors e) build some tests/examples using the above to verify that the whole thing looks more or less natural and not too cryptic to be usable. f) build a "proto-layer" which implements the DSEL using the the function objects defined above. It would have its own set of functions with similar names to c) above which would return expressions rather than do any real work. That is, c) above would define "language semantics", while proto would define "language syntax" in terms of c) above. A large part of the motivation here is to separate things into "conceptual layers" so I don't have to the whole thing in my head simultaneously. At my age, internal stack overflow is a serious concern. I'm just curious if I'm on the right track here. Robert Ramey

(Moving this discussion to just -users to reduce cross-posting.) On 2/3/2011 2:20 AM, Mathias Gaunard wrote:

On 02/02/2011 19:21, Robert Ramey wrote:

...

boost/lambda& boost/function included in boost/phoenix

Boost.Phoenix does not include Boost.Function. boost::function is a type erasure wrapper for function objects.

Right.

...

proto - able to use function objects defined by phoenix but not those defined by boost/function

I think it's able to use neither, since they must be specifically tagged with proto::callable.

Not true. Proto can use any PolymorphicFunctionObject, if it's wrapped in proto::call. Tagging the function object with proto::callable makes wrapping it in proto::call unnecesary -- it's nothing more than sugar.

...

As a strategy for implementing my own pet DSEL application I wanting to

If you want to make a DSEL, the right tool to use is Proto.

Well, it's the only tool, so yeah, it's the right one. :-)

...

a) define types of the objects that I'm dealing with - no conceptual problems here.

If you make them Proto terminals up front, you save some work later. That doesn't preclude any of your other plans.

...

b) define concepts on the above types to catch errors - no conceptual problems here but somewhat harder. c) define functions and/or function objects which use variables of the above types. At this point the question arises as to which library would provide the best "templates" to build these funtions/function_objects. This was the motivation for my question.

You are talking about ordinary function [objects] for eager evaluation, right? I don't think there is a tool for that. Boost.Egg was a proposed library to make writing function objects easier, but it was rejected.

...

d) define concepts on c) to catch usage errors

Not sure what you mean. If your functions accept T's and eagerly compute new T's, there are no new types and no need for new concepts.

...

e) build some tests/examples using the above to verify that the whole thing looks more or less natural and not too cryptic to be usable.

IMO, it's actually easier to prototype your EDSL syntax with Proto. All the operator overloads exist already and build expression trees for you. proto::display_expr pretty-prints the expression tree, letting you easily see what you're doing. Have a look at this if you're looking for a place to start: http://cpp-next.com/archive/2010/09/expressive-c-playing-with-syntax/

...

f) build a "proto-layer" which implements the DSEL using the the function objects defined above. It would have its own set of functions with similar names to c) above which would return expressions rather than do any real work. That is, c) above would define "language semantics", while proto would define "language syntax" in terms of c) above.

That's not really the right procedure to make a DSEL with Proto.

It does feel like a lot of unnecessary work to me.

...

I'm just curious if I'm on the right track here.

I recommend you read the C++Next articles.

Couldn't hurt. At least the one I linked to above. -- Eric Niebler BoostPro Computing http://www.boostpro.com

On 2/2/2011 12:55 PM, Eric Niebler wrote:

(Cross-posting for now, but please follow up on boost-users only.)

On 2/3/2011 12:06 AM, Robert Ramey wrote:

...

I've been studying proto/fusion/phoenix. Becoming familiar with this stuff takes quite an effort. It's quite interesting though. And it seems ideal for a project I want to do. But I do have one question:

phoenix/Function objects Functional/ Proto/ PolymorphicFunctionObject ?

All seem to address function objects. There seems to be a lot of overlap and it's not clear to me which I should be using for what. That is, each library seems to address function objects from a different perspective, but there is not summary which contrasts them. I need a "function object library Decoder Ring". Are there any documents which would help me out?

Lots of libraries define function objects or tools for creating them. That's true for Phoenix and Proto (both tools for creating function objects). Phoenix helps you define general purpose function objects in-place (lambdas). Proto helps you define function objects specifically for manipulating expression trees (grammars w/ semantic actions).

PolymorphicFunctionObject is a concept that function objects must model if they are to be usable with boost::result_of. Function objects created by Phoenix and Proto all model PolymorphicFunctionObject.

I have read the docs for boost::result_of but I do not see anything there about the PolymorphicFunctionObject concept there. Where in the Boost documentation is the explanation for this concept ?

(cc'ing boost-docs) On 2/3/2011 10:23 AM, Cromwell Enage wrote:

...

I have read the docs for boost::result_of but I do not see anything there about the PolymorphicFunctionObject concept there. Where in the Boost documentation is the explanation for this concept ?

I remember reading about this concept here:

http://www.boost.org/libs/fusion/doc/html/fusion/functional/concepts/poly.ht...

Yeah, Proto defines a similar concept. It highlights the need to have one place where the Boost-wide concepts are defined, and an easy way to link to them. Arguably, the proper place for the definition of PolymorphicFunctionObject is in Boost.Result_of's docs. But if we do that, we have to accept the fact that when building the pdf doc of, say, Fusion, the links to the concept will be broken. Kinda sucky. -- Eric Niebler BoostPro Computing http://www.boostpro.com

On Wednesday, February 23, 2011 04:52:24 PM Mathieu Champlon wrote:

On 01/02/2011 01:43, Hartmut Kaiser wrote:

...

Feel free to preview the code at: https://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/

Hello,

Just a quick typo : the file boost/phoenix/phoenix.hpp includes a few cpp files instead of (I guess) hpp files.

Thanks, this is fixed now.

MAT.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

On Saturday, February 26, 2011 08:49:25 AM alfC wrote:

On Jan 31, 5:43 pm, "Hartmut Kaiser" wrote:

...

Hi List,

PhoenixV3 is nearing its completion.

With the port to Boost.Proto we tried to address the outstanding issues of the review and would like to announce that themini-review will start on February 19th.

Thank you for the new version of Phoenix-3. I wonder if things like phoenix-expression matching is now possible as "promised" in this thread: http://lists.boost.org/boost-users/2010/05/59491.php

Yes, stuff like this could be indeed made possible. Though, I don't see where phoenix comes into the game in the examples in this thread.

Thanks, Alfredo

On Saturday, February 26, 2011 11:28:58 PM alfC wrote:

On Feb 25, 11:57 pm, Thomas Heller wrote:

...

On Saturday, February 26, 2011 08:49:25 AM alfC wrote:

...

On Jan 31, 5:43 pm, "Hartmut Kaiser" wrote:

...

Hi List,

PhoenixV3 is nearing its completion.

With the port to Boost.Proto we tried to address the outstanding issues of the review and would like to announce that themini-review will start on February 19th.

Thank you for the new version of Phoenix-3. I wonder if things like phoenix-expression matching is now possible as "promised" in this

thread: http://lists.boost.org/boost-users/2010/05/59491.php

Yes, stuff like this could be indeed made possible. Though, I don't see where phoenix comes into the game in the examples in this thread.

I was doing things like this with Phoenix2 by hacking the internals:

in a function call like this

integral( 'arbitrary phoenix expression' , interval(2., 4.));

I was matching, first that the passed expresion is of the form #1/ ( phoenix::_1 - #2), if so it checked that #2 is a 'double-type' value, then extracted that value and then passed the whole thing to a numerical intergrator that handle functions with sigularities at the value of #2. If the expression didn't match then a generic integrator is called.

Nothing easier than that, no need to hack (more or less) undocumented internals of the library. Every phoenix expression can be matched with proto's grammar matching facilities: struct singularity : proto::when< proto::divides< proto::_ , proto::minus< phoenix::expression::argument<1> , proto::_ > > , proto::_value(proto::_right(proto::_right)) > {}; Match arbitratry expressions with proto::matches ... call the transform to get the singularity, etc.

Thanks, Alfredo