That follows from how (the) source code is parsed. The tokenizer (or:
scanner) sees
a = newb();
and applies
InputElementRegExp ::
WhiteSpace
LineTerminator
Comment
Token
RegularExpressionLiteral
repeatedly, resulting in the following tokens:
"a" " " "=" " " "newb" "(" ")" ";"
| | | | | : : :
Token WhiteSpace Token WhiteSpace Token Token Token Token
| | | : : :
IdentifierName Punctuator IdentifierName: :
: : :
Punctuator :
: :
Punctuator
:
Punctuator
<snip>
The lexical syntax specification says what valid strings can be
produced, which why they are called production rules. The preamble to
the syntax says that the source text is deemed to be a sequence of input
elements. Let us see what can be produced by two adjacent input
elements.
Assume the left hand one can't be a division operator (it makes no
difference here anyway) so we have
InputElementRegExp InputElementRegExp
One possibility is that each of these is a token so we have
Token Token
One possibility is that each of these an identifier name (ES5 naming
scheme) so we have
IdentifierName IdentifierName
One possibility is that an identifier name is a reserved word; another
is that it is an identifier, so we can have
ReservedWord Identifier
One possibility for a reserved word is a keyword, so we can have
Keyword Identifier
One possibility for a keyword is 'new'; one possibility for an
identifier is identifier start (to keep it simple), so we can have
new IdentifierStart
One possibility for an identifier start is a Unicode letter, so we can
have
new UnicodeLetter
Let us choose the letter 'b' for the Unicode letter, so we finally have
the adjacent input elements
new b
with NOTHING IN BETWEEN THE ELEMENTS.
Only the rule "The source text is scanned from left to right, repeatedly
taking the longest possible sequence of characters as the next input
element." can stop the parser treating this as the production forest
that was used to produce the input substring 'newb'.
John
