[proto] Manipulating _data
So I've had fun tinkering with my lambda-like language. I moved on to try to introduce scoping, but I'm having some trouble. I've attached a simplified example. Compiling as-is, the test outputs what I would expect. It seems like the LookupSymbol transform works brilliantly, so symbol lookup is a go. However, convincing the grammar to match an expression that invokes the AddScope transform seems more difficult. Commenting the #if clause results in an error about converting a Wrapper<...> to a shared_ptr<Base> which I can only guess means the grammar is not matching the proto expression. I've tried all sorts of different things. I don't think the UnaryPassThrough transform should be neccessary, but maybe it does't hurt either. With or without it, the error is the same. What am I missing here? Thanks! -Dave
Hi David, On 2/2/2010 3:45 PM, David A. Greene wrote:
So I've had fun tinkering with my lambda-like language. I moved on to try to introduce scoping, but I'm having some trouble. I've attached a simplified example.
Compiling as-is, the test outputs what I would expect. It seems like the LookupSymbol transform works brilliantly, so symbol lookup is a go.
However, convincing the grammar to match an expression that invokes the AddScope transform seems more difficult. Commenting the #if clause results in an error about converting a Wrapper<...> to a shared_ptr<Base> which I can only guess means the grammar is not matching the proto expression.
You guess correctly, and you could have verified that for yourself with a compile-time assertion, which I've added for you. See attached.
I've tried all sorts of different things. I don't think the UnaryPassThrough transform should be neccessary,
It's not; I've removed it.
but maybe it does't hurt either. With or without it, the error is the same.
What am I missing here?
You're going to kick yourself. The problem is exactly the same as last time. The expression is a subscript expression, but you don't have a case that handles subscript expressions. You seem to be confusing terminals within sub-expressions with the operators that bind sub-expressions together. Pretty much the only change I had to make was to change this: template<> struct ConstructStatementGrammarCases::case_keyword::scope to this: template<> struct ConstructStatementGrammarCases::case_boost::proto::tag::subscript If I can make a suggestion.... proto::switch_ is an optimization. Leave it for later. Just use proto::or_ for now, and when you get everything working, you can easily change it to use proto::switch_ to improve compile times. I think with proto::or_, you'll have an easier time keeping terminals and operators straight. I'm attaching a corrected example. There seems to be a logic flaw though; outer scopes are not getting searched. That should be a simple fix. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tuesday 02 February 2010 04:27:15 Eric Niebler wrote:
What am I missing here?
You're going to kick yourself. The problem is exactly the same as last time. The expression is a subscript expression, but you don't have a case that handles subscript expressions. You seem to be confusing terminals within sub-expressions with the operators that bind sub-expressions together. Pretty much the only change I had to make was to change this:
Ha! And I forgot to change that after I finished defining the grammar. A forgotten TODO. I will be more judicious in my use of assertions in the future.
I'm attaching a corrected example. There seems to be a logic flaw though; outer scopes are not getting searched. That should be a simple fix.
That was deliberate for this test. Rest assured that the real code does lookups properly. :) Thanks again. -Dave
participants (3)
-
David A. Greene -
David Greene
-
Eric Niebler