[proto] Comma Strangeness
Well, my little lambda-like experimental language is getting rather large. I'm really having fun with it and am close to actually doing something almost useful with it. :) Unfortunately I've run into a problem I can't seem to isolate to a small testcase. I'm doing something like this: proto::display_expr( list [ obj["name1"].attr["a"], obj["name2"].attr["a"], obj["name3"].attr["b"] ] ); Presume I have all of the terminals, members, etc. declared/defined correctly (at least "correctly" as I understand it). display_expr dumps out an expression without any comma operators. It just shows a subscript off "list" with one "index," obj["name3"].attr["b"]. It's the behavior I would expect if the operands of the commas were not protoized expressions, but they _should_ be protoized. The funny thing is, if I write a small testcase just isolating the terminals, members, etc. needed to construct the expression, it works as expected. But in the context of the (much) larger language, it fails. However, the grammar specification shouldn't have any bearing on what display_expr dumps out. So any ideas as to why commas might be gobbled up prematurely? -Dave
display_expr dumps out an expression without any comma operators. It just shows a subscript off "list" with one "index," obj["name3"].attr["b"].
It's the behavior I would expect if the operands of the commas were not protoized expressions, but they _should_ be protoized.
The funny thing is, if I write a small testcase just isolating the terminals, members, etc. needed to construct the expression, it works as expected. But in the context of the (much) larger language, it fails. However, the grammar specification shouldn't have any bearing on what display_expr dumps out.
I have the following toy program :
#include <iostream>
#include
On Friday 26 March 2010 20:37:19 Manjunath Kudlur wrote:
The funny thing is, if I write a small testcase just isolating the terminals, members, etc. needed to construct the expression, it works as expected. But in the context of the (much) larger language, it fails. However, the grammar specification shouldn't have any bearing on what display_expr dumps out.
I have the following toy program :
and I do see the expression getting printed out correctly as follows. Do you see something different?
As I said, if I make a toy program, it works. Only in the context of the larger language code does it fail. I don't expect anyone to be able to easily reproduce the problem. I'm just looking for ideas of what to try next. -Dave
On 3/26/2010 6:11 PM, David Greene wrote:
But in the context of the (much) larger language, it fails. However, the grammar specification shouldn't have any bearing on what display_expr dumps out.
The grammar *could* have a bearing on what proto operators are considered, so long as you specified the grammar as the second parameter to proto::domain<>. If your grammar doesn't allow comma, then proto's comma operator is ignored, leaving only C++'s build-in comma. If that's not the problem, you'll have to post a self-contained repro of the problem so we can track it down. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Saturday 27 March 2010 23:35:01 Eric Niebler wrote:
On 3/26/2010 6:11 PM, David Greene wrote:
But in the context of the (much) larger language, it fails. However, the grammar specification shouldn't have any bearing on what display_expr dumps out.
The grammar *could* have a bearing on what proto operators are considered, so long as you specified the grammar as the second parameter to proto::domain<>. If your grammar doesn't allow comma, then proto's comma operator is ignored, leaving only C++'s build-in comma.
Ah, I'll have to check that. I use comma in the grammar but perhaps I didn't do the domain<> stuff correctly. -Dave
participants (3)
-
David Greene -
Eric Niebler -
Manjunath Kudlur