Proto for Boost mailing list page: Re: [proto] [phoenix3] New design proposal

Subject: Re: [proto] [phoenix3] New design proposal
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2010-10-19 04:33:05

On Tue, Oct 19, 2010 at 6:21 AM, Joel de Guzman
<joel_at_[hidden]> wrote:
> On 10/19/2010 3:25 AM, Thomas Heller wrote:
>>
>> Hi all,
>>
>> Based on recent discussions [1] I want to propose a new design for the
>> intermediate structure of phoenix3.
>>
>> This email will be the attempt to both explain the design, and formalize
>> what phoenix is, and what phoenix expressions are.
>> An implementation can be found at [2]. Please feel free to comment on the
>> concepts and design decision that were made. I urge you to read through
>> [1]
>> to better understand the motivation behind the need of such a refactoring.
>
> Can we also focus on one very specific use-case that demonstrates the
> motivation behind the need of such a refactoring and why the old(er)
> design is not sufficient? I'd really want to sync up with you guys.

With the old design (the one which is currently in the gsoc svn sandbox) I had
problems with defining what phoenix expressions really are. We had at least
two types of expressions. First were the ones we reused from proto (plus,
multiplies, function and so on), Second were these proto::function constructs
which had a funcwrap<T> struct and an env placeholder. This env placeholder
just wastes a valuable slot for potential arguments.
The second point why this design is not good, is that data and behaviour is not
separated. The T in funcwrap defines how the phoenix expression will
get evaluated.

This design solves this two problems: Data and behaviour are cleanly separated.
Additionally we end up with only one type of expressions: A expression
is a structure
which has a tag, and a variable list of children. You define what what
a valid expression
is by extending the phoenix_algorithm template through specialisation
for your tag.
The Actions parameter is responsible for evaluating the expression.
By template parametrisation of this parameter we allow users to easily
define their own
evaluation schemes without worrying about the validity of the phoenix
expression. This is
fixed by the meta grammar class.
I can imagine a lot of usecases that benefit from this feature. Let me
list a few here:
   - Multi Stage programming: evaluate the phoenix expression to
another language that can
     be compiled by some external compiler. The prime example i
imagine for this is that someone
     picks that topic up, and writes a shader DSL based on phoenix
reusing the already existing
     phoenix constructs.
  - Debugging: In order to debug a phoenix expression, we certainly do
not want to evaluate the
    phoenix expression in a C++ context, but probably into some kind
of string, giving detailed information
    about certain intrinsics of that expression
  - Optimiziers: With the help of this Actions parameter, it almost
gets trivial to write optimization
    passes that work on phoenix expression. I think this is worth
exploring, because a optimizer working
    on these high level expression has way more information than for
example the GIMPLE representation
    of GCC.

HTH,
Thomas