Re: [IBIS] BIRD135: Add Boolean to BNF for IBIS-AMI

I don't see the urgency to push BIRD 135 through. It may be uncomfortable
that the spec has a Boolean Type and the BNF does not mention it. But Type
can also be Tap or UI, and the BNF doesn't have those either. Most likely
existing parsers are reading everything in as strings, possibly
auto-detecting numbers, then checking the Boolean values of strings on an as
needed basis by string comparison.

Going completely in the opposite direction, it is in my opinion questionable
that the various value types even need to be defined in the BNF at all. The
reason a grammar defines types is so that other definitions in the same
grammar can specify exactly what types are required for different parts of
statements. We don't have that. In our case each parameter in the AMI file
says what the Type of it's value is, and AMI parsers really have to
interpret the values based on that. The DLLs already know how to treat the
values for each named parameter, and I don't think they need the BNF to tell
them that the value strings must be treated as various types (but only you
the DLL know which types they are).

So my alternate proposal would be to remove the entire definition of value
from the BNF and just say it's a value string.

Having now thrown the monkey wrench, I'm willing to help. But I'd like to
hear from those who have written DLLs first.

Mike

On 7/15/11 1:53 PM, "Arpad Muranyi" <Arpad_Muranyi@mentor.com> wrote:

> 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 1993