From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1945 invoked by alias); 25 Sep 2009 10:55:30 -0000 Received: (qmail 1936 invoked by uid 22791); 25 Sep 2009 10:55:30 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx.southnet.co.nz (HELO viper.snap.net.nz) (202.37.101.20) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Sep 2009 10:55:24 +0000 Received: from totara (242.29.255.123.dynamic.snap.net.nz [123.255.29.242]) by viper.snap.net.nz (Postfix) with ESMTP id 869013DA6AD; Fri, 25 Sep 2009 22:55:21 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id 47AF5C167; Fri, 25 Sep 2009 22:55:19 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19132.41367.233102.480938@totara.tehura.co.nz> Date: Fri, 25 Sep 2009 10:55:00 -0000 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH:doc] GDB/MI attribute names In-Reply-To: <837hvnv45y.fsf@gnu.org> References: <19131.17428.428101.481874@totara.tehura.co.nz> <837hvnv45y.fsf@gnu.org> From: nickrob@snap.net.nz (Nick Roberts) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00784.txt.bz2 > > This patch, slightly paranoid, document the current practice for attribute > > names. I don't want future names to break exiting parsers. > > I agree, assuming that what you wrote is factually correct at this > point, and that we have no good reasons to modify it VSN. Is that > indeed so? I can't find any that don't fit the rule that I want to document. It occurred to me that the regexp that I was using to parse MI output for Emacs wouldn't work if certain characters, e.g "$", were used. I just want to discourage their use in future attribute names. Parsers will have to handle existing anomalies, if any. > > + @var{variable} expressions should be alphabetic words or comprise of > > + alphabetic words separated by underscores. ^^^^^^^^^^^ > > Don't you meant "comprised of"? Either sounds OK to me. > In any case, the text you suggests sounds a bit inaccurate to me. > (Maybe I just don't know enough about MI, so please bear with me.) > You say "variable expressions", but an expression can use operators, > can't it? If it can, then the operators are not generally alphabetic > characters. No I don't really mean expression. @var{variable} names... would probably work. > Based on my understanding of what you meant, I suggest to rephrase as > follows: > > Every @var{variable} should be specified as a sequence of alphabetic > characters and underscores. > > Does that reflect correctly what you wanted to say? I'm not sure. To me, thay're not really variables but a field names (or attribute names in HTML/XML parlance). It might mean the value rather than the name. How about: @var{variable} names should be specified as a sequence of alphabetic characters and underscores. Or say what you would like to see. I'm not too worried about the exact wording. I just want to formalise the output syntax a bit more. > Btw, are digit really "verboten"? If not, replace "alphabetic" with > "alphanumeric" above. I've actually used the [:alnum:] character class in my parser but there are so few names that I felt that requiring alphabetic wouldn't be restrictive. -- Nick http://users.snap.net.nz/~nickrob