From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21597 invoked by alias); 26 Aug 2004 21:13:22 -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 21541 invoked from network); 26 Aug 2004 21:13:20 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 26 Aug 2004 21:13:20 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7QLDFS2013000 for ; Thu, 26 Aug 2004 17:13:15 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7QLDE318149; Thu, 26 Aug 2004 17:13:14 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6BCB12B9D; Thu, 26 Aug 2004 17:12:01 -0400 (EDT) Message-ID: <412E5221.8010601@gnu.org> Date: Thu, 26 Aug 2004 21:13:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040801 MIME-Version: 1.0 To: Bob Rossi Cc: gdb@sources.redhat.com Subject: Re: GDB/MI Output Syntax References: <20040825154348.GA19533@white> In-Reply-To: <20040825154348.GA19533@white> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00401.txt.bz2 > Hi, > > Along with the newline changes, there are 2 other changes that I propose > to the grammar. They are, > > async-record ==> exec-async-output | status-async-output | notify-async-output > exec-async-output ==> [ token ] "*" async-output > status-async-output ==> [ token ] "+" async-output > notify-async-output ==> [ token ] "=" async-output] FYI, these were done this way so that the complete structure and intent was clear (rather than worry about language issues). As you note a rewrite gives an ll(1) grammar; it also looses that clarity. > to > > async-record ==> [token] async-record-kind async-output > async-record-kind ==> "*" | "+" | "=" > > however, if you really would like to keep the *-async-output rules, we > could do > > async-record ==> [token] async-record-kind async-output > async-record-kind ==> exec-async-output | status-async-output | notify-async-output > exec-async-output ==> "*" > status-async-output ==> "+" > notify-async-output ==> "=" I can see something like (better names): async-record ==> [token] async-output async-output ==> exec-async-output | ... exec-async-output ==> "*" async-result async-result ==> async-class ( "," @var{result} )* @var{nl} > The second change is identical but refers to the rules of > stream-record ==> console-stream-output | target-stream-output | log-stream-output > console-stream-output ==> "~" c-string > target-stream-output ==> "@" c-string > log-stream-output ==> "&" c-string > > to > stream-record => stream-record-kind c-string > stream-record-kind => "~" | "@" | "&" > > The reason it would be helpful to modify the grammar in this way is that > it leads to a more elegant form when trying to build an intermediate > representation. At the parse level of 'stream-record' or 'async-record' > you have all of the information necessary in order to populate a > structure with data. Otherwise, the information is a few levels down > stream. I don't follow. Andrew