Hello all,
I'm writing some documentation for some of my own code, and, for the
sake of convenience, am trying to write syntax descriptions using the
same grammar as the HyperSpec. Concerning multiple forms and values,
however, I'm noticing a trend for which I can't figure a reason, even
after reading the notational conventions section of the HyperSpec and
the Wikipedia pages on [E]BNF.
The description of, e.g., case, is:
case keyform {normal-clause}* [otherwise-clause] => result*
and my question is:
Why {normal-clause}* rather than just normal-clause*? After all, it's
result* and not {result}*. I understand that the semantics are
slightly different, one says that you can have an aribitrary number of
repetitions of normal-clauses, and the other would say that you can
have an arbitrary number of normal-clauses, but these, in this case,
would seem to describe the same expressions. Is there method in this
madness? (It's not really madness, as both would seem to work just
fine, but I'm curious as to whether there is something here that I'm
missing, a stylistic convention for reasons that I'm missing, ...)
Thanks in advance!
//J
On Tue, 25 Sep 2007 21:02:30 -0000, Joshua Taylor
<···········@gmail.com> wrote:
>Hello all,
>
>I'm writing some documentation for some of my own code, and, for the
>sake of convenience, am trying to write syntax descriptions using the
>same grammar as the HyperSpec. Concerning multiple forms and values,
>however, I'm noticing a trend for which I can't figure a reason, even
>after reading the notational conventions section of the HyperSpec and
>the Wikipedia pages on [E]BNF.
>
>The description of, e.g., case, is:
>
>case keyform {normal-clause}* [otherwise-clause] => result*
>
>and my question is:
>
>Why {normal-clause}* rather than just normal-clause*? After all, it's
>result* and not {result}*. I understand that the semantics are
>slightly different, one says that you can have an aribitrary number of
>repetitions of normal-clauses, and the other would say that you can
>have an arbitrary number of normal-clauses, but these, in this case,
>would seem to describe the same expressions. Is there method in this
>madness? (It's not really madness, as both would seem to work just
>fine, but I'm curious as to whether there is something here that I'm
>missing, a stylistic convention for reasons that I'm missing, ...)
By convention a token surrounded by curly braces indicates a named
substitution - in this case the token, "normal-clause", should be the
name of another production within the grammar.
"result" is generic - it does not name another grammar production.
George
--
for email reply remove "/" from address
George Neuner <·········@comcast.net> wrote:
+---------------
| <···········@gmail.com> wrote:
| >case keyform {normal-clause}* [otherwise-clause] => result*
...
| >
| >Why {normal-clause}* rather than just normal-clause*? ...
|
| By convention a token surrounded by curly braces indicates a named
| substitution - in this case the token, "normal-clause", should be the
| name of another production within the grammar.
+---------------
Also see CLHS 1.4.1.2.3 "Additional Uses for Indirect Definitions
in Modified BNF Syntax" [which conveniently uses CASE as an example!],
where it notes that some of those "other productions" might be unused
in the formal grammar on the page where they're defined... but might
be referenced in the formal grammar elsewhere, or informally in the
descriptive text.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kent M Pitman
Subject: Re: Notational Convention for BNF in HyperSpec
Date:
Message-ID: <uir5y2eee.fsf@nhplace.com>
····@rpw3.org (Rob Warnock) writes:
> George Neuner <·········@comcast.net> wrote:
> +---------------
> | <···········@gmail.com> wrote:
> | >case keyform {normal-clause}* [otherwise-clause] => result*
> ...
> | >
> | >Why {normal-clause}* rather than just normal-clause*? ...
> |
> | By convention a token surrounded by curly braces indicates a named
> | substitution - in this case the token, "normal-clause", should be the
> | name of another production within the grammar.
> +---------------
>
> Also see CLHS 1.4.1.2.3 "Additional Uses for Indirect Definitions
> in Modified BNF Syntax" [which conveniently uses CASE as an example!],
> where it notes that some of those "other productions" might be unused
> in the formal grammar on the page where they're defined... but might
> be referenced in the formal grammar elsewhere, or informally in the
> descriptive text.
I'm not so sure there this isn't just messy notation on my part.
I'd have to go back and read carefully what my conventions were,
(or maybe others have). But before anyone builds a shrine around
something that could just be either a typo or an inconsequential
equivalence not in most reduced form, one should at least consider
the possibility of sloppiness.
Also, sometimes this kind of thing creeps in when one is editing
something [that might have been badly expressed protodoc] like:
{ normal-clause | otherwise-clause }*
where it may be that I wanted to make sure the otherwise clause
only went last and I removed part of the brace structure but then
didn't edit out the braces. Or, perhaps even more likely, it could
come from an early version that said:
case keyform { normal-clause | otherwise-clause }*
ccase keyform { normal-clause }*
ecase keyform { normal-clause }*
where braces were used in all three cases for reasons of parallel
construction reason [where "parallel construction" is a term of art
in the writing of literature, not programs, as in
http://humanities.ucsd.edu/writing/grammar/21parallel.htm ].
In the end, I think it's the kind of harmless stuff like
writing (x)^2 meaning the same as x^2 in an infix language [which the
BNF is]. One is only supposed to worry about extra parens in Lisp,
where parens generally do more than group--they have often semantic
effect. ;)
On 26 Sep 2007 01:18:17 -0400, Kent M Pitman <······@nhplace.com>
wrote:
>····@rpw3.org (Rob Warnock) writes:
>
>> George Neuner <·········@comcast.net> wrote:
>> +---------------
>> | <···········@gmail.com> wrote:
>> | >case keyform {normal-clause}* [otherwise-clause] => result*
>> ...
>> | >
>> | >Why {normal-clause}* rather than just normal-clause*? ...
>> |
>> | By convention a token surrounded by curly braces indicates a named
>> | substitution - in this case the token, "normal-clause", should be the
>> | name of another production within the grammar.
>> +---------------
>>
>> Also see CLHS 1.4.1.2.3 "Additional Uses for Indirect Definitions
>> in Modified BNF Syntax" [which conveniently uses CASE as an example!],
>> where it notes that some of those "other productions" might be unused
>> in the formal grammar on the page where they're defined... but might
>> be referenced in the formal grammar elsewhere, or informally in the
>> descriptive text.
>
>I'm not so sure there this isn't just messy notation on my part.
>I'd have to go back and read carefully what my conventions were,
>(or maybe others have). But before anyone builds a shrine around
>something that could just be either a typo or an inconsequential
>equivalence not in most reduced form, one should at least consider
>the possibility of sloppiness.
There are as many variations of E(xtended)BNF as there are language
designers. But there are some conventions that have been established.
I didn't look at the productions in CLHS to see if they were used
consistently - I just assumed the conventions were being followed
given the time period when CL was standardized and the docs were
written.
>Also, sometimes this kind of thing creeps in when one is editing
>something [that might have been badly expressed protodoc] like:
> { normal-clause | otherwise-clause }*
>where it may be that I wanted to make sure the otherwise clause
>only went last and I removed part of the brace structure but then
>didn't edit out the braces. Or, perhaps even more likely, it could
>come from an early version that said:
> case keyform { normal-clause | otherwise-clause }*
> ccase keyform { normal-clause }*
> ecase keyform { normal-clause }*
>where braces were used in all three cases for reasons of parallel
>construction reason [where "parallel construction" is a term of art
>in the writing of literature, not programs, as in
>http://humanities.ucsd.edu/writing/grammar/21parallel.htm ].
>In the end, I think it's the kind of harmless stuff like
>writing (x)^2 meaning the same as x^2 in an infix language [which the
>BNF is]. One is only supposed to worry about extra parens in Lisp,
>where parens generally do more than group--they have often semantic
>effect. ;)
George
--
for email reply remove "/" from address