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

Subject: Re: [Boost-users] [Review] Phoenix V3: mini-review starts February19th
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-02-02 17:21:30

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