Talk:Backus–Naur Form
From Wikipedia, the free encyclopedia
 |
This article is within the scope of the WikiProject Philosophy, which collaborates on articles related to philosophy. To participate, you can edit this article or visit the project page for more details. | ||||||||
| ??? | This article has not yet received a rating on the quality scale. | ||||||||
| ??? | This article has not yet received an importance rating on the importance scale. | ||||||||
|
|||||||||
Contents |
[edit] BNF
The BNF of BNF is redundant. <Expression> is unnecessary, as its only production is <whitespace> and an <Or-Expression>. <Or-Expression> also begins with <whitespace>. Correct me if I'm wrong, but I think <Expression> should be eliminated and <Or-Expression> should be retitled <Expression>.
--Michael A. Ball 18:47, 17 July 2006 (UTC)
Hirzel, I think the "see also" is a bit redundant, but since you put it in, I'll leave it. It is my opinion that a "see also X" is nice but embedding the link in the article and explaining there *why* one should "also see X", is better. Having both seems a bit redundant to me, but that's just me. -- Jan Hidders 03:44 Aug 14, 2002 (PDT)
This translates into English as:
- A postal address consists of a name-part, followed by a street-address part, followed by a zip-code part.
- A personal-part consists of either a first name or an initial followed by a dot.
- A name-part consists of either: a personal-part followed by a last name followed by an optional "jr-part" (Jr., Sr., or dynastic number) and end-of-line, or a personal part followed by a name part (this rule illustrates the use of recursion in BNFs, covering the case of people who use multiple first and middle names and/or initials).
- A street address consists of an optional apartment specifier, followed by a street number, followed by a street name.
- A zip-part consists of a town-name, followed by a comma, followed by a state code, followed by a ZIP-code followed by an end-of-line."
Note that many things (such as the format of a personal-part, apartment specifier, or ZIP-code) are left unspecified here. If necessary, they may be described using additional BNF rules, or left as abstraction if irrelevant for the purpose at hand.
- Common US Postal rules (Publication 28, http://pe.usps.gov/text/pub28/welcome.htm) put the apartment number at the end of the line, not the front as shown here. Also, they specifically request that the last line not include a comma between the city and state. And there are various other nitpicky errors or omissions.
-
- But this is all getting into the detail of postal addresses, which is not the point here. This is all included just as an illustration of BNF, using an example that is common enough for people to easily understand it. T-bonham (talk) 07:45, 29 March 2008 (UTC)
Isn't personal-part specified? I didn't want to remove the mention of it being unspecified because I'm a beginner, but this one seems pretty obvious...
The "See Also" link Syntax Diagram page has been deleted, page history shows multiple deletes (with rubbish content) Should this link be kept?
[edit] The formal syntax is under "Further Examples"
The formal syntax is specified in thechapter "Further Examples", without exlanation.
I would prefer to have a formal syntax definition in one seperate chapter (named as such), and an additional informal explanation.
The informal explanation could be similar to what I found in the UML2.0 spec:
- All non-terminals are in italics and enclosed between angle brackets (e.g. <non-terminal>)
- All terminals (keywords, strings, etc.), are enclosed between single quotes (e.g., ‘or’)
- Non-terminal production rule definitions are signified with the ‘::=’ operator
- Repetition of an item is signified by an asterisk placed after that item: ‘*’
- Alternative choices in a production are separated by the ‘|’ symbol (e.g., <alternative-A> | <alternative-B>)
- Items that are optional are enclosed in square brackets (e.g., [<item-x>])
- Where items need to be grouped they are enclosed in simple parenthesis; for example:
-
(<item-1> | <item-2>) *
- signifies a sequence of one or more items, each of which is <item-1> or <item-2>
—The preceding unsigned comment was added by 82.174.19.103 (talk • contribs) .
[edit] Missing EOL in Example?
Shouldn't both options of the name branch include EOLs, or should the EOL be after the end of both options?
~ender 2007-05-12 19:40:PM MST —The preceding unsigned comment was added by 70.167.217.162 (talk) 02:35, 13 May 2007 (UTC).
- I agree. I have now added the EOL. Hendrik. 217.83.27.65 16:47, 20 June 2007 (UTC)
[edit] While it is Backus-Naur Form its proper name is Backus-Naur Format
w3, NASA --Adam1213 Talk 01:52, 2 August 2007 (UTC)
[edit] "<personal-part>" in Address Example
Unless the notation is counter-intuitive, the <personal-part> in the example given appears to me to be incorrect. I would expect that the definition would wish to apply either the whole of what appears after the OR "¦" symbol (an initial and a ".") or that which appears before the OR symbol (a first name). But not to glibly concatenate the "." to the result of what precedes this "." .
So <personal-part> (really a <first-name or initial part>) as I believe it was intended to be in the example, should not in my view be expressed: <personal-part> ::= <first-name> | <initial> "."
(Mail addresses are not yet specified the same way as some email addresses (e.g. christian-name.surname@emaildomain))
The <personal part>(= here 'first-name or initial part') of a snail mail address should surely be specified (in England anyway):
<personal-part> ::= <first-name> | <initial ".">
(or something like that? I'm (still) not knowledgable on this notation).
Perhaps its easier in words:
<personal-part> is:
EITHER
( The Initial followed by "." )
OR
(
The First name [not followed by "."]
)
i.e. NOT
EITHER of
( (
The First name
)
OR
( The Initial )
)
followed by "." . The important part to read in the above is the bracketing level. The layout unfortunately doesn't come out as I typed it.
This admittedly doesn't allow for multiple initials, but neither does the example given. I think my version is less wrong than the original.
I appreciate that this Wiki topic is not really about mail addresses, but it does not aid the education process if something secondary to the main argument is not right as the learner may think she has not understood the prime argument.
Thinkact 11:48, 9 September 2007 (UTC)
- Perhaps, as you say, the notation is counter-intuitive; but I do not see that we have a choice but to stick with it, as the article is in some sense about the notation. (Personally, I think it's quite intuitive that in a BNF a b | c d means (a b) | (c d), not a (b | c) d, but perhaps that's only because I'm used to it. *shrug*) —RuakhTALK 16:34, 9 September 2007 (UTC)
The BNF of BNF won't parse itself. The rule
<opt-whitespace> ::= " " <opt-whitespace> | ""
contains a list of expressions. The rightmost expression ("") does not fit the definition of expression in the grammar. "" is not a literal.
It would be better to allow a list to be an empty list:
<list> ::= <term> | <term> <opt-whitespace> <list> |
and then define opt-whitespace as:
<opt-whitespace> ::= " " <opt-whitespace> |
--Sérgio Carvalho 16:25, 3 March 2008 (UTC)
[edit] BNF of BNF
In the BNF of BNF, does the rule:
<line-end> ::= <opt-whitespace> <EOL> | <line-end> <line-end>
make sense? Are two consecutive <line-end>s really an option?
Why not hoist the left branch up to the <rule> rule:
<rule> ::= <opt-whitespace> "<" <rule-name> ">"
<opt-whitespace> "::="
<opt-whitespace> <expression>
<opt-whitespace> <EOL>
and delete the <line-end> rule?
24.5.187.137 (talk) 01:03, 28 May 2008 (UTC)
