On 10/20/2010 12:08 AM, Eric Niebler wrote:
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?
Yes, exactly, that's what I want. Anyway, while I'd still want to see
this, I looked at the code and I like it, except for some nits here
and there (especially naming). More on that later.
Regards,
--
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net
_______________________________________________
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
