From: David A. Greene (greened_at_[hidden])
Date: 2007-07-01 16:25:25
On Sunday 01 July 2007 10:13, Eric Niebler wrote:
> Oh wait, that's not quite what you want, because then if_[e1].else_[e2]
> will chop off the if_ part of the tree. What you need instead is a
> member like (untested):
> template<typename Expr ...>
> struct phoenix_expr
> : proto::extends<Expr ...>
> : else_(proto::make_expr<phoenix::tag::else_>(*this))
> // ...
> pheonix::tag::else_ // else is now an "operator"
> , phoenix_expr const
> >::type const else_;
> Then, if_/else_ statements would conform to the following grammar:
Ok, that makes sense to me, modulo the current lack of make_expr
I'm looking to do something similar to what Dan is doing so I'm glad he
asked the question. I was just about to.
One thing that's not clear to me is how he would handle the
if_(expr)[...] syntax. In your first message you have:
// Here is the grammar for if_ expressions
I don't understand the derivation from proto::subscript. What about the
From your second message:
Then, if_/else_ statements would conform to the following grammar:
Again what about the call operator?
Dan has two uses of operator() here. The first is a proto expression that
needs to be part of the grammar to match the if expression. The other is
the operator() provided through proto::extends to do the runtime evaluation.
I'm going to be doing something different. Rather than evaluate the
expression, I'm going to want to run a transformation on it. Given the
example from your second message:
template<typename Expr ...>
: proto::extends<Expr ...>
pheonix::tag::else_ // else is now an "operator"
, phoenix_expr const
>::type const else_;
how do I match the new "else_ operator" and transform it?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk