[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Backus-Naur Form for CIF
- Subject: Re: Backus-Naur Form for CIF
- From: Nick Spadaccini <nick@xxxxxxxxxxxxx>
- Date: Wed, 11 Oct 2000 06:06:38 +0100 (BST)
On Tue, 10 Oct 2000, Herbert J. Bernstein wrote:
Herb: I have cross posted to the wider developers list.
> Nick has posted a revised BNF. Here are some comments:
>
> 1. The data on the document is "19th September 2000". It needs to be
> updated to 10th October 2000 to avoid confusion about the 30 day clock.
Yep.
> 2. The production <DATA_HEADING> has an upper case non-terminal name, but
> is referenced as a lower-case non-terminal name, <data_heading>, in the
> <data_block> production. Since EBNF is normally case sensitive, it would
> be a good idea to fix one non-terminal string or the other. (The same
> observation applies to <DATA_NAME>.)
Corrected these and several others.
> 3. The production and comments for <data> are intending to convey the
> very important distinction between uses of non-terminal whitespace and
> whitespace which ends in line termination, but the comments use the term
> "space" while the production uses the non-terminal string <spaces>. This
> is an unfortunate choice of terminology, since the "standard" name for the
> ASCII character " " (32) is "SP", which is pronounced "space".
There is confusion here because I refer to the production as <spaces> when
I really mean <blank> (being SP TAB or VTAB). I have systematically
changed the production name to <blank>.
> 4. What handling should be specified for SAVE_ STOP_ and GLOBAL_ ?
> I would suggest we require parsers to recognize them (as well as DATA_ and
> LOOP_) and then to reject them as non-quoted strings, as the proposed BNF
> rejects LOOP_ as a non-quoted string. Otherwise we could end up with CIFs
> that would violate STAR rules.
One could argue why disallow strings which do not conflict with the
specification of the CIF language. But I agree with herb on this one. Even
though they are not CIF reserved words we should protect them on the off
chance that some features of STAR which the community may consider
adopting in the (long distant - bm) future will not corrupt legacy CIFs. I
have included the productions and (in text) disallowed these as non-quoted
strings.
> 5. A data heading is specified to allow any <non_blank_char> in the
> data block name. This would permit both quote marks and all the national
> characters in data block names. Is this intentional?
>
> 6. Similar comments as have been given for data headings apply to the
> production for <DATA_NAME>. For example, this BNF seems to accept
>
> data_'"'
>
> _"' '"'
>
> as a valid CIF. Is this intentional? Please note that we have another
> level of control over strange data names via the dictionaries, but if
> parsers are supposed to accept a very wide range of names, we should be
> clear about it.
The answer to 5 and 6 is yes as far as STAR is concerned. Again CIF may
wish to disallow such constructions but I can't really see the need.
I have also changed the BNF significantly, cleaning up a number of errors,
though you don't see them when you read the BNF in a certain mindset (they
had to do with grouping {} and the strict interpretation of the OR |).
I have explicitly defined the character set also, and tried to be more
consistent in the look of the BNF. Happy reading. The clock starts again,
you have one month before this version is accepted by COMCIFs.
.... your time starts ... NOW!
cheers
Nick
--------------------------------
Dr Nick Spadaccini
Department of Computer Science voice: +(61 8) 9380 3452
University of Western Australia fax: +(61 8) 9380 1089
Nedlands, Perth, WA 6907 email: nick@cs.uwa.edu.au
AUSTRALIA web: http://www.cs.uwa.edu.au/~nick
Reply to: [list | sender only]
- Prev by Date: Re: Backus-Naur Form for CIF
- Next by Date: Re: Backus-Naur Form for CIF
- Prev by thread: Re: Backus-Naur Form for CIF
- Next by thread: Re: Backus-Naur Form for CIF
- Index(es):