Export Expression & Statement types, add Literal & ShiftNode types?

[jsoverson]

It would be very helpful to have these exported along with an additional type that encompassed all valid Shift nodes (called ShiftNode ?) and a type that covers all Literals.

If there are no concerns I'll submit a PR.

[michaelficarra]

I'm not sure about the value of these additional types. What are some use cases?

[jsoverson]

ShiftNode is valuable for anything that takes or returns arbitrary Shift ASTs. Shift-refactor, shift-query, and shift-traverser need this (as does almost anything that would use Shift w/ TypeScript).

Expression/Statement is for differentiating statement/expression context for transformation and evaluation purposes. I use it for transformations in shift-refactor and in a meta interpreter.

Literal would be useful for shift-query where you may have a complex selector that has a component that just needs to be any literal. I use those commonly in when analyzing scripts. This one is less critical but figured I'd push for it given the opportunity.

[michaelficarra]

ShiftNode is valuable for anything that takes or returns arbitrary Shift ASTs

Only certain types of nodes are allowed in each position. I don't know when you'd want to not know anything more than "ShiftNode" statically. Or how that situation would arise in a well-typed program.

Expression/Statement [...]

Yeah Expression/Statement definitely make sense because there's positions that allow specifically those unions.

Literal [...]

Can you be explicit with which nodes you want to be included in Literal? People sometimes have different definitions of a "literal".

[bakkot]

Only certain types of nodes are allowed in each position. I don't know when you'd want to not know anything more than "ShiftNode" statically. Or how that situation would arise in a well-typed program.

Because you're doing something other than building a tree: for example, you might be building a map of nodes to their parents.

[jsoverson]

+1 to @bakkot's case which I have as well.

Shift-traverser needs this too. Every enter/leave takes a callback that gets an arbitrary node and its parent. Shift-refactor has similar use cases with callbacks.

For Literals, my immediate use case is around removing dead code or likely-to-be-dead code, like assignments of literals in statement context for variables that are never read in a meaningful way. It's a specific case, but seemed worth adding due to its mapping of the central Literal node in ESTree. If this holds a PR up then I'll drop it.

[michaelficarra]

Yeah I'm convinced by the non-tree use cases, thanks for that. The literals use case doesn't seem too well-motivated. For identifying dead code, you should be traversing into things like class decls/exprs to see if their methods have computed property names with effects, and that sort of thing. In Shift, we have a bunch of nodes that start with Literal, but I'm not sure what the criteria was for considering them "literal" other than maybe an artefact of staying close to estree when there was no reason to deviate. @bakkot Do you think there's an "obviously correct" union of node types that we'd call Literal?

[bakkot]

Do you think there's an "obviously correct" union of node types that we'd call Literal?

No. I wouldn't include that.

[michaelficarra]

K @jsoverson you want to send a PR for Node/Statement/Expression`?

[michaelficarra]

Fixed by #59.