(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