On Wed, Jul 26, 2017 at 1:56 PM, Brendan Eich <brendan.e...@gmail.com> wrote: > Strict mode also made runtime-incompatible changes, e.g. arguments[i] not > aliasing i'th formal parameter, which required two-way testing while strict > mode adoption was nascent or partial (which of course many devs skipped). > > On Wed, Jul 26, 2017 at 9:53 AM Andreas Rossberg <rossb...@google.com> > wrote: >> >> The "ability to do sound static analysis" is not a binary characteristics. >> You can do analysis on JS. With strict mode you have a couple more >> invariants, so can do slightly better, but from my perspective it's not even >> close to a game changer. > > > Agreed (static analysis approximates runtime, so the ability to do it is of > course not binary -- many trade-offs).
Of course, no static analysis can be complete for all programs in a Turing complete language. At the time it was being debated, we couldn't assume closure integrity if a parameter could alias eval which made static analysis of even simple programs really really hard. It looks like both violations of closure integrity via indirect aliasing of eval got rolled into non-strict mode though. I was just confused. > From my memory of the meetings and online discussions, strict mode was not > meant to make static analysis significantly easier. More important was > enabling Caja (now SES) to "use strict" and do less work, static and at > runtime. Implementation and legacy loopholes continue to confound such > efforts :-). Fair enough. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
