List annotations

[Yoric]

For the moment, we have discussed the following annotations:

• has direct eval;
• let-bindings;
• var-bindings;
• captured names;
• directives.

[littledan]

I assume const, class, catch and function bindings are included under var and let bindings where appropriate, right? Note that sloppy-mode function hoisting is especially complicated.

[bakkot]

sloppy-mode function hoisting is especially complicated

Another advantage of not supporting sloppy-mode scripts!

[Yoric]

@littledan For the moment, the idea was to dispatch function to let or var depending on the case and to merge const with var. I may, of course, be missing something.

[littledan]

Yeah, modulo details that should work well, especially if you ban sloppy mode (sloppy-mode function hoisting would probably need special AST representation).

[Yoric]

For the moment, we are not planning to ban sloppy mode, as this would exclude a huge portion of the existing JS code.

[ljharb]

@Yoric it is, however, worth noting that the amount of existing JS code in sloppy mode that's run through a build process such that it'd be able to leverage the binary AST format is much, much smaller than the amount of extant sloppy code overall. Still nonzero, but i would expect it's not the majority of build-processed-code.

[bakkot]

@Yoric

For the moment, the idea was to dispatch function to let or var depending on the case and to merge const with var.

This is not sufficient to implement sloppy-mode block-scoped function hoisting as described in Annex B.3.3, which has... complicated semantics.

Separately, how would merging const with var work, especially given sloppy-mode dynamic scope? These two programs do not have the same semantics unless o has a scopable x property.

const x = 0;
with (o) {
  x = 1;
}

var x = 0;
with (o) {
  x = 1;
}

[syg]

@bakkot is right that const can't be merged with var. In the interest of making incremental progress, I recommend we punt on Annex B.3.3 until things are more mature.

I still think it's important to support sloppy mode code. But Annex B.3.3 on the other hand... perhaps we'll test the limits of "normative optional".

[Yoric]

My bad for the var / const mixup, I obviously misread a bit of the spec. Won't be the last :/

I wonder how much of a "simplified AST" we could use for subsets that are strict. That sounds pretty hard to specify, unfortunately.

[littledan]

There's definitely a lot of sites that depend on Annex B 3.3. I'd be a bit scared of effectively another language mode--removing this seems much more drastic than the delayed verification discussed elsewhere. IMO the design choice here should be about supporting all of sloppy mode or none of it, not parts.

[syg]

@littledan I admit I'm somewhat surprised to hear the dependence on Annex B.3.3. If web content forces our hand, then it is what it is. I would like us then to own up to the "normative optional" thing, though.

[ljharb]

I think if we care about sloppy code, it's going to be primarily sloppy web code, which requires Annex B.

[littledan]

Cc @erights

[littledan]

Maybe build tools can tell at JS code which would take advantage of it, and there's more flexibility than I am fearing. I can't be sure.

[erights]

How about we include the static analysis directives only for strict code. Sloppy code cannot be statically analyzed well anyway, and there's no reason for the binary ast format to pretend otherwise.

[littledan]

JS implementations tend to do a lot of static analysis on sloppy mode code, e.g. for scope resolution when possible. It is true that eval is worse in sloppy mode, but it's pretty bad in strict mode as well as everything must be closure-allocated. Generally, I don't see gigantic differences in static analyzability.