`kind` field for Literal #61

Closed
isiahmeadows opened this Issue Mar 13, 2015 · 27 comments

Projects

None yet

5 participants

@isiahmeadows
Contributor

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";
}
@kittens
Contributor
kittens commented Mar 13, 2015

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.

@isiahmeadows
Contributor

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

@michaelficarra
Contributor

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
Contributor

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

@isiahmeadows
Contributor

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?

@kittens
Contributor
kittens commented Mar 13, 2015

@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.

@kittens
Contributor
kittens commented Mar 13, 2015

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

@michaelficarra
Contributor

@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".

@isiahmeadows
Contributor

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
Contributor

Backward compatibility with what? Who currently implements kind?

@isiahmeadows
Contributor

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).

@kittens
Contributor
kittens commented Mar 14, 2015

@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".

@isiahmeadows
Contributor

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).

@kittens
Contributor
kittens commented Mar 14, 2015

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

@RReverser
Member

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.

@isiahmeadows
Contributor

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).

@kittens
Contributor
kittens commented Mar 14, 2015

Yeah and checking the type of value is easy too.

@michaelficarra
Contributor

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

@RReverser
Member

@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.

@isiahmeadows
Contributor

@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.

@isiahmeadows isiahmeadows referenced this issue Mar 14, 2015
Closed

Add `kind` #63

@isiahmeadows
Contributor

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
Member

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".

@kittens
Contributor
kittens commented Mar 18, 2015

Closed via #63.

@kittens kittens closed this Mar 18, 2015
@RReverser RReverser referenced this issue Jun 12, 2015
Closed

File node #91

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment