From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27004 invoked by alias); 26 Aug 2004 22:41:38 -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 26982 invoked from network); 26 Aug 2004 22:41:36 -0000 Received: from unknown (HELO smtp10.atl.mindspring.net) (207.69.200.246) by sourceware.org with SMTP; 26 Aug 2004 22:41:36 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1C0Sw1-0000KB-00; Thu, 26 Aug 2004 18:41:33 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id EA2A94B102; Thu, 26 Aug 2004 18:41:34 -0400 (EDT) Date: Thu, 26 Aug 2004 22:41:00 -0000 From: Michael Chastain To: cagney@gnu.org, bob@brasko.net Subject: Re: GDB/MI Output Syntax Cc: gdb@sources.redhat.com Message-ID: <412E671E.nail8HL11F7WG@mindspring.com> References: <20040825154348.GA19533@white> <412E5221.8010601@gnu.org> In-Reply-To: <412E5221.8010601@gnu.org> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00406.txt.bz2 Well, the difference betwen: # more nonterminals async_record : exec_async_output | status_async_output | notify_async_output ; exec_async_output : opt_token "*" async_output ; status_async_output : opt_token "+" async_output ; notify_async_output : opt_token "=" async_output ; And: # less nonterminals async_record : opt_token async_record_kind async_output async_record_kind : "*" | "+" | "=" ... that difference is not going to make-or-break the necessary LALR(1) property. The place to watch out for that is with rules that can be reduced with 0 input tokens. That gets ambiguous real fast. My esthetics say to combine common things, Andrew's esthetics say to be more concrete names for things. It's an esthetic tradeoff. Andrew has more say as the MI maintainer. exec_async_output is actually a pretty good nonterminal. It's async_output that really bugs me. async_output is not a complete object, it's a sub-part that doesn't really need to be there. Just substitute in its definition. > async-result ==> async-class ( "," @var{result} )* @var{nl} I think the "*" stuff has to go, though. bison and yacc don't process it. Which means that as soon as someone tries to write a bison grammar, they have to write something different from our doco. So every front end will have a slightly different parser and that will be to GDB's sorrow. Eventurally GDB will do something that's in the printed grammar, and some front end will tip over because it's not accepted by their bison grammar. Also, some front-end writers will walk into the same sand-trap that Bob did when they are translating (a b)* into bison language, and mistakenly write a non-LALR(1) grammar. The closer our doco is to a real bison grammar that really compiles, the less grief. bob> The reason it would be helpful to modify the grammar in this way is that bob> it leads to a more elegant form when trying to build an intermediate bob> representation. At the parse level of 'stream-record' or 'async-record' bob> you have all of the information necessary in order to populate a bob> structure with data. Otherwise, the information is a few levels down bob> stream. ac> I don't follow. Every time a yacc/bison rule is reduced, the code associated with that rule has to make another data structure that copies/refers-to all the data from each of the components. So a flatter rule tree means the C code looks like "a->b->data" instead of "a->b->c->d->data".