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