8 ms·

Even as a pragma, a la "use strict"? "use stricter"?

BrendanEich 12y ago
No, because: 1. Modes are bad for implementations (this feeling was strong from V8 folks such as Erik Corry, but the new crew in Munich may not feel the same way), due to code branching burdens in testing and optimizing while keeping the complexity down. 2. Worse, what you propose would fork the language to double the testing burden for web devs (apart from engine implentors, item 1), since older browsers would ignore the useless expression statement. This already happened with ES5 "use strict", and created real world bugs (e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=631043 https://bugzilla.mozilla.org/show_bug.cgi?id=631043, there are more like this). Developers do not test all the combinations. Notice how a tower of M modes implemented via these string-expression-statement prologue directives can make a 2^M-fold testing burden.
- stupidcar 12y ago
  Aren't Google now proposing a bunch of new pragmas? http://www.2ality.com/2015/02/soundscript.html http://www.2ality.com/2015/02/soundscript.html
  - BrendanEich 12y ago
    As noted in item 1 ("new crew in Munich"), but these may both throw early errors, not let code get to runtime with different semantics (as ES5 strict did, due to arguments object and a few other changes), and use real pragma syntax, which will fail in old user agents. How can real pragma syntax work on the Web? Only by using a compiler such as Traceur or Babel, otherwise old browsers would choke on the `use types;` unquoted directive. Note how this can still complicate VMs, but it doesn't fork the test load for web developers. And if the type system results in early errors, plus better optimization with unforked runtime semantics, then the only burden on VM implementors is in the parser and type checker. We shall see how this experiment works, but in no way is it like `"use stricter";`.
    - matt_kantor 12y ago
      > use real pragma syntax, which will fail in old user agents > We shall see how this experiment works, but in no way is it like `"use stricter";`. I might be misunderstanding your comment, but stupidcar's link (http://www.2ality.com/2015/02/soundscript.html http://www.2ality.com/2015/02/soundscript.html) mentions `"use stricter;"` and `"use stricter+types;"` as mode flags, although it also contains a big disclaimer ("The final version of SoundScript may look and work completely different"). Has the syntax been changed since February? If so, I'm interested in reading about it (but my Google-fu is failing); got a link?
      - BrendanEich 12y ago
        That talk on which Axel Rauschmayer reported had some info from a presentation given by Andreas Rossberg of the V8 team to the last TC39 meeting. Here's the PDF: http://www.mpi-sws.org/~rossberg/papers/JSExperimentalDirections.pdf http://www.mpi-sws.org/~rossberg/papers/JSExperimentalDirect... There are two ideas: 1. A `"use stricter";` (originally "use sanity" :-/) prologue directive that would not change runtime semantics for code that passed all of static checks, (control flow dependent) dynamic exception-throwing tests, and runtime restrictions on object behavior. 2. A "SoundScript" mode, perhaps enabled by a `use types;` opt-in, or expressed some other way (per module?), that enables gradual type checking based on optional annotations inspired by TypeScript, but with TS-incompatible differences. Mode 1 might fly with TC39, because it does not fork semantics for code that passes all checks. But for real-world code, there will be divergence when run on old vs. new browsers, so I expect push-back in TC39 on this mode being expressed by a useless string expression statement. Mode 2 cannot be enabled by a fake-string-expression-statement "prologue directive".
        matt_kantor 12y ago
        Thanks! This looks promising. Gradual typing is something I've been wanting in JavaScript ever since ES4 got my hopes up.

No, because: 1. Modes are bad for implementations (this feeling was strong from V8 folks such as Erik Corry, but the new crew in Munich may not feel the same way), due to code branching burdens in testing and optimizing while keeping the complexity down. 2. Worse, what you propose would fork the language to double the testing burden for web devs (apart from engine implentors, item 1), since older browsers would ignore the useless expression statement. This already happened with ES5 "use strict", and created real world bugs (e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=631043 https://bugzilla.mozilla.org/show_bug.cgi?id=631043, there are more like this). Developers do not test all the combinations. Notice how a tower of M modes implemented via these string-expression-statement prologue directives can make a 2^M-fold testing burden.

stupidcar 12y ago
Aren't Google now proposing a bunch of new pragmas? http://www.2ality.com/2015/02/soundscript.html http://www.2ality.com/2015/02/soundscript.html
- BrendanEich 12y ago
  As noted in item 1 ("new crew in Munich"), but these may both throw early errors, not let code get to runtime with different semantics (as ES5 strict did, due to arguments object and a few other changes), and use real pragma syntax, which will fail in old user agents. How can real pragma syntax work on the Web? Only by using a compiler such as Traceur or Babel, otherwise old browsers would choke on the `use types;` unquoted directive. Note how this can still complicate VMs, but it doesn't fork the test load for web developers. And if the type system results in early errors, plus better optimization with unforked runtime semantics, then the only burden on VM implementors is in the parser and type checker. We shall see how this experiment works, but in no way is it like `"use stricter";`.
  - matt_kantor 12y ago
    > use real pragma syntax, which will fail in old user agents > We shall see how this experiment works, but in no way is it like `"use stricter";`. I might be misunderstanding your comment, but stupidcar's link (http://www.2ality.com/2015/02/soundscript.html http://www.2ality.com/2015/02/soundscript.html) mentions `"use stricter;"` and `"use stricter+types;"` as mode flags, although it also contains a big disclaimer ("The final version of SoundScript may look and work completely different"). Has the syntax been changed since February? If so, I'm interested in reading about it (but my Google-fu is failing); got a link?
    - BrendanEich 12y ago
      That talk on which Axel Rauschmayer reported had some info from a presentation given by Andreas Rossberg of the V8 team to the last TC39 meeting. Here's the PDF: http://www.mpi-sws.org/~rossberg/papers/JSExperimentalDirections.pdf http://www.mpi-sws.org/~rossberg/papers/JSExperimentalDirect... There are two ideas: 1. A `"use stricter";` (originally "use sanity" :-/) prologue directive that would not change runtime semantics for code that passed all of static checks, (control flow dependent) dynamic exception-throwing tests, and runtime restrictions on object behavior. 2. A "SoundScript" mode, perhaps enabled by a `use types;` opt-in, or expressed some other way (per module?), that enables gradual type checking based on optional annotations inspired by TypeScript, but with TS-incompatible differences. Mode 1 might fly with TC39, because it does not fork semantics for code that passes all checks. But for real-world code, there will be divergence when run on old vs. new browsers, so I expect push-back in TC39 on this mode being expressed by a useless string expression statement. Mode 2 cannot be enabled by a fake-string-expression-statement "prologue directive".
      - matt_kantor 12y ago
        Thanks! This looks promising. Gradual typing is something I've been wanting in JavaScript ever since ES4 got my hopes up.