
On Wed, Sep 19, 2012 at 2:23 AM, Thomas Heller <thom.heller@gmail.com> wrote:
On 09/18/2012 08:06 PM, Eric Niebler wrote:
On 9/18/2012 10:45 AM, Andrey Semashev wrote:
On Tuesday 18 September 2012 13:58:24 Felipe Magno de Almeida wrote:
Could it use boost.phoenix v3? IUC, Phoenix v3 creates a boost.proto expression. The library could make transformations to these expressions.
Yes, phoenix was designed to make this sort of application possible.
Indeed.
Phoenix actors do contain Proto expressions. But as I understand, actors and the additional components Phoenix implements to evaluate expressions in a functional manner are useless in context of Boost.Compute.
True, you would need a different back-end.
Indeed.
IIUC, the constructed expressions are not invoked but translated into strings (the C99 source code). Using Proto directly seems more appropriate.
Just because you need a different back-end doesn't mean the phoenix front-end is worthless. Phoenix has defined a schema that maps C++ statements onto C++ expressions and provides the components to build these expressions for you. To ignore that and rebuild it from scratch seems like a waste to me.
Besides, having a way to take a single phoenix expression and evaluate it in different ways -- on a CPU with the built-in Phoenix evaluators, or on a GPU with alternate ones -- sounds bloody cool, and very useful.
I have to fully agree here. The external transforms we put tremendous effort into were designed for exactly that purpose. I would not like to see this going to waste hand have yet another lambda library implemented. I even put up an example for this http://www.boost.org/doc/libs/1_51_0/libs/phoenix/example/parallel_for.cpp (Ok, this is for openmp, but i think it shows the basic direction one could go). Instead of executing the expression in the evaluation you create a string and be done with it. Reuse a subset of the already existing phoenix expressions, generate an error on the unsupported ones, use the phoenix extension mechanism to create Boost.Compute "overloads" for regular functions. Bloody cool indeed and on my list from day 1 we had the external transforms in place. So question to Kyle is: What did you miss from phoenix 3?
Truthfully, I've never used (or even really taken a close look at) Boost.Phoenix. The Proto library seemed to have the functionality I needed and thus I used that. I will take a look at Boost.Phoenix 3 and see if it will work for Boost.Compute. Thanks for providing the example link. Cheers, Kyle