From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30803 invoked by alias); 25 Aug 2004 15:51:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30791 invoked from network); 25 Aug 2004 15:51:37 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 25 Aug 2004 15:51:37 -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 i7PFpaS2020195 for ; Wed, 25 Aug 2004 11:51:36 -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 i7PFpU319671; Wed, 25 Aug 2004 11:51:30 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0DBBD2B9D; Wed, 25 Aug 2004 11:50:18 -0400 (EDT) Message-ID: <412CB539.1060102@gnu.org> Date: Wed, 25 Aug 2004 15:51: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: Michael Chastain , gdb-patches@sources.redhat.com Subject: Re: GDB/MI Output syntax References: <20040824191931.GC17542@white> <412B980A.nailFLQ1QDS6L@mindspring.com> <412B9B2C.3080302@gnu.org> <20040824200116.GF17865@white> <412BA22C.1000106@gnu.org> <20040824205613.GG17865@white> In-Reply-To: <20040824205613.GG17865@white> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00694.txt.bz2 >>>> >Andrew, were you suggesting something like this? >>>> > >>>> >from >>>> > output ==> ( out-of-band-record )* [ result-record ] "(gdb)" nl >>>> >to >>>> > output ==> (out-of-band-record nl)* [ result-record nl] "(gdb)" nl >>>> > >>>> >and removing the 'nl' everywhere else? >> >>> >>> Yep. >>> >> >>>> >That might actually work. Although, I don't personally know a way of >>>> >changing a grammar and guaranteeing that there the same. >> >>> >>> A series of rewrites where NL is slow pushed down should eventually >>> result in the old grammar (well except that it would be fixed). > > > By the way you are talking, I can't tell if you are going to do this, or > if you expect someone else to do it? I eye balled it - it puts a NL at the end of each record which was the intent. > Should I just post a new grammar with the suggestion? The problem is, I > don't know how to prove that the new grammar is equivalant to the old > grammar. Is there a way to do that? Well, to be pedantic, the old grammer contained a bug which this fixes so we can't prove equivalence. However using a sequence of transformations (rewrite was a poor choice of word) we can show rough equivalence. For instance: > @item @var{output} @expansion{} > @code{( @var{out-of-band-record} @var{nl} )* [ @var{result-record} @var{nl} ] "(gdb)" @var{nl}} > > @item @var{result-record} @expansion{} > @code{[ @var{token} ] "^" @var{result-class} ( "," @var{result} )*} Moving result-record's NL into the result-record production yields: > @item @var{output} @expansion{} > @code{( @var{out-of-band-record} @var{nl})* [ @var{result-record} ] "(gdb)" @var{nl}} > > @item @var{result-record} @expansion{} > @code{ [ @var{token} ] "^" @var{result-class} ( "," @var{result} )* @var{nl}} which is the easy one done. The other while longer and more tedious is similar except it ends up pushing an NL down into stream-record (where it was missing). Is this what you ment? Andrew