kind field for Literal

[dead-claudia]

It is very useful for basic type checking, and IMO is a bit less hackish (and easier) than typeof node.value. Here's my idea:

interface Literal <: Node, Expression {
  type: "Literal";
  value: string | boolean | null | number | RegExp;
  // addition, the type
  kind: "string" |
    "boolean" |
    "null" |
    "undefined" |
    "number" |
    "regexp";
}

[sebmck]

I'm impartial to this since I wouldn't be able to rely on kind anyway in case the AST was mangled but I can very much see the benefits for other tooling. Also undefined shouldn't be in that list since it's an Identifier.

[dead-claudia]

I filed a bug out of uncertainty (this would be a modification of the original spec).

[michaelficarra]

Add "infinity" to distinguish infinity literals from other numbers? This would allow SpiderMonkey AST to be serialised to JSON. Also, agreed that "undefined" should not be there; there is no undefined literal.

[gibson042]

"infinity" seems like an abuse of this proposal. That Infinity and NaN cannot appear directly in JSON is a problem analogous to representation of ES6 regular expression literals in ES<6 runtimes.

"kind" has value on its own, but is insufficient to cover portability, which I think requires either Literal subtypes or "raw".

[michaelficarra]

@gibson042 The regexp issue has already been solved by #27. NaN isn't a problem because there's no NaN literal.

[dead-claudia]

I would also support a "raw" node as well.
On Mar 13, 2015 1:30 AM, "Michael Ficarra" notifications@github.com wrote:

@gibson042 https://github.com/gibson042 The regexp issue has already
been solved by #27 #27. NaN
isn't a problem because there's no NaN literal.

—
Reply to this email directly or view it on GitHub
#61 (comment).

[gibson042]

NaN isn't a problem because there's no NaN literal.

Is the same not true of Infinity?

[sebmck]

@gibson042

Nope, you can represent Infinity with a numeric literal. eg:

> 1e10000
Infinity

[gibson042]

Is that true in SpiderMonkey? esprima at least presents value: null in such cases, and represents both literal Infinity and NaN as Identifier.

Regardless, I maintain that kind is not the mechanism for addressing lossy representations.

[sebmck]

@gibson042 In acorn it does at least, sounds like an esprima bug.

[michaelficarra]

@gibson042: No, it doesn't. You're probably observing the JSON serialisation problem we're talking about. And Infinity and NaN are identifiers. Literal infinities are just very large numbers (around 2e308 and larger) that cannot be precisely represented by an IEEE double.

If you don't think kind is a good proposal, what backward-compatible alternative do you suggest?

[gibson042]

You're probably observing the JSON serialisation problem we're talking about.

D'oh, right you are. 😳

If you don't think kind is a good proposal, what backward-compatible alternative do you suggest?

I do think kind is a good proposal, just not kind: "infinity".

[dead-claudia]

I concur with kind: "infinity" being a bad idea, with backwards
compatibility being another concern.
On Mar 13, 2015 12:38 PM, "Richard Gibson" notifications@github.com wrote:

You're probably observing the JSON serialisation problem we're talking
about.

D'oh, right you are. [image: 😳]

If you don't think kind is a good proposal, what backward-compatible
alternative do you suggest?

I do think kind is a good proposal, just not kind: "infinity".

—
Reply to this email directly or view it on GitHub
#61 (comment).

[michaelficarra]

Backward compatibility with what? Who currently implements kind?

[dead-claudia]

Identifier("Infinity") versus Literal(kind: "infinity"). Tools already
depend on the former. That clarify?
On Mar 13, 2015 2:33 PM, "Michael Ficarra" notifications@github.com wrote:

Backward compatibility with what? Who currently implements kind?

—
Reply to this email directly or view it on GitHub
#61 (comment).

[sebmck]

@IMPinball We aren't proposing to parse the Infinity identifier as a Literal, that makes no sense. Infinite numeric literals would be given the "infinity" kind instead of "number".

[dead-claudia]

Oh. Thanks for clarifying, although I don't get exactly why such a
distinction is absolutely necessary, since infinity is a number, and
checking for an infinite literal specifically isn't that hard.
On Mar 14, 2015 12:25 AM, "Sebastian McKenzie" notifications@github.com
wrote:

@IMPinball https://github.com/impinball We aren't proposing to parse
the Infinity identifier as a Literal, that makes no sense. Infinite
numeric literals would be given the "infinity" kind instead of "number".

—
Reply to this email directly or view it on GitHub
#61 (comment).

[sebmck]

You can't serialise an infinite numeric literal to JSON.

[RReverser]

What about -Infinity, then? Do we need to add "-infinity" type for it, too?

Also, I'm not sure JSON serialization should be something that drives design of AST itself since, when it's really needed, you can implement callback for JSON.stringify that handles these edge cases.

[dead-claudia]

Adds to the list of reasons why I'm not sure kind: "infinity" is really
necessary. It's easy to check for, and in reality, raw is the best way to
serialize it to JSON, anyways.
On Mar 14, 2015 12:45 AM, "Ingvar Stepanyan" notifications@github.com
wrote:

What about -Infinity, then? Do we need to add "-infinity" type for it,
too?

Also, I'm not sure JSON serialization should be something that drives
design of AST itself since, when it's really needed, you can implement
callback for JSON.stringify that handles these edge cases.

—
Reply to this email directly or view it on GitHub
#61 (comment).

[sebmck]

Yeah and checking the type of value is easy too.

[michaelficarra]

@RReverser there are no negative number literals in JavaScript. -Infinity must be generated using unary negation.

[RReverser]

@michaelficarra Depends on whether AST node was parsed or generated and inserted. In {type: "Literal", value: num} having negative num was never specified as an invalid state, and AST transformers might very well insert such nodes into the tree.

[dead-claudia]

@RReverser Technically, a transformer or builder can still emit invalid ASTs. Nothing stops you from doing this, even though it's completely nonsensical.

ConditionalExpression(
  IfStatement( // invalid
    Identifier("Foo"),
    null,
    BlockStatement([])
  ),
  BlockStatement([ // invalid
    NewExpression(
      Identifier("Foo"),
      []
    )
  ]),
  Literal(0)
)

// Your invalid JS-ish result:
(if (Foo) {}) ? { new Foo(); } : 0

As for a negative numeric Literal, that would be an easy PR to make, although it would be breaking. Getting all the tools patched for that should be relatively easy, though. The Literal type does not specifiy that restriction, by the way.

[dead-claudia]

I do feel we are digressing from the topic, though. As for the current values (without undefined, which is parsed as an Identifier), is this okay? #63

[RReverser]

The Literal type does not specifiy that restriction, by the way.

That's exactly what I was pointing to by "having negative num was never specified as an invalid state".

[sebmck]

Closed via #63.