Re: [Boost-users] [Review] Phoenix V3: mini-review starts February19th

Subject: Re: [Boost-users] [Review] Phoenix V3: mini-review starts February19th
From: Eric Niebler (eric_at_[hidden])
Date: 2011-02-03 02:18:32

(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