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

Subject: Re: [proto] [phoenix3] New design proposal
From: Eric Niebler (eric_at_[hidden])
Date: 2010-10-19 12:08:04

On 10/19/2010 1:33 AM, Thomas Heller wrote:
> On Tue, Oct 19, 2010 at 6:21 AM, Joel de Guzman wrote:
>> 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.

What Thomas said. We realized that for Phoenix to be extensible at the
lowest level, we'd need to document its intermediate form: the Proto
tree. That way folks have the option to use Proto transforms on it.
(There are higher-level customization points that don't expose Proto,
but I'm talking about real gear-heads here.)

There were ugly things about the intermediate form we wanted to clean up
before we document it. That started the discussion. Then the discussion
turned to, "Can a user just change a semantic actions here and there
without having to redefine the whole Phoenix grammar in Proto, which is
totally non-trivial?" I forget offhand what the use case was, but it
seemed a reasonable thing to want to do in general. So as Thomas says,
the goal is two-fold: (a) a clean-up of the intermediate form ahead of
its documentation, and (b) a way to easily plug in user-defined semantic
actions without changing the grammar.

I think these changes effect the way to define new Phoenix syntactic
constructs, so it's worth doing a before-and-after comparison of the
extensibility mechanisms. Thomas, can you send around such a comparison?
How hard is it to add a new statement, for instance?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com