On Feb 15, 2014 9:47 AM, "Brendan Eich" <[email protected]> wrote: > When I'm in a bad mood, I call it VisualCobol. It's painfully low-level and verbose, yet hard to verify. Let's hope that the JSCert work will help, and Allen has been common'ing subroutines. Whatever we call it, the spec language ain't great.
Tooling could help. I've filed a number of minor bugs against the draft spec about undefined identifiers, unused variables, etc. In theory at least those issues could be automatically linted. It's tempting to say that at some point JS should be defined in terms of "core JS", a strongly typed (!) subset of the language. (Strongly typed because verification is the point. Alternatively you could just make an executable test suite normative...) FWIW I did a decent amount of work writing a JS runtime in "TurtleScript", a differently-minded JS subset. One could also write specs in/compile to asm.js but that's probably swinging the pendulum too far (and exposing a lot of unnecessary implementation). Ian Piumarta has done a lot of good work on self-hosting languages which look very similar to a proto-JS. > Using "-Speak" as a stem conjures Orwell. Not good. I'm sure you mean ungood, which is plusgood goodthinkful. >> I wrestled with the phrasing there. I think what I really mean is "avoid allocating new backing storage", since there are "new string primitives" returned regardless. If there's a better phrase for "string backing storage" I'd be glad to add that to my dictionary. > > What does "backing storage" mean? There are no new String objects in any event. There may be ropes or dependent strings under the hood, but that's all unobservable (apart from performance) implementation-land. The original text under review here was discussing an optimization of the String.at polyfill, so performance was indeed the point. --scott
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
