Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [PATCH:doc] GDB/MI attribute names
Date: Fri, 25 Sep 2009 12:53:00 -0000	[thread overview]
Message-ID: <h9ieb9$6cn$1@ger.gmane.org> (raw)
In-Reply-To: <19132.47302.194071.325914@totara.tehura.co.nz>

Nick Roberts wrote:

>  > > How about:
>  > > 
>  > >    @var{variable} names should be specified as a sequence of alphabetic
>  > >    characters and underscores.
>  > 
>  > It seem to me to introduce too many indirection levels. We don't have something
>  > called 'variable' that also has name, that is also 'specified' by something
>  > separate. Why not:
>  > 
>  >      The @var{variable} nonterminal in the above grammar may contain only
>  >      alphanumeric characters or the underscore character.
>  > 
>  > ? This is probably not 100% accurate either, since nonterminals do not
>  > contain characters but have terminal strings derived from them, which
>  > strings consist of characters, but I presume we're not writing a PhD here
>  > ;-)
> 
> I had to look up `nonterminal' in Wikipedia where it talks about
> Backus?Naur Form.  Having read that,
> 
>   <VARIABLE> should be specified as a sequence of alphabetic
>   characters and underscores.

That's again using the word 'specified', as if VARIABLE is something you write
specification for, and you are restricted in how you can write such specification.
Rather, VARIABLE *is* a sequence of alphabetic characters and underscores.

Anyway, this is probably too minor for me to further complain about.

> seems good to me.  Apparently it's a widely used syntax and it looks familiar
> to me, e.g., the git manpages and we could use it for existing documentation,
> e.g.,
> 
> <RESULT-RECORD> ::=  [ <TOKEN> ] "^" <RESULT-CLASS> ( "," <RESULT> )* <NL>
> 
> rather than the currently ad-hoc(?) metasyntax.

In fact, the current convention is just as good as putting nonterminal names in
angle brackets. BTW, probably the best way to fix documentation is actually
define 'string'. We have definition for c-string:

        c-string ==> 
        """ seven-bit-iso-c-string-content """

and can add this:

        string ==> 
        """ ( letter | digit | "_" ) * """

This is much more formal than anything else we can say.

- Volodya



  reply	other threads:[~2009-09-25 12:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-24 10:04 Nick Roberts
2009-09-25  8:09 ` Eli Zaretskii
2009-09-25 10:55   ` Nick Roberts
2009-09-25 11:09     ` Vladimir Prus
2009-09-25 12:34       ` Nick Roberts
2009-09-25 12:53         ` Vladimir Prus [this message]
2009-09-25 13:19           ` Eli Zaretskii
2009-09-25 13:35             ` Vladimir Prus
2009-09-25 13:59               ` Eli Zaretskii
2009-09-25 14:15                 ` Vladimir Prus
2009-09-25 15:54                   ` Eli Zaretskii
2009-09-25 22:32                   ` Nick Roberts
2009-09-25 23:12                     ` Nick Roberts
2009-09-28 16:25                       ` Vladimir Prus
2009-09-26  9:00                     ` Eli Zaretskii
2009-09-25 13:13       ` Eli Zaretskii
2009-09-25 13:40         ` Vladimir Prus
2009-09-25 13:07     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='h9ieb9$6cn$1@ger.gmane.org' \
    --to=vladimir@codesourcery.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox