From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8649 invoked by alias); 19 Dec 2002 19:58:40 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8642 invoked from network); 19 Dec 2002 19:58:40 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 209.249.29.67 with SMTP; 19 Dec 2002 19:58:40 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id gBJJwSC09884; Thu, 19 Dec 2002 11:58:28 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Paul Hilfinger Cc: gdb Subject: Re: c-exp.y References: <200212190336.TAA20859@tully.CS.Berkeley.EDU> From: David Carlton Date: Thu, 19 Dec 2002 11:58:00 -0000 In-Reply-To: <200212190336.TAA20859@tully.CS.Berkeley.EDU> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00294.txt.bz2 On Wed, 18 Dec 2002 19:36:22 -0800, Paul Hilfinger said: >> I suspect that the division of labor between what the >> parse_expression does and what eval_expression does is a bit funny, >> and I'm pretty sure that the rule >> >> start : exp1 >> | type_exp >> ; >> >> in the parser leads to some conceptual incoherence. > It does, but it is not alone, which I guess was my point. Look > further down in the grammar, and you find > exp : '(' type ')' exp %prec UNARY > ... > ; > exp : '(' exp1 ')' > { } > which is essentially the same thing all over again. Ah, gotcha. Good point. I'll have to think about what to do with this, then. It seems like the two obvious options would be either to have the lexer handle all double-colons, or else to have the lexer handle none of them but to add a rule in the grammer converting a possibly qualified name to a type. And the former option doesn't work because the lexer doesn't have enough smarts to let GDB do something useful with expressions of the form C::x where x is a non-type member of C. And the latter option probably won't work for the reasons you are bringing up. Sigh. Certainly the short-term "fix" of extending the current hack in yylex is looking more and more necessary. David Carlton carlton@math.stanford.edu