Re: errata/596: ambiguous operands in expressions (A.8.3)

From: Stefen Boyd (stefen@boyd.com)
Date: Mon Jul 26 2004 - 08:20:01 PDT

  • Next message: Karen Pieper: "errata/603: Revised generate proposal from 113"

    The following reply was made to PR errata/596; it has been noted by GNATS.

    From: Stefen Boyd <stefen@boyd.com>
    To: etf-bugs@boyd.com
    Cc:
    Subject: Re: errata/596: ambiguous operands in expressions (A.8.3)
    Date: Mon, 26 Jul 2004 08:19:03 -0700

    >Date: Tue, 20 Jul 2004 12:18:19 -0700
    >From: mail <mail@boyd.com>
    >Subject: Failed bug submission from Eric Mahurin <eric_mahurin@yahoo.com>,
    >eric_mahurin@yahoo
    >
    > >From eric_mahurin@yahoo.com Tue Jul 20 12:18:17 2004
    >Received: from web41114.mail.yahoo.com (web41114.mail.yahoo.com
    >[66.218.93.30])
    > by wa.boyd.com (8.12.8/8.12.8) with SMTP id i6KJIHKk012268
    > for <etf-bugs@boyd.com>; Tue, 20 Jul 2004 12:18:17 -0700
    >Message-ID: <20040720192153.41267.qmail@web41114.mail.yahoo.com>
    >Received: from [66.90.167.158] by web41114.mail.yahoo.com via HTTP; Tue,
    >20 Jul 2004 12:21:53 PDT
    >Date: Tue, 20 Jul 2004 12:21:53 -0700 (PDT)
    >From: Eric Mahurin <eric_mahurin@yahoo.com>
    >Subject: Re: errata/596: ambiguous operands in expressions (A.8.3)
    >To: Shalom.Bresticker@freescale.com
    >Cc: etf-bugs@boyd.com
    >In-Reply-To: <Pine.GSO.4.10.10407201734510.15991-100000@eagle>
    >MIME-Version: 1.0
    >Content-Type: text/plain; charset=us-ascii
    >
    >Shalom,
    >
    >It may be more confusing, but at least it conveys what
    >the operator operands are and is not ambiguous. For
    >example, try the expression a*b+c&d/e<f&&g==h. The
    >current BNF allows this to be interpreted a variety of
    >ways, but only one gives the correct meaning
    >(following the operator precedence).
    >
    >In general, what are the goals of the BNF? Here are
    >some things I can think of:
    >
    >1. allow all valid syntax (a given).
    >
    >2. disallow as much invalid syntax as possible. To
    >not complicate things too much some syntax issues
    >could be handled with verbage and treated as a
    >semantic issue instead of a syntactic issue. For
    >example a function_statement is defined as a
    >statement, but is qualified with certain rules from
    >10.3.4.
    >
    >3. Structure the syntax in a meaningful way. For
    >example, attributes could (almost) syntactically be
    >treated like optional separators between statements
    >and operators or almost comments/whitespace, but
    >semantically, they should be associated with what
    >follows, so that's where they are specified in the
    >BNF.
    >
    >4. Have no ambiguity so that every component of every
    >rule is clearly defined. It should be clear as to
    >what alternatives ("|"), options ("[]"), and number of
    >repetitions ("{}") are taken for any valid syntax.
    >
    >I assume #1 and #2 above are goals. I hope #3 and #4
    >are also. To use this BNF directly as a basis for a
    >parser, I think all of these goals need to be met.
    >
    >The current BNF for "expression" utterly fails these
    >#3 and #4 goals. scalar_timing_check_expression
    >(errata/237) also fails similarly. I've found a few
    >others that fail goal #4 and haven't mentioned those -
    >they are not as involved.
    >
    >- Eric
    >
    >--- Shalom.Bresticker@freescale.com wrote:
    > > After looking at this, I think the suggestion is
    > > much more confusing than the current BNF.
    > >
    > > Shalom
    > >
    > >
    > > > Here's my suggested BNF:
    > > >
    > > > expression ::= conditional_expression | STRING
    > > >
    > > > conditional_expression : logical_or_expression [
    > > "?" attrs expression ":" expression ]
    > > >
    > > > logical_or_expression ::= logical_and_expression {
    > > "||" logical_and_expression }
    > > >
    > > > logical_and_expression ::= bitwise_or_expression {
    > > "&&" bitwise_or_expression }
    > > >
    > > > bitwise_or_expression ::= bitwise_xor_expression {
    > > "|" bitwise_xor_expression }
    > > >
    > > > bitwise_xor_expression ::= bitwise_and_expression
    > > { ("^"|"~^"|"^~") bitwise_and_expression }
    > > >
    > > > bitwise_and_expression ::= equality_expression {
    > > "&" equality_expression }
    > > >
    > > > equality_expression ::= inequality_expression {
    > > ("=="|"!="|"==="|"!==") inequality_expression }
    > > >
    > > > inequality_expression ::= shift_expression {
    > > (">="|"<"|"<="|">") shift_expression }
    > > >
    > > > shift_expression ::= additive_expression {
    > > ("<<"|">>"|"<<<"|">>>") additive_expression }
    > > >
    > > > additive_expression ::= multiplicative_expression
    > > { ("+"|"-") multiplicative_expression }
    > > >
    > > > multiplicative_expression ::=
    > > exponential_expression ( ("*"|"/"|"%")
    > > exponential_expression }
    > > >
    > > > exponential_expression ::= unary_expression { "**"
    > > unary_expression }
    > > >
    > > > unary_expression ::= ( "+" | "-" | "!" | "~" | "&"
    > > | "~&" | "|" | "~|" | "^" | "~^" | "^~" )
    > > unary_expression
    > > > | primary
    > >
    > > --
    > > Shalom Bresticker
    > > Shalom.Bresticker @freescale.com
    > > Design & Reuse Methodology
    > > Tel: +972 9 9522268
    > > Freescale Semiconductor Israel, Ltd.
    > > Fax: +972 9 9522890
    > > POB 2208, Herzlia 46120, ISRAEL
    > > Cell: +972 50 5441478
    > >
    > > [ ]Freescale Internal Use Only [ ]Freescale
    > > Confidential Proprietary
    > >
    > >
    >
    >
    >
    >
    >
    >__________________________________
    >Do you Yahoo!?
    >Vote for the stars of Yahoo!'s next ad campaign!
    >http://advision.webevents.yahoo.com/yahoo/votelifeengine/
     
     --------------------
     Stefen Boyd Boyd Technology, Inc.
     stefen@BoydTechInc.com (360)666-6957
     www.BoydTechInc.com
     

    This archive was generated by hypermail 2.1.4 : Mon Jul 26 2004 - 08:20:35 PDT and
    sponsored by Boyd Technology, Inc.