NaN is lexed as a number, not as an identifier

[Razican]

Describe the bug
In #397, we modified NaN to be lexed as a number, and not as an identifier. This fixed the most common case of using NaN, that wouldn't work before, but it won't work for Number.NaN, among others.

To Reproduce
This now fails:

Number.NaN;

Expected behavior
This should produce NaN, since it's almost the same case, but it produces a parsing error.

Additional context
We will need to add the associated constant to the "Global" object and to the "Number" for this to work, and make sure that an identifier in the global scope tries to access the constant in the global object.

[croraf]

Can we make the lexer to resolve .<One or more letters> as a single token?

It looks to me that .<One or more letters> construct cannot have any other meaning than the field accessor?

// in lexer
                '.' => {
                    // . or ...
                    if self.next_is('.') {
                        if self.next_is('.') {
                            self.push_punc(Punctuator::Spread, start_pos);
                        } else {
                            return Err(LexerError::new("Expecting Token ."));
                        }
                    } else {
                        self.push_punc(Punctuator::Dot, start_pos);
                    };
                }

If this is true, we could remove Punctuator::Dot completly, and here produce something like a FieldDotAccessor('string') token here.

[Razican]

Can we make the lexer to resolve .<One or more letters> as a single token?

Well, there is two things here. The bug is just that it's lexed as an f64 and not an identifier. This can be easily solved by reverting #397. We now have NAN as a property of the global object, so it should "just work".

But, as you say, . is, as far as I can tell, always followed by a GetConstField string (if it's not part of ...). We could in theory optimise this by directly lexing the node instead of the punctuator.

But, the issue here is that . is considered a Punctuator by ECMAScript (spec). This means that in the future, this could be used to parse different things, and that logic should be part of the parser, the lexer should just be a fast tokenizer.

It's already pretty fast, in any case, since it generates the token list and the parser can just read it and decide what to do with the following identifier.

[croraf]

Yes, I think that makes sense, because NaN when encountered can always in the lexer be resolved as an Identifier, right?

My proposal was probably influenced by my thoughts that NaN can sometimes be a keyword or a numeric value, so that it cannot be uniquely identified and that the context knowledge (the preceding .) was necessary during lexing.

[Razican]

Yes, I think that makes sense, because NaN when encountered can always in the lexer be resolved as an Identifier, right?

Yep, as per the spec, it's an identifier, so I think that's the best way to proceed :)

[LuoZijun]

https://www.ecma-international.org/ecma-262/10.0/#sec-value-properties-of-the-global-object

Infinity, NaN and undefined are global property, not a number token.

[croraf]

Thanks @LuoZijun . Yes we proceeded to implement it like this as you can check in the linked PR. Although I didn't know "undefined" is the same. I thought "undefined" is a reserved keyword, but now I see it is same as NaN. Good point about Infinity and undefined.

I checked and the following works ok in Boa:

const a = {
  undefined: 5,
};

a.undefined