From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-20468-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 23709 invoked by alias); 6 Jan 2005 00:32:31 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 23652 invoked from network); 6 Jan 2005 00:32:21 -0000
Received: from unknown (HELO demos.bsdclusters.com) (69.55.225.36)
  by sourceware.org with SMTP; 6 Jan 2005 00:32:21 -0000
Received: from demos.bsdclusters.com (demos [69.55.225.36])
	by demos.bsdclusters.com (8.12.8p1/8.12.8) with ESMTP id j060WKl5060874;
	Wed, 5 Jan 2005 16:32:20 -0800 (PST)
	(envelope-from kmacy@fsmware.com)
Received: from localhost (kmacy@localhost)
	by demos.bsdclusters.com (8.12.8p1/8.12.8/Submit) with ESMTP id j060WKjq060871;
	Wed, 5 Jan 2005 16:32:20 -0800 (PST)
X-Authentication-Warning: demos.bsdclusters.com: kmacy owned process doing -bs
Date: Thu, 06 Jan 2005 00:32:00 -0000
From: Kip Macy <kmacy@fsmware.com>
X-X-Sender: kmacy@demos.bsdclusters.com
To: Paul Schlie <schlie@comcast.net>
cc: gdb@sources.redhat.com
Subject: Re: GDB/MI Output Syntax
In-Reply-To: <BE01F034.8807%schlie@comcast.net>
Message-ID: <20050105163128.U97844@demos.bsdclusters.com>
References: <BE01F034.8807%schlie@comcast.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-SW-Source: 2005-01/txt/msg00045.txt.bz2


Similar alternatives have been discussed previously and decided against.
Check the archives for details.

			-Kip

> Or how about a basic scheme (<keyword> <expression> ...) syntax, can't get
> much simpler or more flexible than that, not to mention it's fairly straight
> forward easy to read/parse/extend and may realativly easily accomplished by
> imbedding an open-source basic scheme interpreter, vs re-inventing the
> wheel; nearly eliminating the necessity for steps 1, 2; and longer term
> could easily eliminate gdb's present less than flexible command interpreter,
> as there's truly no good reason for the two to be distinct. (Not a new
> notion; but possibly timely and arguably far more productive than developing
> yet another yet another syntax/language/intepreter/etc.)
>
>
>
>
>
>