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
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 list run by eric at boostpro.com