I believe I found an inconsistency problem with the definition of the syntactic grammar in C#.
This problem remains with the interim version of the c# 2.0 spec. and worries me a great deal.
<!– BEGIN TECHNICAL MUMBO JUMBO –>
Chapter 5 of the specification starts with the following phrase:
“… The lexical grammar defines how characters can be combined to form tokens (§9.4), the minimal lexical elements of the language. The syntactic grammar defines how tokens can be combined to make valid C# programs.”
The lexical element token is defined:
token:: identifier keyword integer-literal real-literal character-literal string-literal operator-or-punctuator
This means that a token may be one of the following: an identifier, a keyword, an integer literal, a real literal, a character literal, a string literal, an operator or a punctuator.
Please note the fact that the lexical element is literal is not one of those options.
The grammatical element primary-no-array-creation-expression is defined:
primary-no-array-creation-expression: literal simple-name parenthesized-expression member-access invocation-expression element-access this-access base-access post-increment-expression post-decrement-expression object-creation-expression delegate-creation-expression typeof-expression checked-expression unchecked-expression pointer-member-access pointer-element-access sizeof-expression
This means that primary-no-array-creation-expression may be a literal, in addition to the other options specified.
Now, giving that all grammatical elements must be made out of lexical tokens, it surprises me that the primary-no-array-creation-expression might be a literal, which is a lexical element which is not a token nor any descendant of a token!
<!– END TECHNICAL MUMBO JUMBO –>
What all this means is that the specification is in err.
However, there are two ways to correct this:
- Replace the list of literals token may be with just the literal lexical element.
This may have some implications that I have not yet foreseen, but it seems like the most logical of choises.
- Replace literal with the list of valid literals (those that can be tokens).
The downside of that is that you could not, taking it literally (no pun intended), do this:
bool b1 = true; bool b2 = false; object o = null;
since null, true and false will not be valid values as assignees.
Oh, the burden of decision. Glad it’s not mine (ok, not really; I actually want to be a part of the decision making).
I submitted the problem to ECMA TC39-TG2‘s Convenor, Microsoft’s Jon Jagger, who has confirmed that this is indeed a problem.
My only remaining question is: How has no one found out about this up until now? There have been too many compilers written to ignore this mistake.
My guess is that everyone just cut corners and were done with it. No idea why, though.