Mike,
Thanks for all the research on this topic. While your
argument is convincing that our BNF is incomplete, my
response is the same as before. BIRD 135 was written
to add the missing Boolean, and not to correct the
other problems, defining things, and the completeness
of the BNF, etc... (This is clearly captured by the
title of the BIRD). I still feel that we should leave
this BIRD as is, and deal with the other problems
separately.
Or, we can write a new BIRD with a new title which
would clean up the BNF and provide a full description
and definition for everything under the sun, including
Boolean, with the stipulation that BIRD 135 will be
voted down. But I would rather have someone else write
this BIRD, since I am not that great in the area of BNF.
Would you be interested?
Thanks,
Arpad
========================================================
-----Original Message-----
From: Mike LaBonte [mailto:milabont@cisco.com]
Sent: Friday, July 15, 2011 12:42 PM
To: Muranyi, Arpad; IBIS
Subject: Re: [IBIS] BIRD135: Add Boolean to BNF for IBIS-AMI
In the Open Forum meeting today I agreed with Arpad that this BIRD is
limited to BNF changes, and improvements to the definition of acceptable
Boolean values is a separate matter. However, looking at the full BNF for
AMI I am beginning to think it needs even more work.
The IBIS 5.0 spec has:
| The modified BNF specification for the syntax is:
|
| <tree>:
| <branch>
|
| <branch>:
| ( <branch name> <leaf list> )
|
| <leaf list>:
| <branch>
| <leaf>
| <leaf list> <branch>
| <leaf list> <leaf>
|
| <leaf>:
| ( <parameter name> whitespace <value list> )
|
| <value list>:
| <value>
| <value list> whitespace <value>
| <value>:
| <string literals>
| <decimal number>
| <decimal number>e<exponent>
| <decimal number>E<exponent>
In BNF, everything inside <angle brackets> is called a non-terminal. It is
called that because the definition of it is not yet complete. A terminal
definition specifies actual characters, which are not in angle brackets. An
exception is terms like "white-space", "lbracket", and other characters that
have to be built into the BNF language as symbolic names because BNF itself
is expressed using them.
Our BNF does not define the non-terminals <string literals>, <decimal
number>, and <exponent>. In the meeting I heard Bob make the point that if
we add <Boolean> to the BNF then we will have one more undefined
non-terminal (he might not have called it that).
Below my signature I have pasted the BNF that describes <literal> for C++.
Note that they don't use angle brackets, which is a bit confusing. They use
the style where anything not defined is a terminal that has to be taken
exactly as it appears. You can see that <boolean> is the last definition and
it either maps to exactly the words "true" or "false", or they made the same
mistake and left true and false undefined.
Anyway, the BNF in the IBIS spec is insufficient in that you could not pass
it to YACC or BISON to create a parser that is able to discriminate between
string literals, decimal numbers, or exponents. A complete BNF is usually
pretty long.
At this point I have to agree with Bob that we might not want to add Boolean
until we have a better handle on how complete our BNF should be. At a
minimum I would advise adding a definition for Boolean if <Boolean> is added
to <value>:
<Boolean>:
True
False
Mike
http://www.csci.csusb.edu/dick/c++std/cd2/gram.html
literal:
integer-literal
character-literal
floating-literal
string-literal
boolean-literal
integer-literal:
decimal-literal integer-suffixopt
octal-literal integer-suffixopt
hexadecimal-literal integer-suffixopt
decimal-literal:
nonzero-digit
decimal-literal digit
octal-literal:
0
octal-literal octal-digit
hexadecimal-literal:
0x hexadecimal-digit
0X hexadecimal-digit
hexadecimal-literal hexadecimal-digit
nonzero-digit: one of
1 2 3 4 5 6 7 8 9
octal-digit: one of
0 1 2 3 4 5 6 7
hexadecimal-digit: one of
0 1 2 3 4 5 6 7 8 9
a b c d e f
A B C D E F
integer-suffix:
unsigned-suffix long-suffixopt
long-suffix unsigned-suffixopt
unsigned-suffix: one of
u U
long-suffix: one of
l L
character-literal:
'c-char-sequence'
L'c-char-sequence'
c-char-sequence:
c-char
c-char-sequence c-char
c-char:
any member of the source character set except
the single-quote ', backslash \, or new-line
character
escape-sequence
universal-character-name
escape-sequence:
simple-escape-sequence
octal-escape-sequence
hexadecimal-escape-sequence
simple-escape-sequence: one of
\' \" \? \\
\a \b \f \n \r \t \v
octal-escape-sequence:
\ octal-digit
\ octal-digit octal-digit
\ octal-digit octal-digit octal-digit
hexadecimal-escape-sequence:
\x hexadecimal-digit
hexadecimal-escape-sequence hexadecimal-digit
floating-literal:
fractional-constant exponent-partopt floating-suffixopt
digit-sequence exponent-part floating-suffixopt
fractional-constant:
digit-sequenceopt . digit-sequence
digit-sequence .
exponent-part:
e signopt digit-sequence
E signopt digit-sequence
sign: one of
+ -
digit-sequence:
digit
digit-sequence digit
floating-suffix: one of
f l F L
string-literal:
"s-char-sequenceopt"
L"s-char-sequenceopt"
s-char-sequence:
s-char
s-char-sequence s-char
s-char:
any member of the source character set except
the double-quote ", backslash \, or new-line
character
escape-sequence
universal-character-name
boolean-literal:
false
true
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993Received on Fri Jul 15 10:54:12 2011
This archive was generated by hypermail 2.1.8 : Fri Jul 15 2011 - 10:54:26 PDT