On Tue, Oct 19, 2010 at 6:21 AM, Joel de Guzman <j...@boost-consulting.com> 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 _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto