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 _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
