Re: errata/607: function returning signed integer/real/time/realtime

From: Eric Mahurin (eric_mahurin@yahoo.com)
Date: Fri Jul 30 2004 - 09:20:01 PDT

  • Next message: Eric Mahurin: "Re: errata/608: mintypmax_expression usage"

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

    From: Eric Mahurin <eric_mahurin@yahoo.com>
    To: etf-bugs@boyd.com
    Cc:
    Subject: Re: errata/607: function returning signed integer/real/time/realtime
    Date: Fri, 30 Jul 2004 09:18:44 -0700 (PDT)

     To write a lenient parser that accepts all legal
     syntax, the BNF is quite close. That is what I've
     been doing and reporting the issues. I think the
     issues I'm finding can be broken down into these
     categories:
     
     1. doesn't allow some valid syntax. Examples: extra
     semicolons in PATHPULSE constructs; inconsistent
     mintypmax usage.
     
     2. doesn't group items meaningful to the language.
     Examples: expression/event_expression (no regards to
     operator precedence)
     
     3. redundancies/ambiguities. Examples: #2 issues
     typically also are ambiguous; in A.6.2 "force" can
     take a net_assignment or a variable_assignment, but
     syntactically net_assignment is a subset of
     variable_assignment; if_else_if alternative for a
     conditional statement. I'll document these next.
     
     4. inconsistencies in the leniency. This really
     doesn't hinder making the parser. Example: this
     errata (function allowing the return signed
     integers/etc when nothing else allows it)
     
     5. lower-level token/whitespace/preprocessor issues
     (lexical analysis). I know this isn't part of the
     BNF, but having something solid here is necessary for
     the parser. Examples: all of the compiler directive
     questions I've had.
     
     I think you can break down the LRM in terms of a
     parsing and understanding meaning into these
     categories:
     
     - tokens/whitespace/preprocessor stuff: lexical
     analysis
     
     - BNF: syntactic analysis
     
     - all other qualifications in the LRM: semantic
     qualifications. Some of these can be handled during
     the parsing phase, but most will need to be done later
     (or checking after parsing an entire construct - i.e.
     module)
     
     --- Shalom.Bresticker@freescale.com wrote:
     
    > The BNF most definitely is not sufficient by itself
    > for a parser.
    > Not every syntax allowed by the BNF is actually
    > legal.
    > That was a deliberate decision of the Working
    > Group.
    > I think that in most of those cases, the text of
    > the LRM contains additional
    > restrictions.
    >
    > Shalom
    >
    >
    > > I'm about to bombard you with some more errata
    > items. It's almost as though nobody has built a
    > parser based directly on the BNF in the spec. Or
    > maybe they didn't report the errors.
    >
     
     
     
             
                     
     __________________________________
     Do you Yahoo!?
     New and Improved Yahoo! Mail - 100MB free storage!
     http://promotions.yahoo.com/new_mail
     

    This archive was generated by hypermail 2.1.4 : Fri Jul 30 2004 - 09:20:08 PDT and
    sponsored by Boyd Technology, Inc.