[Review] Phoenix V3: mini-review starts February 19th
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
--- On Mon, 1/31/11, Hartmut Kaiser wrote:
Hi List,
Howdy.
Phoenix V3 is nearing its completion.
It looks to be really useful. I'm already starting to use it in some of my example code and am looking for ways to incorporate it into a few of my libraries. One possible feature request: delete_array, which calls operator delete[]. Cromwell D. Enage
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 ? 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? Robert Ramey
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.
(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, -- Eric Niebler BoostPro Computing http://www.boostpro.com
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
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.
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.
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.
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.
That's not really the right procedure to make a DSEL with Proto.
I'm just curious if I'm on the right track here.
I recommend you read the C++Next articles.
(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
Robert Ramey wrote:
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 .
Ok ... to clarify, there is: - Boost.Bind - Boost.Lambda - Boost.Phoenix - Boost.Function - Boost.Proto The first three definitely overlap. They are all libraries to create unnamed function objects. Boost.Phoenix combines all two of them and will be compatible to them (there will be a section in the docs about that particular topic). Boost.Function is a little different, it just lets you store something callable, basically making it "named" again. Boost.Proto is a complete beast of its own Boost.Phoenix is implemented with Proto as the underlying framework. That means we have: 1) An expression template tree full of proto expressions that are valid phoenix expressions (more on that in the docs, almost done ;)) 2) A mechanism to traverse this tree (for example evaluated). This traversal is done by PFOs
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.
It is possible to use Phoenix as a basis of your DSEL, this makes sense if you want to reuse a lot of the C++-Like syntax and semantics. What Phoenix will provide you is a convenient way to define expression (not saying proto is inconvient), and an (hopefully) easy way to evaluate the expressions. All this comes along with an already predefined set of C++ semantics. So i guess it makes sense to use phoenix as a rapid prototype environment for your DSEL. You can later on always easily migrate to "raw" proto.
I'm just curious if I'm on the right track here.
Robert Ramey
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 ?
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.html> HTH, Cromwell D. Enage
(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.html>
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 01/02/2011 01:43, Hartmut Kaiser wrote:
Feel free to preview the code at:
Hello, Just a quick typo : the file boost/phoenix/phoenix.hpp includes a few cpp files instead of (I guess) hpp files. MAT.
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 Jan 31, 5:43 pm, "Hartmut Kaiser" <hartmut.kai...@gmail.com> 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 Thanks, Alfredo
On Saturday, February 26, 2011 08:49:25 AM alfC wrote:
On Jan 31, 5:43 pm, "Hartmut Kaiser" <hartmut.kai...@gmail.com> 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 Feb 25, 11:57 pm, Thomas Heller <thom.hel...@googlemail.com> wrote:
On Saturday, February 26, 2011 08:49:25 AM alfC wrote:
On Jan 31, 5:43 pm, "Hartmut Kaiser" <hartmut.kai...@gmail.com> 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. Thanks, Alfredo
On Saturday, February 26, 2011 11:28:58 PM alfC wrote:
On Feb 25, 11:57 pm, Thomas Heller <thom.hel...@googlemail.com> wrote:
On Saturday, February 26, 2011 08:49:25 AM alfC wrote:
On Jan 31, 5:43 pm, "Hartmut Kaiser" <hartmut.kai...@gmail.com> 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
participants (9)
-
alfC -
Cromwell Enage -
Edward Diener -
Eric Niebler -
Hartmut Kaiser -
Mathias Gaunard -
Mathieu Champlon -
Robert Ramey -
Thomas Heller