Re: how many async-modules can js-app practically load?
If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. I'm in an environment where it is still not practical to use ES modules, and have started work again on BravoJS, which implements the old CommonJS Modules/2.0 strawman. (Same primordial development soup as AMD, but with a different set of flaws; favouring correctness/compatibility instead of brevity) How I've solved this problem historically is to have some smarts on the server side, that feeds (transitive) dependencies of a module at the same time as the module. It will be interesting to play with that type of loader -- if possible -- once ES module loaders become well-defined/implemented/available. We also have to remember that loading via SCRIPT tags -- type=module or not -- is important to developers, so that we can load modules from CDNs and so on without cross-site security pain. Thanks, Wes On Sat, 25 May 2019 at 02:41, guest271314 wrote: > Have not tried babel or webpack. You can write the test to answer your own > inquiry and post the result at a gist. > > On Sat, May 25, 2019 at 6:34 AM kai zhu wrote: > >> Why would 50 separate
Re: Re: Proposal: native XML object support.
As a data point -- I was writing JavaScript applications with GPSEE, a server-side Spidermonkey embedding, for several years until recently. The design pattern was, for all intents and purposes, CGI. GPSEE has E4X capability. I used it a few times to generate xhtml documents. I never found a compelling application. Being able to use XML object literals honestly caused more problems than it solved. If I really needed XML interchange today, I would try really hard to represent it internally with javascript objects and render/parse it at the network boundary. The only two things I ever found useful in E4X was template strings (which we have in ES6 backticks now) and for each. Wes On Tue, 21 May 2019 at 19:58, Jacob Pratt wrote: > JSX doesn't necessarily need a vDOM. > > On Tue, May 21, 2019, 10:31 kai zhu wrote: > >> jsx is not terribly javascripty ... vs direct manipulation of the dom >> (using static-functions/handlers). >> >> it requires two extra ux-workflow transformations -- 1) transpilation and >> 2) virtual-dom manipulation, for the sake of oft-quoted faster >> dom-performance, which some like me are skeptical is true in modern >> browsers. >> >> -kai >> >> >> On Tue, May 21, 2019, 16:35 Andrea Giammarchi < >> andrea.giammar...@gmail.com> wrote: >> >>> People use JSX, which is basically E4X, so I'd argue the word useless is >>> not really appropriate. You can use E4X to produce HTML, the fact we're >>> talking XML is merely about the E4X background, but as you could produce >>> strings out of E4X you could do the same and have better templating out of >>> the box. >>> >>> But like I've said, I already use template literal tags, but those >>> strings don't get hints or highlights as if these were E4X, XML, or plain >>> HTML, which is the only cool thing I'd personally find useful. >>> >>> Maybe it's just a tooling issue though. >>> >>> On Mon, May 20, 2019 at 3:06 PM ViliusCreator < >>> viliuskubilius...@gmail.com> wrote: >>> > the client, it could still somehow shine in NodeJS though. The only way it can shine is only passing HTML objects as arg to website. That’s it. And still, you can use string to do that for you. People already use JSON and I don’t think they would use XML in Node js. There are already tons of libs for XML stuff, yet they don’t have a lot of downloads, as far as I remember. So basically, Node js doesn’t need XML. That would be useless. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss >>> ___ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How many ES5 environments are still in use today?
We still use ES5 for development, since our server-side platform (GPSEE) doesn't run on later SpiderMonkey (embedding API made massive changes a couple of years ago and we haven't had resources to update.massive changes) I am working closely with another company right now that uses NodeJS. It's nominally ES6, but ES6 modules are not available in typical deployments, which is a pretty major missing feature. Wes On 2 April 2018 at 15:18, /#!/JoePeawrote: > I'm curious to know how many pure ES% environments (with or without > non-standard features like __proto__, and without any ES6 features) are > still being used in the wild. > > Would this come down to a browser statistics lookup? I believe there are > other projects that use ES, like Rhino, Espruino, etc. Do you know of some > place to get such statistics besides for browsers? > > */#!/*JoePea > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How it feels to learn JavaScript in 2016
On 27 October 2017 at 01:48, kai zhuwrote: > es6 is essentially javascript++, like c/c++. you can't expect senior > c programmers to trivially transition projects to c++, or for existing > c toolings to automatically extend to c++. > > Really? I was in that particular boat at one point in my career. I typed extern "C" { } a lot. No big deal. Similarly, as a JS developer, both front and back end, I have figured out how to transition my projects from ES5 to ES6 in the most efficient way possible: I have done absolutely nothing, and they continue to work perfectly. In fact, I have ES3 code still running in the wild. Wes On 10/27/17, Mark wrote: > > kai, what do you think would've been a better alternative? (Honestly > > curious) > > > > On Fri, Oct 27, 2017 at 1:27 AM kai zhu wrote: > > > >> tc39 is partly to blame for promoting the perception of javascript > >> language instability, which promotes tooling instability. > >> > >> generators, es modules, destructing, let, fat arrows have caused > >> tremendous harm to tooling stability, which has made > >> frontend-development hell for everyone. > >> > >> > >> On 10/27/17, Jordan Harband wrote: > >> > aka "how it feels to learn"? > >> > > >> > A decent response: > >> > > >> https://medium.com/front-end-hacking/how-it-feels-to-learn-j > avascript-in-2017-a934b801fbe > >> > > >> > On Thu, Oct 26, 2017 at 3:38 PM, J Decker wrote: > >> > > >> >> (humor?) > >> https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016- > >> >> d3a717dd577f > >> >> > >> >> It all seemed so simple > >> >> > >> >> ___ > >> >> es-discuss mailing list > >> >> es-discuss@mozilla.org > >> >> https://mail.mozilla.org/listinfo/es-discuss > >> >> > >> >> > >> > > >> ___ > >> es-discuss mailing list > >> es-discuss@mozilla.org > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 <(613)%20542-2787> ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Officially support a shebang line
In gpsee (using spidermonkey), we allow executable programs exactly the same way as a shell script, and there is no real penalty from a JavaScript parsing POV. I'm not sure why node+v8 would be any different. We just hand over the script to the parser with the pointer pointing to the newline at the end of the shebang. This skips the syntax error and keeps the line numbers as expected. As Alexander Jones explains, this shebang support stuff is deep in unix, and arrives by virtue of the exec-and-friends system calls declared in unitstd.h. I suppose the one 'gotcha' here is that you can't have a module which can both act as a program and library. We have the similar limitations in C - we have a special object file which has a symbol named 'main' and usually load library code as DSOs - but I never really found that to be a significant limitation in real-world work. What is an example use-case that would take advantage of this proposal? Wes On 19 May 2017 at 10:25, Jan Kremswrote: > Sorry, mentioning support in syntax highlighters might have been > misleading. I am talking specifically about executable JavaScript scripts > and modules. It's a common pattern in node to have programs written in > JavaScript, with a shebang and the x flag set. > > I just mentioned editor / syntax highlighter support to say "this is > already de-facto part of real life JavaScript as it's understood by tools, > it's just missing from the spec". > > On Fri, May 19, 2017 at 1:44 AM Alexander Jones wrote: > >> It doesn't make any sense. The shebang is a UNIX way of declaring the >> interpreter for an executable script, not for hinting your syntax >> highlighter. If your file is not executable (as in, it can't be run with >> `./filename`, it shouldn't have a shebang). >> >> On 19 May 2017 at 02:44, Jan Krems wrote: >> >>> Tried to search past proposals for this but couldn't find one The short >>> version: Most editors / syntax highlighting engines, non-engine parsers, >>> node.js - they all support a leading shebang line in .js files. With the >>> advent of ES6 modules it's the final holdout where node has to patch the >>> script source to make V8 parse the code (and thus producing a mismatch >>> between what's on disk and what the engine sees). >>> >>> Is there a downside to allow any script or module to begin with the >>> magical #! bytes? It should not break existing scripts because it's invalid >>> syntax today & the parse overhead should be fairly limited. >>> >>> ___ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
If anybody wants to play with MT ES (I'm not saying I think this is a good idea) -- you might want to dig up a ~ten-year old version of Spidermonkey, perhaps the JS 1.7 release (MT "safety" broke with Array Extras). Then add this code, which implements a basic Thread class: https://github.com/wesgarland/gpsee/blob/master/modules/thread/ (hopefully that code builds without too much effort...I stopped using it as soon as it was finished, I did not find the paradigm useful in my work). The result is lock-free property access (anarchy!) on a global object shared across operating system threads. You might be able to then prototype a smarter API in ES3 and see how you like it. I think you might also be able to try similar experiments with Rhino using Java threads. Wes On 13 March 2017 at 00:19, Isiah Meadowswrote: > For prior discussion on a fairly similar concept, see my proposal [1] > and related thread [2]. > > [1]: https://gist.github.com/isiahmeadows/a01799b4dc9019c55dfcd809450afd24 > [2]: https://esdiscuss.org/topic/module-based-parallel-js-strawman > - > > Isiah Meadows > m...@isiahmeadows.com > > > On Sun, Mar 12, 2017 at 10:14 PM, /#!/JoePea wrote: > > > > On Sun, Mar 12, 2017 at 7:11 PM, /#!/JoePea wrote: > >> > >> Leo's idea that JavaScript code as it is today won't be impacted when > >> async functions are run in separate threads is interesting. > > > > > > I meant, "Leo's idea that JavaScript code as it is today can work exactly > > the same (f.e. async functions) while behind the scenes be threaded > without > > impacting end JS-devs is interesting." > > > > > > /#!/JoePea > > > > ___ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
There is no requirement for a host environment to use any kind of serialization for worker threads. It's completely fine to pass messages which are binary in nature. In fact, I have passed C structs as messages between JavaScript workers. I don't know why you think this is a fight. You should understand that you are proposing a very, very, very significant modification of the ES standard and you have not yet defined a problem which this work would solve. Wes On 3 November 2016 at 14:19, Leo Dutrawrote: > Workers need serialization, threads would not. > > In Node, lack of threading requires a prior spawn of a bunch of native > processes and manually build a tasking pool. > > Web Workers spawn a specific script (if you respawn the caller you are > doing dirty job). > > Maybe we should fork projects like the one Isiah brought to us and > headbang compiling it with the lovely gyp. > > So much emotion. Much doge work. So delicious. > > You could simply spawn a thread in almost the same way we use Node > streams... > > but I won't fight 10 guys alone. > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
Please do. I have also done some work in this area. I have also implemented asynchronous POSIX signals (fraught with peril) and fork(). Entertaining stuff. My major problem has always been entrainment of crap from the global object. Although it has been a few years since I looked at this (slightly before ES5 release). Wes On 2 November 2016 at 16:28, Isiah Meadowswrote: > I'll post it to the list when it's ready, though. > > On Wed, Nov 2, 2016, 16:27 Isiah Meadows wrote: > >> I've been working on another idea for parallelism that also leverage >> modules, but doesn't involve workers. It will enable read-only resource >> sharing of direct object instances across threads, using realms, a built-in >> concept of thread ownership, and atomicity for ensuring thread safety. It >> also allows for blocking calls for individual atomic access. >> >> On Wed, Nov 2, 2016, 16:00 Leo Dutra wrote: >> >> We could think in a pool of workers with dynamic code execution or >> propose, in JS spec, points where multithreading is recommended. >> >> Anyway... looks like community is OK with the current state and that's >> more than enough. >> >> Good to see interest, anyways. >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal of Multithread JavaScript
I'm still confused about what problem we are trying to solve here. I had pthreads-style JS running in JS 1.7 many years ago ( https://github.com/wesgarland/gpsee/tree/master/modules/thread), and after investing quite a lot of time in making it work, I found that it wasn't really all that useful in solving any problems I had at the time. Or since. Mostly it was written for problems I thought I had, because I was a C developer trying to bend JS to fit old thought patterns. Lately, I have been using messaging passing a la DOM workers when I need parallelization and find it quite useful. Incidentally, there is no "single thread dogma". I don't know where you get this idea. Running multiple threads of unrelated JS is completely supported by the existing spec and at least one of the engines. Finally, Message Passing is not a JS problem either, IMO. It's a host environment problem. This is why, for example, we have DOM workers and not JS workers. If you want workers for some other (ie non-browser) environment, just write it. It's not hard, and it doesn't need to be part of the language. Wes On 2 November 2016 at 13:32, Florian Böschwrote: > On Wed, Nov 2, 2016 at 6:16 PM, Bradley Meck > wrote: > >> I'm fine with co-routines, just explicit ones (which we currently have >> via generators and async functions). Implicit ones make it hard to reason >> about if a variable needs to place guards prior to performing any action if >> actions pop the stack in order to do a co-routine pause/resume. >> > As I've illustrated, the natural tendency of explicit tagged asynchronous > code combined with proper software engineering (separation of concerns, > modularity, reuse, interfaces, encapsulation etc.) will be to infect most > code with it, until the distinction of "explicit" becomes entirely > meaningless. > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Thought about const
How often do you type const in a day? Saving 2 characters will save you 250ms assuming you are a decent keyboardist. I'll trade 250ms of typing for clarity any day. Wes Sent from my iPhone On Aug 28, 2016, at 08:00, Cyril Auburtinwrote: After a year of using `const`, I got used to it, but even with that I often feel losing time using it, with those 2 additional chars. It's really unfortunate because it's by far the most frequently used for variables assignments. It's also really close to *cons*ole(.log,...), annoying with auto-completers Thing are probably frozen at this time, but `cst`, `ref`, `val` would have been interesting ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Language design
That root post ignored compatibility constraints that have been discussed to death over the years, and just glibly asserted that == and === could be changed. The last time == and === were changed (JS 1.1-1.2-1.3) I was a pretty green developer building a very large DHTML application. I lost many nights of sleep trying to figure out why my code worked on one version of Netscape but not the other. You can't change stuff like that, we have paid the price to learn that lesson! The OP also spoke about fromCodePoint vs fromCharCode. It is necessary, IMO, to be able to manipulate both the underlying bytes and Unicode. I bumped into a related issue on our Server Side solution this week, importing malformed UTF8. Our platform has a big switch which changes how we handle C strings, and both modes of operation were necessary to analyze and resolve the problem. I'm looking forward to upgrading to ES6. I'm building large, somewhat complex, applications that share ES5 libraries and data on the browser and server. I am looking forward to features like default parameters, destructuring assignment (we have this in the server and like it), better modules (although there will be migration pain), and template strings. I'm sure there will be stuff I don't need - but that's okay, I just won't use it. Wes So, I don't believe you agreed with that noise. Am I mistaken? If your point is that Object.is does not pull its weight, make a stronger case for why people should have to write it by hand. You missed that Object.is(-0, +0) (and with arguments transposed) is false, while -0 === +0. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleSpecifier: include .js or not?
Some food for thought from a non-standard use-case. In GPSEE, we can require(module) - but we support both modules written in JavaScript, and modules written in C (technically, any compiled binary with the correct C API), or both. We dlload(module.so) (if present), then interpret module.js (if present) as part of the module loading procedure. So, from my POV, loading a module from script with the extension .js is not ideal. If you are going to assign meaning to the extension, you must think about what it means. In our case, it indicates the file type to load, and the implementation of the library is not relevant to the library user - only the API matters. And if you are only ever going to allow one extension type, then there is no point to typing .js on the end of every module name. In my opinion, the ModuleSpecifier should be fed the module name, and is it up to the loader to munge the filename (eg by adding .js) as it sees fit. Wes ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Q: Lonely surrogates and unicode regexps
Some interesting questions here. 1 - What is a character? Is it a Unicode Code Point? 2 - Should we be able to match all possible JS Strings? 3 - Should we be able to match all possible Unicode Strings? 4 - What do we do if there is a character in a String we cannot match? 5 - Do unmatchable characters match . ? 6 - Are subsections of unmatchable strings matchable if they contain only matchable characters? It is important to remember in these discussions that the Unicode specification allows strings which contain unmatched surrogates. Do we want regular expressions that can't match some Unicode strings? Do we extend the regexp syntax to have a symbol which matches an unmatched surrogate? How about reserved code points? What happens when they become assigned? On 28 January 2015 at 05:36, Marja Hölttä ma...@chromium.org wrote: Hello es-discuss, TL;DR: /foo.bar/u.test(“foo\uD83Dbar”) == ? The ES6 unicode regexp spec is not very clear regarding what should happen if the regexp or the matched string contains lonely surrogates (a lead surrogate without a trail, or a trail without a lead). For example, for the . operator, the relevant parts of the spec speak about characters: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-atom https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-charactersetmatcher-abstract-operation https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-canonicalize-abstract-operation E.g., “Let A be the set of all *characters* except LineTerminator.” “Let ch be the *character* Input[e].” But is a lonely surrogate a character? According to the Unicode standard, it’s not. If it's not, what will ch be if the input string contains a lonely surrogate in the relevant position? Q1: Are lonely surrogates allowed in /u regexps? E.g., /foo\uD83D/u; (note lonely lead surrogate), should this be allowed? Will it match a lead surrogate inside a surrogate pair? Suggestion: we shouldn't allow lonely surrogates in /u regexps. If users actually want to match lonely surrogates (e.g., to check for them or remove them) then they can use non-/u regexps. The regexp syntax treats a lonely surrogate as a normal unicode escape, and the rules say e.g., The production RegExpUnicodeEscapeSequence :: u Hex4Digits evaluates as follows: Return the character whose code is the SV of Hex4Digits. - it's also unclear what this means if no valid character has this code. Q2: If the string contains a lonely surrogate, what should it match? Should it match .? Should it match [^a] ? (Or is it undefined behavior?) Test cases: /foo.bar/u.test(foo\uD83Dbar) == ? /foo.bar/u.test(foo\uDC00bar) == ? /foo[^a]bar/u.test(foo\uD83Dbar) == ? /foo[^a]bar/u.test(foo\uDC00bar) == ? /foo/u.test(bar\uD83Dbarfoo) == ? /foo/u.test(bar\uDC00barfoo) == ? /foo(.*)bar\1/u.test(foo\uD834bar\uD834\uDC00) == ? // Should the backreference be allowed to match the lead surrogate of a surrogate pair? /^(.+)\1$/u.test(\uDC00foobar\uD83D\uDC00foobar\uD83D) == ?? // Should we allow splitting the surrogate pair like this? Suggestion: a lonely surrogate should not be a character and it should not match . or [^a] etc. However, a lonely surrogate in the input string shouldn't prevent some other part of the string from matching. If a lonely surrogate is treated as a character, the matching rule for . gets complicated and difficult / slow to implement: . should not match individual surrogates inside a surrogate pair, but if it has to match a lonely surrogate, we'll end up needing lookahead and lookbehind logic to implement that behavior. For example, the current version of Mathias’s ES6 Unicode regular expression transpiler ( https://mothereff.in/regexpu ) converts /a.b/u into /a(?:[\0-\t\x0B\f\x0E-\u2027\u202A-\uD7FF\uE000-\u]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF])b/ and afaics it’s not yet fully consistent wrt lonely surrogates, so, a consistent implementation is going to be more complex than this. If we convert the string into UC-32 before matching, then the lonely surrogate is a character behavior gets easier to implement, but we wouldn't want to be forced to do that. The intention behind the ES6 spec seems to be that strings can / should still be stored as UC-16. Converting strings to UC-32 before matching with /u regexps would require an additional pass over the string which we'd want to avoid, and converting only when strictly needed for the lonely surrogate is a character implementation adds complexity. E.g., with some regexps we don't need to scan the whole input string to find a match, and also most input strings, even for /u regexps, probably won't contain surrogates (to find that out we'd also need to scan the whole string, or some logic to fall back to UC-32 matching when we see a surrogate). BR, Marja
Re: Machine readable specifications
The specification is hard enough to digest for average developers now; I'd hate to point one of my guys at a machine-readable document when he's having trouble with some corner-case. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On 22 March 2013 08:41, gaz Heyes gazhe...@gmail.com wrote: You wouldn't do that, you'd point them to the human readable form. The machine version is specifically designed to be read by machines with low overhead to update functionality without touching code. Is there a formalized way to translate between the human and machine-readable specifications? If they are found to have different meanings (not hard to imagine), which specification would be considered authoritative? -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 10 biggest JS pitfalls
You did not include variants of var i, a=[]; for (i=0; i 10; i++) { a.push(print(i)); } print(a[3]); /* output is 9 */ in your list. I see related bugs on a regular basis. The other place I see regular bugs by intermediate coders is related to 'this' in events; but I'm not sure if we can count that as a JS problem or a DOM bug (Is that 9c in your list?) -- function A() { this.a = 123; } A.prototype.p = function {alert(this.a)}; window.onclick = new A().p; IIRC, clicking will alert undefined, as the event handler is invoked with this as the event. IME, this is not what programmers mean when they write that. We can work around it by changing the constructor: function A() { this.a = 123; this.p = this.p.bind(this); } but of course now we are over-allocating for no good reason IMO. Very frustrating. #3 on your list is entertaining, I have been told that == is faster than === in at least one implementation, because that's what sunspider tests. On 30 December 2012 16:22, Axel Rauschmayer a...@rauschma.de wrote: [Starting a new thread, just in case.] I made a list of the 10 biggest JS pitfalls and most of them will be gone under ES6. Much less to worry about, much easier to learn. Could you share your 10-biggest list? 1. Both undefined and null [not too much of a problem, easily learned] 2. Truthy and falsy values [not pretty, but I’ve grown used to them and the convenient but sloppy “has a value” checks via `if`] 3. == [easy fix: always use ===] 4. Parameter handling [fixed in ES6] 5. Array-like objects [not completely fixed (DOM...), but `arguments` becomes obsolete in ES6] 6. Function-scoped variables [`let` FTW in ES6] 7. Accidental sharing of data [for-of will help in ES6] 8. Creating sub-constructors is messy [fixed via classes and `super` in ES6] 9. `this` in non-method functions: 9a) Referring to the `this` of a surrounding method, 9b) accidentally creating globals by forgetting `new`, 9c) using methods as callback functions [(a) and (b) fixed by ES6 arrow functions and ES5 strict mode] 10. The for-in loop [simple rule: avoid if you can, already possible in ES5] Thus: 1-3 won’t go away soon. 4-10 are mostly eliminated by ES6. Deliberate omissions: - Implicit conversions are messy (and a superset of pitfall #2), but seem to surprise people much less than the above items. - Modules close another important hole in JavaScript, but I wouldn’t consider that hole a pitfall. There are more pitfalls, but these seemed the biggest ones. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@iterator in arguments object
Arguments object is used here to fill the rest void, but also as an argument to apply (after converting into a real array) when writing wrapper functions; eg monkey patches, userspace profiling, etc. Is there an ES6 way to use apply on rest params? If not, arguments must live on. Sent from my iPhone On 2012-12-23, at 12:48, Brandon Benvie bran...@brandonbenvie.com wrote: Yeah good point, and you don't even need to dump all the named params. In light of this, I think its feasible to pronounce the arguments object in ES6 as vestigial and ready for retirement (except for all the legacy code of course). ES6 claims another victim: [object Arguments]. On Sunday, December 23, 2012, Brendan Eich wrote: You could always use an explicit rest parameter as the only formal parameter and still dispense with arguments in new code. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Modules: suggestions for improvement
On 24 July 2012 05:03, Claus Reinke claus.rei...@talk21.com wrote: Hm, I hadn't thought about that, but my intuition tells me that there should be an export object for every module, with just the exports, and that this export object should be accessible from the module object. Being able to access the export object from the module object enables a pattern we use locally, which is roughly require(myModule).configParameter = xyz; or require(myModule).errorReporter = function(err){alert(err)}; exports.errorReporter, exports.configParameter are then used heavily within the module -- normally, they are not even set by the user, but they there in case the user needs to override some behaviour. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Fwd: delay keyword
On 5 July 2012 11:19, Patrik Stutz patrik.st...@gmail.com wrote: Oh I didn't know that Isaac is also unhappy with the whole javascript module thing. I tought that, since there already so much modules for node.js it is pointless to ask them to change their module system, so that node modules also could be used in the browser, so I asked you to give me a JavaScript feature than allows me to implement node's module system in the browser. I'll bet that there at least 1,000 times more web pages out there that depend on JavaScript's run-to-completion semantics than there are node.js modules. As for using Node modules in the browser, provided Node uses CommonJS Modules/1.0 modules (I believe it does), then you might want to look at the draft of a non-standard specification called CommonJS Modules/2.0-draft8 at http:/www.page.ca//~wes/CommonJS/modules-2.0-draft8. To summarize: - Works fine on browser - Works fine on server - Does not alter *any* semantics of valid /1.1.1 modules - Requires a trivial two-line change for each module (and one of those lines is closing brace, close paren, semicolon). I have implemented most of this spec in BravoJS and it has also been implemented in at least one other project, NobleJS. I have implemented it on the server on top of GPSEE's /1.1.1 module system, with a trivial patch to module.constructor. And I have built two major systems on top of BravoJS + GPSEE using Modules/2.0 modules shared between the browser and the server. BUT: interestingly, the import keyword also seems to be synchronous. So, I think behind the scenes there still would have to be something like a delay function to make it non-blocking. Or am I missing something? import is no more synchronous than var. What you are missing is that ES modules do not do demand-based (lazy) loading, like CommonJS *can* on the server (the spec does not require it, modulo maybe require.paths). All the dependencies in ES modules are statically resolved before any code runs. Where ES modules differ from current browser-platform module systems derived from CommonJS is that there seems to be no facility to lazy-load modules. Modules/2.0-draft, AMD (require.js), etc, all have some kind of eager module loading, although Modules/2.0 delays initialization to preserve the Modules/1.1.1 execution semantics. Everybody CommonJS-derived on the client seems to have lazy module loading, too -- but the interesting observation from my POV is that is that lazy module loading on the client seems rather unused. I know I have never used it, and neither has anybody on my team. Has anybody here? Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Modules: suggestions for improvement
On 27 June 2012 15:45, Kevin Smith khs4...@gmail.com wrote: By implementing it in SpiderMonkey! :) That's cheating! : ) A social note: designing the module system for ES6 is a difficult position to be in because there's already a more or less de facto module system in place (derived from CommonJS). It's like an empty field has been transformed into a garden by the local community, and then the owner of the plot wants to plow it up to create a better garden. Professional gardeners who feed millions plow up their gardens on a regular basis. So-called green manure, usually a nitrogen-fixing legume such as white clover, is grown after the money-making crop. This crop will add nitrogen (a key element in plant growth) from the atmosphere into the soil through the action of bacteria growing in its roots. Then this crop is plowed under, allowing it decompose to add organic matter to the soil before the next crop is sown. Similarly, while I have a *LOT* of time, money, and effort invested in and around the CommonJS ecosystem, I eagerly await the addition of a native module system to the language. The CommonJS experience helped to generate a lot of fertile ideas and willpower in the community, and when it is time for a better crop to be sewn, I see no reason not to plow it under in order to grow something better. Remember that CommonJS is not all about modules -- CommonJS modules only a means to and end, which is to create a base-level environment for executing ES code on a wide variety of host platforms. It's impossible to have large systems without modules. There are some serious issues which remain to be addressed with CommonJS modules, in particular, good ways to handle the global var scope, which cannot be addressed in the browser... and to address them on the server, I had to do some things to SpiderMonkey which would probably make Brendan cry. One thing I hope we can still have in ES6 modules, though, is the ability to lazy-load modules in a server-side context without altering the semantics of the program. I'll have to give that some thought in the future. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Modules: suggestions for improvement
On 27 June 2012 17:21, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: Certainly you shouldn't have to create a userland loader in order to get examples like I've written to work. You should only ever need to create a loader if you want to customize things, such as redirecting some things to localStorage, or setting up a sandbox. Hopefully it will be possible to create userland loaders somehow which can fetch multiple modules at once. We are able to fetch multiple CommonJS modules at once, often satisfying an entire dependency tree with a single HTTP 304 status response. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Modules: suggestions for improvement
On 27 June 2012 17:40, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: What request do you send to ask for multiple modules? We send a request like /methods/modules?root=pathto/mystuffid=/sha256id=/auth/password The client canonicalizes each CommonJS dependency to its full (canonical) path and tells the server where the module system root is. The server then examines each module last modification time, comparing against the Last-Modified-Since header. Dependent modules are likewise examined recursively. If any module is newer, all of the modules are sent, otherwise, an HTTP 304 response is returned and the browser reads all modules from its cache. And does this work for the non-cached situation (that is, how did the client get to the place where 304 was the right thing -- by doing multiple requests previously?)? Precisely. This pattern is obviously more useful for some sites than others. But I think it's interesting enough to mention. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Modules: suggestions for improvement
On 26 June 2012 16:45, Kevin Smith khs4...@gmail.com wrote: Hi Isaac, I share some of your concerns as well. I like the idea of import just returning an object, which can be destructured using let. I also like the idea of eliminating the import * syntax. However, I think that dynamic exports (export expression) might not be as useful as it seems. In my modules, I use the export expression form for the following reasons: 1. When I want to export a single function (perhaps a constructor), and I don't want importers to unnecessarily repeat the function name: var MyClass = require(MyClass).MyClass; // Boo! var MyClass = require(MyClass); // Better! var { MyClass } = require(MyClass); // Best! Best of both worlds! My code is full of this. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Modules: suggestions for improvement
On 26 June 2012 18:36, Aymeric Vitte vitteayme...@gmail.com wrote: Node.js's way is good, except the transitive dependency issue mentioned in your post which in some cases indeed can cause problems. Does Node not handle transitive dependencies per CommonJS Modules/1.0? What I find bad (1) is the need of VMs, let's take node.js's one, it's calling c++ stuff, calling itself js's stuff, and at the end things are coming back to js (with some imperfections like node.js's VM not binding things correctly in some cases) Can you explain this in more detail? I don't really understand what you're getting at . -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Yes, we could make ?? and ??= do the same for null as for undefined. I'm not sure that's the right choice, but it's a choice. Introducing yet another way to think about values in ES is not going to help most programmers. We already have to think about thinks like undefined and falsey -- what's been proposed here is an operator that mysterious works on something halfway between the two. Some folks may not see the need to differentiate between the two, but as somebody who talks to databases with ES -- there is a world of difference between null and undefined. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On 13 June 2012 03:45, T.J. Crowder t...@crowdersoftware.com wrote: Is the reason for using ?: rather than ?? because we may want it for my desired second ternary? E.g., from my other message: Something else to consider; if we use (a ?: b), it would have to be equivalent to (a ? a : b) with the exception that a is only evaluated once, just as it is in gcc. Any other meaning would be confusing to end users, due to the strong resemblance to the ternary operator. The use-case here seems to be that it would have the value a whenever a is undefined, not when a is truey. This is a tricky enough difference that I think it mandates a different operator, like ??. That said, I don't think I have ever seen code like that in the field, where the caller sorts out the default values instead of the callee.* * later edit: I thought this was true, but see that I have been unwittingly using this idiom myself for years, see examples below. Very much looking forward to ?: (however we spell it) and ?=. Me too. They are all over my C code and Makefiles. Random usage (food for thought): memcpy(newHnd-buffer, thisHnd-buffer, min(length, newHnd-length ?: length)); const char *filename = gpsee_programRelativeFilename(cx, report-filename) ?: unknown filename; JS_SetGCParameter(rt, JSGC_MAX_BYTES, (size_t)strtol(rc_default_value(rc, gpsee_gc_maxbytes, 0), NULL, 0) ?: (size_t)-1); So, as you can see above, I tend to use ?: to supply default behaviour to functions when necessary, particularly when they are library functions out of my control. GPSEE_SRC_DIR ?= $(shell pwd) GREP ?= grep EGREP ?= egrep MAKEDEPEND?= gcc -E -MM -MG NCURSES_LIB_NAME ?= ncurses BIN_DIR?= $(GPSEE_PREFIX_DIR)/bin I use the ?= idiom quite heavily in my Makefiles as we don't use autoconf. We simply have a configure script which generates an include file of stuff that's different for this platform, which gets included before the stuff that's assigned with the ?=. Also, the ?= allows the developer to override particular variables from environment variables passed to make, i.e. to install into a different target directory, use a different version of gcc, etc. This is idiom is especially powerful with Make's late evaluation of variables, but I don't think we should go there in ES. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
This breaks from JS's C-inspired assignment operators, but perhaps we can live with it. FWIW -- I was confused when I first read ||=, I thought it was supposed to be some kind of Boolean-coercing variant on |=. Now I see that it is more like ?= from GNU make. What do you think of GCC's ?: operator? It is basically a special form of the ternary operator, and while not the same as your propsal, it addresses many of the same use cases. (I've been happy with it for a long time). Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
error.stackFrames, an Array which contains one object per stack frame, describing function name (if any), filename, line number, some kind of instance Id (for closures), arguments, and closed-over variables would be absolutely incredible from my POV. Tie it up in a nice package that can be JSON.stringified, and that SSJS back-ends can send better debug info back to the browser for the developers to consume. Wes On 8 June 2012 02:57, T.J. Crowder t...@crowdersoftware.com wrote: On 8 June 2012 04:28, David Herman dher...@mozilla.com wrote: - You mentioned that compatibility requires error.stack to be a string, even though programs would really like to have a structured version. Should we offer a different property with structured stack frame info (probably with a getter to allow straight-forward lazy construction), called error.stackFrames or error.stackEntries or something? Big +1 on that. Avoiding parsing information the engine has as discrete items already is a Good Thing(tm). Perhaps it'll be aspirational at first, but if specified now it'll happen eventually. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
It might be out of scope, but as a developer, I would almost give my left nut to have the kind of information in Brendan's example. Even more so if it the browser guys made it available as an argument to the window.onerror callback. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMA-262 purview? was re: FFT module
On 22 May 2012 12:54, Aymeric Vitte vitteayme...@gmail.com wrote: I don't see how a FFI could really help developers. FFIs are certainly helpful in many situations. I don't think this is one of them. Let me relay a relevant xperience. We develop applications in Server-Side JavaScript. We have an FFI that, with some magic compile-time shims and a few other tricks, lets us write close-to-the-bare-metal applications that are portable without platform detection across many operating systems -- in fact, I believe, to any conformant SUSv3 implementation. We write nearly-C-like code on Linux, Solaris, and Mac OS X, 32 and 64 bit, to give us nice JS libraries on top of the ugly, bare metal. Our implementation is complete enough that we were able to write a complete WebSockets implementation in JS, that runs on many platforms, with no direct support in the host environment other than FFI, right down to the networking system calls, including the magic macros for select (FD_CLR et al). Sounds great, right? Well, it is for us, but it would make a lousy direction for a standard: the resultant JS is completely non-portable to Windows. Or QNX. Or Gronch. Or a myriad of other operating systems. And that's the real problem. We have overcome the typical C porting problems -- endianness, word size, whether fstat() is a function or a macro, etc. but we're still nowhere close to being portable to where the web needs to run. If we want to run anywhere, we would need to FFI up one layer of abstraction, to something like APR or NSPR, and then guess what? We would be no better off in any way than what the standards guys have been up to -- and far, far, worse off in many. That's why I believe TC-39 is not the right place for a JS FFI. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ECMA-262 purview? was re: FFT module
This thread brings up an interesting question: Once we have modules, should we have a place other than ECMA-262 to define standard host-environment libraries that ship with browsers? On 21 May 2012 04:54, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: On Sun, May 20, 2012 at 11:53 PM, Jens Nockert j...@nockert.se wrote: This seems like a very application specific addition. Wouldn't it make more sense to add building blocks for building faster DSP operations instead? True, it is very application specific. And yes, that would be far more useful, however I think at some point in the foreseeable future there's a place for a built-in module like this as well. The main reason I decided to bring this idea up is that having a module like this in JS has come up quite a few times in W3C Audio WG discussions. Strawmen that popped into my mind, 1. Typed arrays ( http://wiki.ecmascript.org/doku.php?id=strawman:typed_arrays, already available in browsers) 2. Value objects ( http://wiki.ecmascript.org/doku.php?id=strawman:value_objects) for fixed-point and complex number operations -- Jens Nockert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMA-262 purview? was re: FFT module
This reminds me of a different topic: foreign function interface. [...] Thoughts? 1. I'm not sure this belongs in ES 2. If TC-39 starts looking at this, I would like to contribute somehow. I have significant experience in this area, and can share knowledge gleaned from an ES-centric implementation which is not related to Python's c-types. Wes On 21 May 2012 12:20, Claus Reinke claus.rei...@talk21.com wrote: Once we have modules, should we have a place other than ECMA-262 to define standard host-environment libraries that ship with browsers? Like the DOM?? ;-) ..criteria for which libraries might be within the prevue of TC39: * it requires extensions to the base language syntax or semantics or core libraries * it is of general utility in a variety of hosting environment, not just the browser * it must be baked in to an implementation * it raises significant interoperability issues that are solvable at the specification level * TC39 has the appropriate domain expertise or experts are willing to join and participate in TC39 This reminds me of a different topic: foreign function interface. Your first reaction might be: ES can't/shouldn't have any FFI! In practice, FFI's exist in various forms already. Chapter 15 and DOM functions spring into existence seemingly out of nowhere (there is no ES code that says there should be a 'createElement', no standard prelude that says 'slice' exists and works on Array-like things). Much of feature-testing tries to secure the gaps created by implicit FFI. Projects needing device access from ES found work-arounds that support general, though not necessarily efficient, foreign function access. Things like Phonegap are entirely based on such work-arounds. JS implementers experimenting with device access just provide foreign functions implicitly, implementation-specific. If ES had a foreign function interface (FFI) to specify how foreign functionality could be imported into ES code, that might: 1 help to document current base functionality in code (there could be standard libraries listing pre-defined functions imported from the host environment) 2 provide a window for optimized, cross-browser implementation of device access, without the work-arounds currently employed in Phonegap/Cordova and related projects Roughly, there would be ES source syntax for linking an ES identifier to foreign code, and ES engine support for calling that foreign code whenever the ES identifier is called in ES code. Thoughts? Claus -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The new operator
On 13 May 2012 13:57, Brendan Eich bren...@mozilla.org wrote: Protocols are fine and perhaps a new-free one will take over some years hence, but not soon. - Should there be alternate, possibly less confusing, ways of coercing values? ToPrimitive() would certainly be nice to have. An object may need to be coerced to a number of value types. How would ToPrimitive know which one to use? There may be a default, but not a unique target type. Vaguely-related use-case, mentioned only so that TC-39 et al get end-user feedback :) In GPSEE (a server-side embedding of SpiderMonkey with a focus on POSIX) we have a number of data types which share a common type of backing storewe call them ByteThings, and, really, they are just C pointers + size, and the JS object wrappers wind up being a sort of memory access protocol. When you have C-stuff, and in particular an FFI that can return pointers to JS space, you find that, at some point, you need to cast. We decided to arrange our ByteThing constructors so that they create *new* ByteThings when invoked with the new operator, and otherwise treat their argument sort of like a coercion source. We call this ByteThing casting. So we can write code ~ like this: var mem = new Memory(2); mem[0] = 65; mem[1] = 0; var sb = new MutableStruct(struct stat); /* Make a new object that maps properties to a struct stat */ stat(filename, sb); print(Memory(sb).asString()); print(mem.asString()); which is basically char *mem = malloc(2); mem[0] = 65; mem[1] = 0; struct stat sb; stat(filename, sb); printf(%s\n, (char *)sb): printf(%s\n, mem); Clearly this is a contrived example, but -- being able to have |new Memory()| and |Memory()| mean different, but related, things is useful to us. We could solve the same class of problems without the new operator by overloading based on argument type, but the code would be a little less legible and harder to reason about if the argument types weren't apparent at the callsite. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: typeof null
It looks to me like this code would work just fine by removing the word 'typeof'. What am I missing? On 8 May 2012 12:19, Rick Waldron waldron.r...@gmail.com wrote: module Foo { export function create( options ) { if ( typeof options === null ) { return ... some default thing; } }; } import create from Foo; let default = create( null ); -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Fun impossible Firefox JS challenge
On 12 April 2012 15:37, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Right chrome and safari log undefined in that case. FF and IE9 syntax error out on the var declaration. As long as we're exploring web compat, here's a historical view of SpiderMonkey behaviour -- JS 1.8.5 (~ Firefox 4) treats fals\u0065 as a valid identifier that is distinct from false. Same for JS 1.7 (~ Firefox 3) Same for JS 1.6 (~ Firefox 2) Same for JS 1.5 (ES-3) JS 1.4.1 does not allow unicode escapes in identifiers -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Terminology: “non-method function”
From a developer's POV - the terms bound/unbound makes a create deal of sense, since already have bind, which effectively turns an unbound function into a bound function. It basically completes the thought and makes it easy to explain. Heck, it even makes this behaviour easy to explain: function ABC() { this.hello = world; } ABC.prototype.def = function() { alert(this.hello) }; window.onclick = new ABC().def; Q: Why does my program alert undefined? A: The default behaviour for an event handler is to bind the event itself as 'this'. If you wanted that program to alert world, you should have used a *bound function* instead. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Development Mode/Production Mode
In a similar vein, I would personally like to have zero-cost-when-not-debugging assert() statements, and am hopeful that statically-linked modules might lead the way. We currently have LOW cost assert() statements, but these are still not suitable for hot loops. We can turn them into zero-cost with some pre-processing, but to actually guarantee that the program is the same with and without the asserts (ignoring side effects of the argument) means that the pre-processor needs to be much trickier than a simple sed statement. Especially given ASI. As a data point, we compile all our code through Mozilla's SpiderMonkey engine with JSOPTION_STRICT, which pre-dates ES5 strict mode, during our build phase. It catches a few things for us that would otherwise cause a bit of head-scratching, like functions that don't always return value. Wes On 1 April 2012 04:28, Brandon Benvie bran...@brandonbenvie.com wrote: Forgive me if this has been discussed before but I read back as much as I could and couldn't find a reference. With all the discussion that has happened in the past about various modes, ES6 strict opt-in, etc. there never seems to be mention of the concept of an optional especially strict mode specifically designed for development. The premise is this: when I developer something I want as many early errors as possible and nothing hidden away behind some abstraction, so it can be fixed. When something goes live it just needs to work, or gracefully fail, hopefully landing in error handlers that were provided, while sending home debug information. All of the discussion I've seen doesn't seen to be from this kind of angle, more of all or nothing it seems. There isn't some sort of mode toggle under discussions for ES6 that is specifically anticipated as a dev/production toggle, is there? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules feedback, proposal
On 31 March 2012 21:30, David Herman dher...@mozilla.com wrote: Yeah, I've thought about auto-appending .js. I think you're right that it opens up the possibility to be a little more abstract. FWIW -- the CommonJS convention of auto-appending .js has been a real boon to us when writing GPSEE modules. We took it a step farther, and decided we should search the filesystem for modules ending in .so also, giving us the ability to have modules which are written in JS, C/C++, or both -- completely transparently to the JS user. I am considering allowing modules written in CoffeeScript, and we'll do the same thing, compiling the CoffeeScript code transparently to a CommonJS module interface, and again, the JS application developer never needs to know what language the application is written in. A similar pattern might be useful if another language on the web ever emerges which needs to co-exist with ES within the browser -- provided this new language could present an ES6 module interface, your loader could detect which compiler to send it to, based on the MIME type, which the web server would figure out based on the extension which it finds by searching the filesystem. You could trivially implement the web-server part today with Apache's content negotiation stuff. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules feedback, proposal
On 1 April 2012 08:22, Wes Garland w...@page.ca wrote: the JS application developer never needs to know what language the application is written in. Sorry, what language the *module* is written in. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Learning from requirejs
We face basically this same problem in our day-to-day development -- here's how we do it: food for thought We use BravoJS as our module system, which targets CommonJS Modules/2.0-draft 8 (not an officially endorsed standard). From the ten-mile-POV, BravoJS works by loading the entire module dependency tree asynchronously (via script-tag injection) when the main module is declared. As dependent modules are loaded, we examine their dependencies and load them, too. Once all dependencies have been loaded, we initialize the main module (run it). Modules in CommonJS are initialized (run) when they are first require()d. Note that this is different from RequireJS, which initializes modules eagerly. We have the ability to lazy-load modules, but find that we seldom need this. We just don't have any large enough leaf modules to need this We use jQuery in our modules freely: we do this by including jQuery old-school, in the document head. I guess this is the 'synchronous load' issue you were discussing? We could address it in our own model by making jQuery a dependency of the main module (and refactoring jQuery to work in a CommonJS loader). We know that jQuery is always available, because our main module is always declared in the last script tag in the document; generally between /body and /html. Note that this means that we can't execute CommonJS code while the document is loading. This has not been a problem for us, although if we wanted to allow this, we could without a lot of effort. We *do* freely use CommonJS code in our HTML, though -- something like this -- form onsubmit=require('validate').form(this); action=return module.main.formAction(this); ..that pattern has been a very useful: flexible, easy to use, plays-well-with-older-code. Wes On 29 March 2012 20:43, John J Barton johnjbar...@johnjbarton.com wrote: On Thu, Mar 29, 2012 at 4:55 PM, David Herman dher...@mozilla.com wrote: On Mar 29, 2012, at 4:47 PM, John J Barton wrote: And like require.js we will have difficulty resynchronizing the script loading with document loading. For example, the above code may fail if the callback fires before 'myelement' is parsed. I'm not sure I understand. Why doesn't something like this work? script System.load(jquery.js, function($) { $.ready(function() { $('myelement').style({ 'background-color': 'yellow' }) }); }) /script To prevent a possible performance problem caused by synchronous module loading that blocks document loading, you are proposing to enforce asynchronous module loading. This sets up developers for a non-deterministic failure mode. Not everyone uses jquery and some that do may easily forget about the race. Can we do better? For example if we had system.load() wait to fire the callback until DOMContentLoaded and offered system.loadImmediate(), developers would be altered to this issue simply by having such an API. The example callback has two dependencies, jQuery and 'myelement'. Only one of these has expressed to the load() operation. Perhaps there are other ways of expressing the second dependency. jjb Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: module path resolution
On 25 March 2012 03:07, Axel Rauschmayer a...@rauschma.de wrote: One thing that would be nice that we don't currently have is the ability to load modules relative to the calling web page. This is an oversight in our loader. I'm curious: What is the use case for that? The case where you have two web pages loading mutually-shared JS -- or even one page using a lot of JS -- but not code you want to place in the globally-available library directory for whatever reason. We write web apps, and think of HTML files more or less as programs. Local-dir modules are like extra .o files in a C program. Module-dir modules are like libraries in /usr/lib. The main() function is a module contained within the HTML itself, usually between /body and /html. Another use-case our loader doesn't address well is loading dynamically-generated modules. These are modules whose source code is generated on the fly for whatever reason (e.g. they might emit information from a database, crypto secrets, etc.). We have to do either require(../../methods/module) /* brittle */ or require(/ + window.location.hostname + /methods/module) /* annoying */ Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: module path resolution
On 23 March 2012 21:59, Irakli Gozalishvili rfo...@gmail.com wrote: A. ./foo.js ../foo/bar.js B. foo.js, foo/bar.js I'd suggest to resolve A type paths relative to a requirer (ether require module url, or document url). And resolve B type paths relative to a `document.baseURI`. This is almost what CommonJS specifies and is quite close to what we use locally. We have a top-level path that is prepended to type B require statements which is by default calculated from window.location.href. We can, of course, override it, in case we move the page to a location where this calculation does not work -- exactly analogous to a base href setting. The fact that the modules themselves use relative paths to co-dependencies means that it's easy to move modules around, from app to app, server to server, etc. One thing that would be nice that we don't currently have is the ability to load modules relative to the calling web page. This is an oversight in our loader. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode based on UTF-16 proposal
On 24 March 2012 17:22, David Herman dher...@mozilla.com wrote: I'm not 100% clear on this point yet, but e.g. the SourceCharacter production in Annex A.1 is described as any Unicode code unit. Ugh, IMHO, that's wrong, and should be any Unicode code point. (let the flames begin?) The underlying transport format should not be a concern for the JS lexer. eval Eval is a red herring: its input is defined as the contents of the given String. So, we come full-circle back to what's in a String?. I'm still partial to Brendan's BRS idea, because at least it fixes everything all at once. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How about replacing | with -
On 1 March 2012 19:34, Allen Wirfs-Brock al...@wirfs-brock.com wrote: What do you think? Do you like - better than | ? Is it ok to not have it available for functions? I am always reticent to re-use lexical features of one language when implementing in another with wildly different semantics. Like it or not, programmers see JavaScript as a C-like language where - generally means 'accessor', as in C++. One could make the point that they should read the fine manual, but var scope is still a regular source of confusion: the vast majority of programmers just don't read anything more detailed than snippets on stackoverflow. I think an entirely new symbol will force them to read about the functionality and keep them from guessing about what it does. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native JSON loading (was: system module loader)
What about native JSON loading? How would this be different from XHR + JSON.parse() sugar? Are you proposing loading the JSON from the server as though it were a module? FWIW, most of my JSON-loading use cases are post-page-load, they are of the fetch some data from the server based on user input variety. In a very very very small number of cases (session state mostly) I also will load data at the same time as page load; for these cases I currently use SCRIPT tags and code ~ like this on the server print(Content-type: application/x-javascript\n) /* do stuff */ print var o = + uneval(o); Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Consider extending JSON grammar to support objects with circular reference
Mozilla used to support something like this, it is being removed in Firefox 12, but perhaps the implementation can give you ideas. https://developer.mozilla.org/en/Sharp_variables_in_JavaScript Wes On 5 March 2012 07:49, Andreas Rossberg rossb...@google.com wrote: On 5 March 2012 13:35, 程劭非 csf...@gmail.com wrote: { a: path(/a2), // yes, path(/a2) is a object a2: {c: 1, d: path(../b/d)}, // no, path(/b) is a path itself you will get undefined here. b: path(/b2), //yes, path(/b2) is a object b2: {c: path(../a/c), d: 2}, // no path(../a) is a path itself you will get undefined here. } In general, I mean a path will never refer to a object specified by a path. Why? And anyway, what about: { a: {c: 1, d: path(../b/d)}, b: {c: path(../a/c), d: 2}, } You still need deep dependency analysis. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Math.clz()
Can we really add a Bit namespace without breaking the web? Maybe Math.Bit if we really want a bitwise operation namespace? clz, clo, the names are cryptic but so are their applications -- so I think it's a good fit. zLen and oLen might also make good names. These could be handy for other things, too, provided they work on at least 32-bit numbers. They would need coercion rules similar to what and have right now. And, what does clz(0) yield? 53? An interesting overload might be letting them work on typed arrays, too. Wes On 4 March 2012 07:15, Jussi Kalliokoski jussi.kallioko...@gmail.comwrote: I'm not sure I understood correctly, but... I think for the sake of this being a useful performance optimization, it shouldn't have any overloads / optional arguments, maybe a separate function for that is a better. Also, while we are adding things to the Bit namespace, I'm not sure if ctz/cto (count trailing zeroes/ones) are really useful, I've never figured out a use case for them, but while at it, why not add it, might be useful in the future, although I highly doubt it. As for the string padding, it might be a bit redundant, but I don't know. On Sun, Mar 4, 2012 at 12:00 PM, Peter van der Zee e...@qfox.nl wrote: Maybe make it generic? Although that might not be very important for the case of counting leading zeroes or ones. I'd love a function for getting n consecutive bits (to left or right..) from number x starting from the nth bith (from the left or right) as a single number as if the lsb was 1. You can create masks for this to and , but it's not as versatile. Also, maybe a toString function for binary with leading zero padding (or are we getting String#pad now?). - peter On Sun, Mar 4, 2012 at 10:38 AM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: Bit.clz() sounds just as good to me. I don't know if they need to be less cryptic, if someone doesn't know the abbreviation, it is highly likely (s)he doesn't need the functions either. :) On Sun, Mar 4, 2012 at 10:01 AM, Tomas Carnecky t...@caurea.org wrote: Wouldn't it be better to namespace these bit-operators in a different module? Bit.clz() perhaps? The Math module is getting a bit crowded. On Sat, 03 Mar 2012 23:21:11 -0800, Brendan Eich bren...@mozilla.org wrote: I'm open to clz/clo. The names perhaps need to be less cryptic... or not. Allen should weigh in. /be Jussi Kalliokoski wrote: We're working on JS audio decoders, and one huge performance issue atm is clz() [count leading zeroes], which is a very commonly used algorithm in decoders. We've tried several different approaches and benchmarked them [1], however, different approaches work better on different engines, so optimizing the function is a bit of a no-go, especially if we want to have it fast in the future as well. So, I thought I'd propose something that would go well with the earlier proposals to extend Math [2]: Math.clz(number) This would allow for great speed boost in our decoders if it the JS engine had this built-in and optimized. While at it, it might be wise to add other related functions as well, such as clo (count leading ones), although not as useful. Cheers, Jussi [1]: http://jsperf.com/read-leading-zeros/8 [2]: http://wiki.ecmascript.org/doku.php?id=harmony:more_math_functions ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
Erratum: var a = [0]; should read var a = []; ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
On 21 February 2012 00:03, Brendan Eich bren...@mozilla.com wrote: These are byte-based enodings, no? What is the problem inflating them by zero extension to 16 bits now (or 21 bits in the future)? You can't make an invalid Unicode character from a byte value. One of my examples, GB 18030, is a four-byte encoding and a Chinese government standard. It is a mapping onto Unicode, but this mapping is table-driven rather than algorithm driven like the UTF-* transport formats. To provide a single example, Unicode 0x2259 maps onto GB 18030 0x8136D830. You're right about Big5 being byte-oriented, maybe this was a bad example, although it is a double-byte charset. It works by putting ASCII down low making bytes above 0x7f escapes into code pages dereferenced by the next byte. Each code point is encoded with one or two bytes, never more. If I were developing with Big5 in JS, I would store the byte stream 4a 4b d8 00 c1 c2 4c as 004a 004b d800 c1c2 004c. This would allow me to use JS regular expressions and so on. Anyway, Big5 punned into JS strings (via a C or C++ API?) is *not* a strong use-case for ignoring invalid characters. Agreed - I'm stretching to see if I can stretch far enough to find a real problem with BRS -- because I really want it. But the data does not need to arrive from C API -- it could easily be delivered by an XHR request where, say, the remote end dumps database rows into a transport format based around evaluating JS string literals (like JSON). Ball one. :-P If I hit the batter, does he get to first base? We still haven't talked about equality and normalization, I suppose that can wait. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
On 20 February 2012 00:45, Allen Wirfs-Brock al...@wirfs-brock.com wrote: 2) Allow invalid unicode characters in strings, and preserve them over concatenation – (\uD800 + \uDC00).length == 2. I think 2) is the only reasonable alternative. I think so, too -- especially as any sequence of Unicode code points -- including invalid and reserved code points -- constitutes a valid Unicode string, according to my recollection of the Unicode specification. In addition to the reasons you listed, it should also be noted that - 2) is cheaper to implement - 2) keeps more old code working; ignoring the examples where developers use String as uint16[], there are also the cases where developers scan strings for 0xD800. 0xD800 is a reserved code point. I don't think 1) would be a very good choice, if for no other reason the set of valid unicode characters is a moving target that you wouldn't want to hardwire into either the ES specification or implementations. To play the devil's advocate, I could point out that the spec language could say something about reserved code points. Those code points are reserved because, IIRC, they are not representable in UTF-16; they include the ranges for the surrogate pairs. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
On 19 February 2012 16:34, Brendan Eich bren...@mozilla.com wrote: Wes Garland wrote: Is there a proposal for interaction with JSON? From http://www.ietf.org/rfc/rfc4627, 2.5 *snip* - so the proposal is to keep encoding JSON in UTF-16. What happens if the BRS is set to Unicode and we want to encode the string \uD834\uDD1E -- the Unicode string which contains two reserved code points? We do not want to deserialize this as U+1D11E. I think we should consider that BRS-on should mean six-character escapes in JSON for non-BMP characters. It might even be possible to add matching support for JSON.parse() when BRS-off. The one caveat is that might make JSON interchange fragile between BRS-on systems and ES5 engines. Yes, sharing the uint16 vector is good. But string methods would have to index and .length differently (if I can verb .length ;-). .lengthing is easy; cost is about the same as strlen() and can be cached. Indexed access is something I have thought about from the implementor's POV for a while [but not heavily]. I haven't come up with a ground-breaking technique, I keep coming up with something that looks like a lookup table for surrogate pairs, degrading to an extra uint32[] when there are many of them. Anyhow, implementation detail. Of course, strings with the same characters are == and ===. Strings appear to be values. If you think of them as immutable reference types there's still an obligation to compare characters for strings because computed strings are not intern'ed. What about strings with the same sequence of code units but different code points? They would have identical backing stores if the backing store were either UTF-8 or uint32. This can happen if we have BRS-on Strings which contain non-BMP code points.(Actually, does BRS-on mean that we have to abandon UTF-16 to store Unicode strings containing invalid code points? Mark Davis, are you reading?) How about strings which are considered equal by Unicode but which do not share the same representation? Will Unicode normalization be performed when Strings are created/parsed? On comparison? If on compare, would we skip normalization for ===? I assume normalizing to NFC form, similar to what W3C does, is the target? http://www.macchiato.com/unicode/nfc-faq (Mark Davis) http://unicode.org/faq/normalization.html Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
On 20 February 2012 09:56, Andrew Oakley and...@ado.is-a-geek.net wrote: While this is being discussed, for any new string handling I think we should make any invalid strings (according to the rules in Unicode) cause some kind of exception on creation. Can you clarify which definition in the Unicode standard you are proposing for invalid string? Most content actually only tries to access characters of a string like this: for (var i = 0; i str.length(); i++) { str[i]; } Does anybody have any data on this? I'm genuinely curious about how much code on the web does any kind of character access on strings; the only common use-case that comes to mind (other than wanting uint16[]) is users who are doing UTF-16 on top of UCS-2. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
On 20 February 2012 16:00, Allen Wirfs-Brock al...@wirfs-brock.com wrote: My sense is that there are a fairly large variety of string data types could be use the existing ES5 string type as a target type and for which many of the String.prototuype.* methods would function just fine The reason is that most of the ES5 methods don't impose this sort of semantic restriction of string elements. To pick one out of a hat, it might be nice to be able to use non-Unicode encodings, like GB 18030 or BIG5, and be able to use regexp methods on them when the BRS is on. (I'm struggling to find a really real real-world use-case, though) Observation -- disallowing otherwise legal Unicode strings because they contain code points d800-dfff has very concrete implementation benefits: it's possible to use UTF-16 to represent the String's backing store. Without this concession, I fear it may not be possible to implement BRS-on without using a UTF-8 or full code point backing store (or some non-standard invention). Maybe the answer is to consider (shudder) adding String-like utility functions to the TypedArrays? FWIW, CommonJS tried to go down this path and it turned out to be a lot of work for very little benefit (if any). But with the BRS flipped it would have to censor C strings passed to JS to ensure that unmatched surrogate pairs are present. Only if the C strings are wide-character strings. 8-bit char strings are fine, they map right onto Latin-1 in native Unicode as well as the UTF-16 and UCS-2 encodings. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New full Unicode for ES6 idea
On 19 February 2012 03:33, Brendan Eich bren...@mozilla.com wrote: S1 dates from when Unicode fit in 16 bits, and in those days, nickels had pictures of bumblebees on 'em (Gimme five bees for a quarter, you'd say ;-). Say, is that an onion on your belt? * indexing by characters, not uint16 storage units; * counting length as one greater than the last index; and These are the two items that IME trip up developers who are either not careful or not aware of UTF-16 encoding details and don't test with non-BMP input. Frankly, JS developers should not have to be aware of character encodings. Strings should just work. I think that explicitly making strings Unicode and applying the fix above would solve a *lot* of problems. If I had this option, I would go so far as to throw the BRS in my build processes, hg grep all our source code for strings like D800 and eliminate all the extra UTF-16 machinations. Another option might be to make ES.next have full Unicode strings; fix .length and .charCodeAt etc when we are in ES.next context, leaving them broken otherwise. I'm not fond of this option, though: since there would be no BRS, developers might often find themselves unsure of just what the heck it is they are working with. So, I like per-global BRS. * supporting escapes with (up to) six hexadecimal digits. This is necessary too; developers should be thinking about code points, not encoding details. P2. The change is not backward compatible. In JS today, one read a string s from somewhere and hard-code, e.g., s.indexOf(0xd800 to find part of a surrogate pair, then advance to the next-indexed uint16 unit and read the other half, then combine to compute some result. Such usage would break. While that is true in the general case, there are many specific cases where that would not break. I'm thinking I have an implementation of UnicodeStrlen around here somewhere which works by subracting the number of 0xD800 characters from .length. In this case, that code would continue to generate correct length counts because it would never find a 0xD800 in a valid Unicode string (it's a reserved code point). We also wish to avoid exposing a full Unicode representation type and duplicated suite of the String static and prototype methods, as Java did. (We may well want UTF-N transcoding helpers; we certainly want ByteArray - UTF-8 transcoding APIs.) These are both good goals, in particular, avoiding a full Unicode type means reducing bug counts in the long term. Is there a proposal for interaction with JSON? Also because inter-compartment traffic is (we conjecture) infrequent enough to tolerate the proxy/copy overhead. Not to mention that the only thing you'd have to do is to tweak [[get]], charCodeAt and .length when crossing boundaries; you can keep the same backing store. You might not even need to do this is the engine keeps the same backing store for both kinds of strings. This means a script intent on comparing strings from two globals with different BRS settings could indeed tell that one discloses non-BMP char/codes, e.g. charCodeAt return values = 0x1. This is the *small* new observable I claim we can live with, because someone opted into it at least in one of the related global objects. Funny question, if I have two strings, both hello, from two globals with different BRS settings, are they ==? How about ===? R1. To keep compatibility with DOM APIs, the DOM glue used to mediate calls from JS to (typically) C++ would have to proxy or copy any strings containing non-BMP characters. Strings with only BMP characters would work as today. Is that true if the full unicode backing store is 16-bit code units using UTF-16 encoding? (Any way, it's an implementation detail) In particular, Node.js can get modern at startup, and perhaps engines such as V8 as used in Node could even support compile-time (#ifdef) configury by which to support only full Unicode. Sure, this is analogous to how SpiderMonkey deals with UTF-8 C Strings. Flip a BRS before creating the runtime. :) Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native Assertion module?
There's both room and need for a built-in assert() IMHO -- I would like one which magically compiles to nothing in production code. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On 30 January 2012 11:56, Allen Wirfs-Brock al...@wirfs-brock.com wrote: this was part of what I was trying to get at in using the phrase application level semantics. The distinction really isn't very different from object created via object literals (or any other standard mechanism). They clearly are ECMAScript objects but because they have arbitrary properties defined by the application they are not standard objects. So, a good example here would be E4X objects? (Ignoring that E4X is a standard, let's pretend they are engine vendor bolt-ons). They have behaviours different from standard ES objects; the first one that pops to mind is that is possible for two E4X objects to be == but not ===. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Any plan for a Zlib API ?
Why wouldn't you just fix this at the HTTP level with Content-Transfer-Encoding negotiation of some sort? Out of curiosity, what are you sending to the server that that requires additional compression? Remember that zlib is not useful on PNG, JPEG, etc content. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let's kill terms native and host
On 28 January 2012 22:51, Mark S. Miller erig...@google.com wrote: Just because an object is provided as part of the host environment does *not* make it a host object. Given your statements above, I suspect that the Node objects you have in mind are all simply native objects provided by the Node hosting environment. If so, these are *not* host objects. I'm another person confused by the difference between host objects, native objects, and objects like Math. Given that I haved worked trying to define the CommonJS host environment and that I write a lot of JS objects in C with SpiderMonkey, you'd think I would know the difference, but I don't. At least now I know I don't. I used to think I did, and that made reading the spec less useful. I think the least confusing way forward may be to drop the terms host object and native object completely from ES6. This isn't the first time that this list has spent many email thread time confusing host objects with native objects provided by the host. By itself, this would suggest that the right terminology is native and non-native. In my opinion, we need terminology describing objects which are provided by the host environment, and those which aren't. The language of implementation is completely irrelevant here. In GPSEE, we have CommonJS modules where exports can be functions implemented in JS or C -- in fact, we purposefully prototype in JS and then write C versions of hot library functions once code is in production. Rhino embeddings can do similar things, implementing some methods in JS and others in Java. In this case, is a Java function native? Here's something even funnier -- if you use Object.prototype.bind in SpiderMonkey (Firefox 9) on a function written in JS userland and then call .toSource() on the result, it reports that the function is native! *head exploding* Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Deep cloning objects defined by JSON.
On 22 January 2012 16:05, Jake Verbaten rayn...@gmail.com wrote: The idea here is that methods do not belong in data structures (clone should be to efficiently clone data). Method vs. Property is a false dichotomy in functional languages, IMO. A method is merely a property whose value is a function instead of some other type. -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: January 19 meeting notes
On 20 January 2012 09:22, Herby Vojčík he...@mailbox.sk wrote: +1. I see no point why let e; should not shadow argument e here. I do. It is a virtual certainty that this form was used accidentally by the developer, which indicates a flaw in the developer's thinking -- probably due to cut-paste/refactor code having a variable name collision. It should be an early error/warning, just like it is in C. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: January 19 meeting notes
On 19 January 2012 23:02, Brendan Eich bren...@mozilla.org wrote: Yes kids, this means we are going with MarkM's lambda desugaring from: https://mail.mozilla.org/**pipermail/es-discuss/2008-**October/007819.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html So any closures formed in the body of such a for(let...;...;...) loop will capture the binding created afresh for that iteration. Thank you, Lord! \o/Can I get a Hallelujah? \o/ for (i=0; i alerts.length; i++) { setTimeout(function(i) { return function() { m.add(alerts[i]) } }(i), (i+1) * 10); } Here ^^ is a real loop I wrote last week, weeping the entire time. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Jan 18 meeting notes
Object.classOf(x) - Object.prototype.toString.call (x).slice(8, -1) using the original value of O.p.toString. Comments? Including the name of the module that the class comes from might be nice. We do that for classes implemented in C in GPSEE modules today by being bad -- we modify JSClass::name after JS_InitClass() returns -- and it's helpful during debugging. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On 16 January 2012 14:20, Andrea Giammarchi andrea.giammar...@gmail.comwrote: var module = require(module); is totally fine but require(module, function (module) { // is totally fine too }); latter could be synchronous in node.js and asynchronous in the web, who cares, as long as it scales for all scenarios ... don't you agree? One fundamental difference between how AMD modules and CommonJS modules (presumably Node) load is that CommonJS modules have lazy initialization, whereas AMD modules have eager initialization. This is probably where some of the NodeAMD impedance mismatch is coming from -- in CommonJS with Modules/1.0 on the server side, developers expect to be able to perform certain types of initialization when the module is loaded, and they do not expect to need to pre-declare their modules. It will be interesting to see how the addition of ES.Next modules plays out with the server-side JS communities. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Better Native XML Support
On 17 January 2012 13:05, Russell Leggett russell.legg...@gmail.com wrote: After all, e4x is just an extension to JS, it should be possible to add the data types natively and then make any e4x code work as syntactic sugar, which you can desugar yourself. I don't really know the details, but that is definitely not true. Ask Jeff Walden from Mozilla for details, if you can convince him to discuss the topic. :) This may be true for something approaching E4X, and might be a great way to approach the community's needs. An XML library and a pre-processor. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
I'll chime in with my vote - I would LOVE to be able to use octal literals again in GPSEE for setting file permissions. chmod(filename, parseInt(777, 8)) just looks stupid when chmod(filename, 0777) would work just fine. Wes On 12 January 2012 14:11, Brendan Eich bren...@mozilla.com wrote: [Resending reply with elaboration. /be] Yes, the ability to quote the octal literal with Node's APIs came up on the gist, but it's not enough. Quoting is easy to forget, and making the runtime convert string (literal) to number is inefficient compared to having JS do it at compile-time, and making the runtime (even via a call to parseInt) do it also increases bug habitat ever so slightly. Mainly, users don't have to shun octal in non-strict mode, and they do not in Node code I have seen. They won't be adopting strict mode as far as I can tell. Banning octal is just one more reason for those who *might* adopt strict mode to reject it. Agree on parseInt. Old dog, hard to change (runtime-only errors are migration- and user-hostile). Not sure what to do there. /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: String concatenation
On 6 October 2011 14:09, Tom Schuster t...@schuster.me wrote: (1) is in fact really good optimized in modern engines. (In case you are interested search for Ropes: an alternative to strings) You don't even need ropes to make this fast for a lot of common cases. I think even a naive implementer would come up with something like this after a couple of beers: - Create the initial string - Mark a bit in the string's private handle (say, a bit in a tagged pointer) when it's referenced - Upon += if the referenced bit is true, goto naive +=, else - realloc() the underlying storage - cat the new string onto the end of the old one - this works whether or not realloc() moves the underlying storage, which it often won't There's all kinds of ways to optimize operations like this. Let's not stifle innovation by over specifying. Incidentally, Tom suggests a great search. The paper is a good read, but the Wikipedia article is a faster skim: http://en.wikipedia.org/wiki/Rope_%28computer_science%29 Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
Andrea; On 17 September 2011 04:12, Andrea Giammarchi andrea.giammar...@gmail.comwrote: I know current Mozilla implementation is not exactly what will be in JS.next but it was the only way I had to test efficiency of this proposal and performances speaking it looks like an epic fail so far and please feel free to correct me as much as possible, thanks. I ... just don't know where to begin. JS-CTypes is a foreign-function interface for SpiderMonkey. It's purpose is to allow JavaScript programs to execute code in native C libraries. It was developed so that extension developers could call into native libraries without shipping binary extensions, thus improving extension compatibility from one version of the browser to another. In order to know how to pass arguments to C functions, you need to know the data types, so some special JS Objects were created to host the data and carry type information with them. I don't understand why you expect these special-purpose JS objects to be faster than JS values at storing numbers. Of course they are going to be slower. Similarly, I don't understand why you would compare JS-CTypes with Cython. A much better analogue is Python's CTypes. *check all properties, check all types, convert them into C compatible structs, bring them back to JS world per each index access* ... I mean, this cannot be the way to make things faster. Of course not, don't be ridiculous. It is not the way to make JS faster. It is the way to make JS interoperate with C libraries. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
Speaking pragmatically, for myself and my unusual (server-side) environment: On 13 September 2011 10:48, Brendan Eich bren...@mozilla.com wrote: Does JS need to be as fast as Java? Would half as fast be enough? If it's compute-bound then that's plenty. Provided we develop so that we can scale across cores, I can double my compute this month for about the same dollar cost as 0.1% programmer-time. My estimate is that type annotations would be far more expensive; as we don't generally have type-related bugs in our JS code, spending time annotating only for the sake of execution speed would be a poor decision. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
Great post, Allen! On 13 September 2011 15:01, Allen Wirfs-Brock al...@wirfs-brock.com wrote: We need to do the same thing with our JS tools. All of the great dynamic language IDEs (that, BTW, preceded and largely inspired the modern static language IDEs) were live environments. They didn't just provide a live debugging experience, it was a live authoring experience. You developed code as a dynamic running program. They truly support incremental, interactive development. Developers operate in a continuous write a little/run a little cycle. The tools use information obtained from an actual running program to provide a great developer experience. This reminds of one of my constant modern-day-language laments...no development-time interactivity. I cut my very first programming teeth during the 8-bit microcomputer era, and learned a wide variety of BASICs (Sinclair, Commodore, AppleSoft, Atari, GW-). A few years on and I'd moved to environments like Logo, Quick Basic 4.5 (not Visual Basic), before heading for less dynamic (but faster) pastures. I've spent time with unusual IDEs like Garry Kitchen's Game Maker, Opcode's MAX, and ControllerMate IV. All of these environments -- even if the languages themselves were awful -- had one thing in common which I love: you just type stuff in, and it goes. You can try a hundred solutions as fast as you can google for one. You get to explore the machine. You learn by doing. These are great traits, and one of the reasons I love JS is that I believe I can recapture some of that ... agility ... that has been eroded over the years. When I write shell programs, and JS programs, I keep an extra terminal window open to a spare shell or a JS REPL. I try stuff. Stuff that works, I copy into my program. Then I run my program - which happens quickly, because the compiler is super-fast and the program is a contained entity which probably runs in a dynamically configured environment. I'm a *highly *productive shell programmer, and a very productive JS programmer. I spent more than a decade full time hacking C, and I frequently write JS programs which are superior to equivalent C programs, even when they are both manipulating the same underlying OS calls, because I can test my JS incrementally (not to mention prototypal inheritance, superior flow control,etc). So, even though C is absolutely my forte, I prefer to hack in JS these days because I am so much more productive. That increase in productivity is due in no small part to the dynamic language development experience you mentioned above and I believe we have only barely scratched the surface. I can't wait to see what improvements will be brought to the ECMAScript IDE in the next few years. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: IDE support?
On 12 September 2011 16:31, François REMY fremycompany_...@yahoo.fr wrote: JavaScript is simple for the developer, but sometimes its flexibility makes it impossible to optimize code properly. And it makes JavaScript slower. I made this graph earlier this year, coincident with the Firefox 4 release: http://www.page.ca/~wes/SpiderMonkey/Perf/sunspider_history.png Look at how much faster JS is now than it was just a few years ago! It's practically a logarithmic curve! ...and yet, Google's Crankshaft (Dec 2010) was *still* faster than Firefox 4's SpiderMonkey, showing that there is still room for improvement in the space! Let's not write the ES5 perf-increase obituary just yet. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Style Question
On 9 September 2011 16:06, Rick Waldron waldron.r...@gmail.com wrote: I was actually very specifically looking for an answer regarding First letter casing for non-constructor built-in objects, ie. Math and Proxy. I think the legacy Java style guide influence addresses the question as best as I can hope for. These *did* come to us via Java (well, not Proxy), but they are hardly a matter of style; they are a matter of specification. Generally we name constructor functions with CapitalLeadingCamelCase and everything else with smallLeadingCamelCase. I think I picked this up from JavaScript: The Definitive Guide, 2nd Edition, by David Flanagan, about 4,000 years ago. As for other matters of style, I am a big proponent of brace-on-a-line in C-syntax languages, however this has proven to be a problem in practice with JavaScript due to the interaction between automatic semicolin insertion and object literal syntax in return statements: return { Hello: world }; is not the same as return { Hello: world } Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
On 16 May 2011 17:42, Boris Zbarsky bzbar...@mit.edu wrote: On 5/16/11 4:38 PM, Wes Garland wrote: Two great things about strings composed of Unicode code points: ... If though this is a breaking change from ES-5, I support it whole-heartedly but I expect breakage to be very limited. Provided that the implementation does not restrict the storage of reserved code points (D800-DF00) Those aren't code points at all. They're just not Unicode. Not quite: code points D800-DFFF are reserved code points which are not representable with UTF-16. Definition D71, Unicode 6.0. If you allow storage of such, then you're allowing mixing Unicode strings and something else (whatever the something else is), with bad most likely bad results. I don't believe this is true. We are merely allowing storage of Unicode strings which cannot be converted into UTF-16. That allows us to maintain most of the existing String behaviour (arbitrary array of uint16), although overflowing like this would break: a = String.fromCharCode(str.charCodeAt(0) + 1) when str[0] is 0+. Most simply, assignign a DOMString containing surrogates to a JS string should collapse the surrogate pairs into the corresponding codepoint if JS strings really contain codepoints... The only way to make this work is if either DOMString is redefined or DOMString and full Unicode strings are different kinds of objects. Users doing surrogate pair decomposition will probably find that their code just works How, exactly? /** Untested and not rigourous */ function unicode_strlen(validUnicodeString) { var length = 0; for (var i = 0; i validUnicodeString.length; i++) { if (validUnicodeString.charCodeAt(i) = 0xd800 validUnicodeString.charCodeAt(i) = 0xdc00) continue; length++; } return length; } Code like this which looks for surrogate pairs in valid Unicode strings will simply not find them, instead only finding code points which seem to the same size as the code unit. Users creating Strings with surrogate pairs will need to re-tool Such users would include the DOM, right? I am hopeful that most web browsers have one or few interfaces between DOM strings and JS strings. I do not know if my hopes reflect reality. but this is a small burden and these users will be at the upper strata of Unicode-foodom. You're talking every single web developer here. Or at least every single web developer who wants to work with Devanagari text. I don't think so. I bet if we could survey web developers across the industry (rather than just top-tier people who tend to participate in discussions like this one), we would find that the vast major of them never both handling non-BMP cases, and do not test non-BMP cases. Heck, I don't even know if a non-BMP character can be data-entered into an input type=text maxlength=1 or not. (Do you? What happens?) I suspect that 99.99% of users will find that this change will fix bugs in their code when dealing with non-BMP characters. Not unless DOMString is changed or the interaction between the two very carefully defined in failure-proof ways. Yes, I was dismayed to find out that DOMString defines UTF-16. We could get away with converting UTF-16 at DOMString JSString transition point. This might mean that it is possible that JSString=DOMString would throw, as full Unicode Strings could contain code points which are not representable in UTF-16. If don't throw on invalid-in-UTF-16 code points, then round-tripping is lossy. If it does, that's silly. It needed to specify _something_, and UTF-16 was the thing that was compatible with how scripts work in ES. Not to mention the Java legacy if the DOM... By this comment, I am inferring then that DOM and JS Strings share their backing store. From an API-cleanliness point of view, that's too bad. From an implementation POV, it makes sense. Actually, it makes even more sense when I recall the discussion we had last week when you explained how external strings etc work in SpiderMonkey/Gecko. Do all the browsers share JS/DOM String backing stores? It is an unfortunate accident of history that UTF-16 surrogate pairs leak their abstraction into ES Strings, and I believe it is high time we fixed that. If you can do that without breaking web pages, great. If not, then we need to talk. ;) There is no question in mind that this proposal would break Unicode-aware JS. It is my belief that that doesn't matter if it accompanies other major, opt-in changes. Resolving DOM String JS String interchange is a little trickier, but I think it can be managed if we can allow JS=DOM to throw when high surrogate code points are encountered in the JS String. It might mean extra copying, or it might not if the DOM implementation already uses UTF-8 internally. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
Re: Full Unicode strings strawman
On 17 May 2011 12:36, Boris Zbarsky bzbar...@mit.edu wrote: Not quite: code points D800-DFFF are reserved code points which are not representable with UTF-16. Nor with any other Unicode encoding, really. They don't represent, on their own, Unicode characters. Right - but they are still legitimate code points, and they fill out the space required to let us treat String as uint16[] when defining the backing store as something that maps to the set of all Unicode code points. That said, you can encode these code points with utf-8; for example, 0xdc08 becomes 0xed 0xb0 0x88. No, you're allowing storage of some sort of number arrays that don't represent Unicode strings at all. No, if I understand Allen's proposal correctly, we're allowing storage of some sort of number arrays that may contain reserved code points, some of which cannot be represented in UTF-16. This isn't that different from the status quo; it is possible right now to generate JS Strings which are not valid UTF-16 by creating invalid surrogate pairs. Keep in mind, also, that even a sequence of random bytes is a valid Unicode string. The standard does not require that they be well-formed. (D80) Right, so if it's looking for non-BMP characters in the string, say, instead of computing the length, it won't find them. How the heck is that just works? My untested hypothesis is that the vast majority of JS code looking for non-BMP characters is looking for them in order to call them out for special processing, because the code unit and code point size are different. When they don't need special processing, they don't need to be found. Since the high-surrogate code points do not appear in well-formed Unicode strings, they will not be found, and the unneeded special processing will not happen. This train of clauses forms the basis for my opinion that, for the majority of folks, things will just work. What would that even mean? DOMString is defined to be an ES string in the ES binding right now. Is the proposal to have some other kind of object for DOMString (so that, for example, String.prototype would no longer affect the behavior of DOMString the way it does now)? Wait, are DOMStrings formally UTF-16, or are they ES Strings? This might mean that it is possible that JSString=DOMString would throw, as full Unicode Strings could contain code points which are not representable in UTF-16. How is that different from sticking non-UTF-16 into an ES string right now? Currently, JS Strings are effectively arrays of 16-bit code units, which are indistinguishable from 16-bit Unicode strings (D82). This means that a JS application can use JS Strings as arrays of uint16, and expect to be able to round-trip all strings, even those which are not well-formed, through a UTF-16 DOM. If we redefine JS Strings to be arrays of Unicode code points, then the JS application can use JS Strings as arrays uint21 -- but round-tripping the high-surrogate code points through a UTF-16 layer would not work. It might mean extra copying, or it might not if the DOM implementation already uses UTF-8 internally. Uh... what does UTF-8 have to do with this? If you're already storing UTF-8 strings internally, then you are already doing something expensive (like copying) to get their code units into and out of JS; so no incremental perf impact by not having a common UTF-16 backing store. (As a note, Gecko and WebKit both use UTF-16 internally; I would be _really_ surprised if Trident does not. No idea about Presto.) FWIW - last I time I scanned the v8 sources, it appeared to use a three-representation class, which could store either ASCII, UCS2, or UTF-8. Presumably ASCII could also be ISO-Latin-1, as both are exact, naive, byte-sized UCS2/UTF-16 subsets. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
On 17 May 2011 14:39, Boris Zbarsky bzbar...@mit.edu wrote: On 5/17/11 2:12 PM, Wes Garland wrote: That said, you can encode these code points with utf-8; for example, 0xdc08 becomes 0xed 0xb0 0x88. By the same argument, you can encode them in UTF-16. The byte sequence above is not valid UTF-8. See How do I convert an unpaired UTF-16 surrogate to UTF-8? at http://unicode.org/faq/utf_bom.html which says: You are comparing apples and oranges. Which happen to look a lot alike. So maybe apples and nectarines. But the point remains, the FAQ entry you quote talks about encoding a lone surrogate, i.e. a code unit, which is not a complete code point. You can only convert complete code points from one encoding to another. Just like you can't represent part of a UTF-8 code sub-sequence in any other encoding. The fact that code point X is not representable in UTF-16 has no bearing on its status as a code point, nor its convertability to UTF-8. The problem is that UTF-16 cannot represent all possible code points. See above. You're allowing number arrays that may or may not be interpretable as Unicode strings, period. No, I'm not. Any sequence of Unicode code points is a valid Unicode string. It does not matter whether any of those code points are reserved, nor does it matter if it can be represented in all encodings. From page 90 of the Unicode 6.0 specification, in the Conformance chapter: *D80 Unicode string:* A code unit sequence containing code units of a particular Unicode encoding form. • In the rawest form, Unicode strings may be implemented simply as arrays of the appropriate integral data type, consisting of a sequence of code units lined up one immediately after the other. • A single Unicode string must contain only code units from a single Unicode encoding form. It is not permissible to mix forms within a string. Not sure what (D80) is supposed to mean. Sorry, (D80) means per definition D80 of The Unicode Standard, Version 6.0 This hypothesis is worth testing before being blindly inflicted on the web. I don't think anybody in this discussion is talking about blindly inflicting anything on the web. I *do* think this proposal is a good one, and certainly a better way forward than insisting that every JS developer, everywhere, understand and implement (over and over again) the details of encoding Unicode as UTF-16. Allen's point about URI escaping being right on target here. If we redefine JS Strings to be arrays of Unicode code points, then the JS application can use JS Strings as arrays uint21 -- but round-tripping the high-surrogate code points through a UTF-16 layer would not work. OK, that seems like a breaking change. Yes, I believe it would be, certainly if done naively, but I am hopeful somebody can figure out how to overcome this. Hopeful because I think that fixing the JS Unicode problem is a really big deal. What happens if the guy types a non-BMP character? is a question which should not have to be answered over and over again in every code review. And I still maintain that 99.99% of JS developers never give it first, let alone second, thought. Maybe, and maybe not. We (Mozilla) have had some proposals to actually use UTF-8 throughout, including in the JS engine; it's quite possible to implement an API that looks like a 16-bit array on top of UTF-8 as long as you allow invalid UTF-8 that's needed to represent surrogates and the like. I understand by this that in the Moz proposals, you mean that the invalid UTF-8 sequences are actually valid UTF-8 Strings which encode code points in the range 0xd800-0xdfff, and that these code points were translated directly (and purposefully incorrectly) as UTF-16 code units when viewed as 16-bit arrays. If JS Strings were arrays of Unicode code points, this conversion would be a non-issue; UTF-8 sequence 0xed 0xb0 0x88 becomes Unicode code point 0xdc08, with no incorrect conversion taking place. The only problem is if there is an intermediate component somewhere that insists on using UTF-16..at that point we just can't represent code point 0xdc08 at all. But that code point will never appear in text; it will only appear for users using the String to store arbitrary data, and their need has already been met.. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
On 17 May 2011 15:00, Phillips, Addison addi...@lab126.com wrote: 2. Allowing unpaired surrogates is a *requirement*. Yes, such a string is ill-formed, but there are too many cases in which one might wish to have such broken strings for scripting purposes. 3. We should have escape syntax for supplementary characters (such as \U001). Looking up the surrogate pair for a given Unicode character is extremely inconvenient and is not self-documenting. ... As Shawn notes, basically, there are three ways that one might wish to access strings: ... - as code units (encoding units of text) I don't understand why (except that it is there by an accident of history) that it is desirable to expose a particular low-level detail about one possible encoding for Unicode characters to end-user programmers. Your point about database storage only holds if the database happens to store Unicode strings encoded in UTF-16. It could just as easily use UTF-8, UTF-7, or UTF-32. For that matter, the database input routine could filter all characters not in ISO-Latin-1 and store only the lower half of non-surrogate-pair UTF-16 code units. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
On 17 May 2011 16:03, Boris Zbarsky bzbar...@mit.edu wrote: On 5/17/11 3:29 PM, Wes Garland wrote: The problem is that UTF-16 cannot represent all possible code points. My point is that neither can UTF-8. Can you name an encoding that _can_ represent the surrogate-range codepoints? UTF-8 and UTF-32. I think UTF-7 can, too, but it is not a standard so it's not really worth discussing. UTF-16 is the odd one out. Therefore I stand by my statement: if you allow what to me looks like arrays UTF-32 code units and also values that fall into the surrogate ranges then you don't get Unicode strings. You get a set of arrays that contains Unicode strings as a proper subset. Okay, I think we have to agree to disagree here. I believe my reading of the spec is correct. There are no such valid UTF-8 strings; see spec quotes above. The proposal would have involved having invalid pseudo-UTF-ish strings. Yes, you can encode code points d800 - dfff in UTF-8 Strings. These are not *well-formed* strings, but they are Unicode 8-bit Strings (D81) nonetheless. What you can't do is encode 16-bit code units in UTF-8 Strings. This is because you can only convert from one encoding to another via code points. Code units have no cross-encoding meaning. Further, you can't encode code points d800 - dfff in UTF-16 Strings, leaving you at a loss when you want to store those values in JS Strings (i.e. when using them as uint16[]) except to generate ill-formed UTF-16. I believe it would be far better to treat those values as Unicode code points, not 16-bit code units, and to allow JS String elements to be able to express the whole 21-bit code point range afforded by Unicode. In other words, current mis-use of JS Strings which can store characters 0- in ill-formed UTF-16 strings would become use of JS Strings to store code points 0-1F which may use reserved code points d800-dfff, the high surrogates, which cannot be represented in UTF-16. But CAN be represented, without loss, in UTF-8, UTF-32, and proposed-new-JS-Strings. If JS Strings were arrays of Unicode code points, this conversion would be a non-issue; UTF-8 sequence 0xed 0xb0 0x88 becomes Unicode code point 0xdc08, with no incorrect conversion taking place. Sorry, no. See above. # printf '\xed\xb0\x88' | iconv -f UTF-8 -t UCS-4BE | od -x 000 dc08 004 # printf '\000\000\xdc\x08' | iconv -f UCS-4BE -t UTF-8 | od -x 000 edb0 8800 003 I just don't get it. You can stick the invalid 16-bit value 0xdc08 into a UTf-16 string just as easily as you can stick the invalid 24-bit sequence 0xed 0xb0 0x88 into a UTF-8 string. Can you please, please tell me what made you decide there's _any_ difference between the two cases? They're equally invalid in _exactly_ the same way. The difference is that in UTF-8, 0xed 0xb0 0x88 means The Unicode code point 0xdc08, and in UTF-16 0xdc08 means Part of some non-BMP code point. Said another way, 0xed in UTF-8 has nearly the same meaning as 0xdc08 in UTF-16. Both are ill-formed code unit subsequences which do not represent a code unit (D84a). Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
On 17 May 2011 20:09, Boris Zbarsky bzbar...@mit.edu wrote: On 5/17/11 5:24 PM, Wes Garland wrote: Okay, I think we have to agree to disagree here. I believe my reading of the spec is correct. Sorry, but no... how much more clear can the spec get? In the past, I have read it thus, pseudo BNF: UnicodeString = CodeUnitSequence // D80 CodeUnitSequence = CodeUnit | CodeUnitSequence CodeUnit // D78 CodeUnit = anything in the current encoding form // D77 Upon careful re-reading of this part of the specification, I see that D79 is also important. It says that A Unicode encoding form assigns each Unicode scalar value to a unique code unit sequence., and further clarifies that The mapping of the set of Unicode scalar values to the set of code unit sequences for a Unicode encoding form is one-to-one. This means that your original assertion -- that Unicode strings cannot contain the high surrogate code points, regardless of meaning -- is in fact correct. Which is unfortunate, as it means that we either 1. Allow non-Unicode strings in JS -- i.e. Strings composed of all values in the set [0x0, 0x1F] 2. Keep making programmers pay the raw-UTF-16 representation tax 3. Break the String-as-uint16 pattern I still believe that #1 is the way forward, and that problem of round-tripping these values through the DOM is solvable. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
Mark; Are you Dr. *Mark E. Davis* (born September 13, 1952 (age 58)), co-founder of the Unicode http://en.wikipedia.org/wiki/Unicode project and the president of the Unicode Consortiumhttp://en.wikipedia.org/wiki/Unicode_Consortiumsince its incorporation in 1991? (If so, uh, thanks for giving me alternatives to Shift-JIS, GB-2312, Big-5, et al..those gave me lots of hair loss in the late 90s) On 17 May 2011 21:55, Mark Davis ☕ m...@macchiato.com wrote:In the past, I have read it thus, pseudo BNF: UnicodeString = CodeUnitSequence // D80 CodeUnitSequence = CodeUnit | CodeUnitSequence CodeUnit // D78 CodeUnit = anything in the current encoding form // D77 So far, so good. In particular, d800 is a code unit for UTF-16, since it is a code unit that can occur in some code unit sequence in UTF-16. *head smack* - code unit, not code point. This means that your original assertion -- that Unicode strings cannot contain the high surrogate code points, regardless of meaning -- is in fact correct. That is incorrect. Aie, Karumba! If we have - a sequence of code points - taking on values between 0 and 0x1F - including high surrogates and other reserved values - independent of encoding ..what exactly are we talking about? Can it be represented in UTF-16 without round-trip loss when normalization is not performed, for the code points 0 through 0x? Incidentally, I think this discussion underscores nicely why I think we should work hard to figure out a way to hide UTF-16 encoding details from user-end programmers. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
Allen; Thanks for putting this together. We use Unicode data extensively in both our web and server-side applications, and being forced to deal with UTF-16 surrogate pair directly -- rather than letting the String implementation deal with them -- is a constant source of mild pain. At first blush, this proposal looks like it meets all my needs, and my gut tells me the perf impacts will probably be neutral or good. Two great things about strings composed of Unicode code points: 1) .length represents the number of code points, rather than the number of pairs used in UTF-16, even if the underlying representation isn't UTF-16 2) S.charCodeAt(S.indexOf(X)) always returns the same kind of information (a Unicode code point), regardless of whether X is in the BMP or not If though this is a breaking change from ES-5, I support it whole-heartedly but I expect breakage to be very limited. Provided that the implementation does not restrict the storage of reserved code points (D800-DF00), it should be possible for users using String as immutable C-arrays to keep doing so. Users doing surrogate pair decomposition will probably find that their code just works, as those code points will never appear in legitimate strings of Unicode code points. Users creating Strings with surrogate pairs will need to re-tool, but this is a small burden and these users will be at the upper strata of Unicode-foodom. I suspect that 99.99% of users will find that this change will fix bugs in their code when dealing with non-BMP characters. Mike Samuel, there would never a supplement code unit to match, as the return value of [[Get]] would be a code point. Shawn Steele, I don't understand this comment: Also, the “trick” I think, is encoding to surrogate pairs (illegally, since UTF8 doesn’t allow that) vs decoding to UTF16. Why do we care about the UTF-16 representation of particular codepoints? Why can't the new functions just encode the Unicode string as UTF-8 and URI escape it? Mike Samuel, can you explain why you are en/decoding UTF-16 when round-tripping through the DOM? Does the DOM specify UTF-16 encoding? If it does, that's silly. Both ES and DOM should specify Unicode and let the data interchange format be an implementation detail. It is an unfortunate accident of history that UTF-16 surrogate pairs leak their abstraction into ES Strings, and I believe it is high time we fixed that. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On 17 April 2011 20:09, Garrett Smith dhtmlkitc...@gmail.com wrote: Function.prototype.toString says yes. That's not a really valid evaluation IMO. At least in mozilla's case, the semi colon appears in this by virtue of the bytecode decompiler putting a semicolon at the end of every statement. The source-code-as-compiled is not actually stored anywhere. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removing labels
On Sat, Apr 9, 2011 at 12:47 PM, David Herman dher...@mozilla.com wrote: When people say Tennent's correspondence principle to mean something like beta-conversion is semantics-preserving I believe this post is where they got the impression that it has to do with Tennent. For better or worse, it seems to have stuck. I haven't got the faintest clue what beta-conversion is, but Neal's post seems consistent with what I took away from that (extremely short) discussion in Tennent's book. I'd look it up now, but it's at my office and this is the weekend. :) What am I missing? Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich bren...@mozilla.com wrote: This es-discuss group sounds exactly like that ES Tech group -- why make a new one? I've always considered this group to be about super-fine nit-picky points of ES, clarifications about recent changes, and well-thought out standards proposals. My thought in proposing ES Tech was that there is probably room for something with a slightly more casual tone, where ideas could be bounced off people as part of the formation process, and less advanced questions could be asked and answered. But not full of spam. If there's too much noise in any group, new or old, the group becomes useless. Asking for some simple ambiguity checks before posting syntax strawmen, and pleading to avoid one-line followups that overcite, etc. is *not* wrath. It's part of the well-known netiquette standard, but not enforced much these days. True that. Turning back my own mental clock, I remember getting flamed once for posting untested code in ... comp.unix.programmer? The flamer was right, and I didn't do it again, but I kept participating. And to be fair, the JS grammar is subtle enough that it's fine to propose somehting that *might* work, only to have grammarians debug it. Non leading-char solutions have the disadvantage of using some other kind of bracketing -- e.g. `a,b { return a + b; }` This is ambiguous too. A comma expression followed by a block (if in an outer function, the return is legal). Not that this was a serious proposal -- but am I missing something, or did you miss the trailing back-tick in my example? Specifically, I don't think this is ambiguous: FunctionExpression : function Identifieropt ( FormalParameterListopt ) { FunctionBody } or `Identifieropt FormalParameterListopt { FunctionBody }` ..although my native thought pattern is definitely LALR(1). I find LL(k) ambiguities hard to spot, not having worked with a top-down parser-generator since I was in school! Argh, now I'm not sure if that grammar is unambiguous for small k due to nested FunctionExpressions. I don't think there is a comma-expression hazard there, though. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote: On Mar 25, 2011, at 8:45 PM, David Foley wrote: My response was simply this : assuming normative scope in conversational tone, that I would welcome is a venue where end users (engineers and architects as well as scripters) could contribute to the developer experience of using JavaScript I was going to suggest comp.lang.javascript, but I just had a look and it seems to have been taken over by DOM questions and spam. David, why don't you start an ES Tech group or something, and ban questions which aren't related to JS? (Copy your charter from comp.lang.c, maybe). Announce it here, and I will subscribe. Probably even participate. Kevin Smith started this thread by objecting to #, and that's fair. It's a bit chicken-scratchy. If we can find a better introductory keyword or formal parameter bracketing form, I'm game. I like Doug's florin idea from an aesthetic POV, but I have two problems with it -- suddenly, I have to care what charset my editor is using -- but more importantly, I can't figure out how to type it on my Sun keyboard or on my Windows box. Also, what of JS which is delivered on the web using something other than unicode? Allowing both is an interesting option, but then I remember how annoying ANSI tri-graphs were (history lesson for !brendan: not all terminals had {, C programs allow ?? instead) and realise that would be a mistake. I, too, find #(a,b) but frankly, there aren't many lead-char solutions which aren't ugly, easy to type, and not used by identifiers (or as operators) already. What have we got to chose from? I think `@#%^* -- none of these are measurably better than # and some are worse. Maybe you could make the point that looks like a melted lambda. But I see no point in bike shedding over this. Non leading-char solutions have the disadvantage of using some other kind of bracketing -- e.g. `a,b { return a + b; }` -- I don't find syntax like this clear from a coder's POV, and there is the re-tooling issue with highlighting editors and the ability to trivially transform between the styles for faster adoption and old code minification -- while these issues certainly shouldn't be deciding factors for TC39 it is nice that leading-char lparen...rparen makes most of them go away. You do yourself a disservice by assuming idiocracy. I don't think Brendan ever assumed that this place is governed by idiots. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bringing setTimeout to ECMAScript
On Sun, Mar 20, 2011 at 6:03 AM, Jorge jo...@jorgechamorro.com wrote: will eventually fire g() before f() is nodejs: https://github.com/joyent/node/pull/604 I've never seen that in any browser. This sounds like a bug in Node's clamping algorithm. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bringing setTimeout to ECMAScript
It doesn't, so we're going to need a non-clamping alias. Perhaps an [ugly] setTimeout ( ƒ, -1 ) ? I posit that the clamping behaviour and timer resolution are domain-specific (embedding-specific) implementation details. Browser makers have been able to deal with run-away CPU scripts, even the ES5 theoretically allows programs which consume all available CPU. Similarly, I'm sure they can manage to figure out how to clamp setTimeout() even if it isn't specified to have an explicit clamping behaviour. That said, I am personally more interested in a set of primitives which can be used to implement setTimeout, rather than setTimeout itself. Although, browser makers will probably have to clamp the primitives, too.. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bringing setTimeout to ECMAScript
On Sat, Mar 19, 2011 at 12:58 PM, Mark S. Miller erig...@google.com wrote: The idea is not stupid at all. It's perfectly sound. For example, the delay example you noticed could be made primitive and setTimeout built out of that. Either can be built from the other. The advantage of layering setTimeout on a new primitive, whether delay or http://nodejs.org/docs/v0.4.3/api/all.html#process.nextTick or something else, is that the new primitive can avoid spec weirdnesses already entrenched for setTimeout, like this 4ms clamping. Instead, this 4ms weirdness could just be specifically part of setTimeout's behavior. I agree 100% - there is no requirement to make setTimeout a fundamental building blocking; it can easily be treated as a high-level API. There is also no need to make the base time measurement unit milliseconds -- it is very easy to see a future where microsecond- or even nanosecond-resolution is desirable. (Assuming, of course, we manage to get over the current GHz barrier to make our individual cores faster). A base specification built on nanosecond-resolution timers gives us a maximal timeout of 104 days with 53-bit integers. That said, I have to ask: is there a reason the base specification needs to discuss time at all? Why not just a function that returns true or false? This still allows us to implement setTimeout in terms of Date, probably requires less specification, and adds more power (is a mouse button down? vs. is it 4 o'clock?) In this untested example which implements setTimeout, I present a function called enqueue, which takes as it's argument a function that returns true if the function is to be re-interested at the end of the event queue once it was evaluated: function setTimeout(f, delay) { var when = +(new Date()) + delay; enqueue(function() { if (+(new Date()) when) return true; if (typeof f === string)) indirectEval(f); else f(); }); } Of course, we could make this a little cheaper by codifying moz's Date.now(), or even having a property of the event system which is the value of the timestamp when the current iteration of the event loop began. In the past, a timer-specific low-level interface may have been desirable from an implementation point of view. I don't believe this the case any more, given two factors -- modern JS engines are really fast at this stuff, and we are not going to be doing any kind of pre-emptive timer (so alarm()-, setitimer()-, etc-backed implementations are unnecessary). I really think if we're looking at setTimeout() we should be looking at arbitrary condition evaluation in the event loop. The embedders will be able to fill in the blanks, and I bet most browser vendors are pretty much already there. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Bringing setTimeout to ECMAScript
Kyle; On Fri, Mar 18, 2011 at 11:53 PM, Kyle Simpson get...@gmail.com wrote: Speaking as someone who has written and currently maintains a *synchronous* server-side JavaScript environment (based on V8), I resemble this description, except that my platform is built on SpiderMonkey rather than V8. That said, I do not share your concerns with respect to the introduction of setTimeout. You've laid out a number of implementation scenarios, but I believe they are properly addressed by the embedding API for your JS engine. Basically, the JS engine can do one of two things: 1) not return until there are no more pending events 2) return immediately, and let the embedder know that there is still code waiting to be serviced, and to provide some kind of servicing API. #1 is an unlikely implementation, as it would not play nicely with the browser, and, frankly, makes for a lousy API. In the strange case where this happens and the program needs to terminate immediately without concern for pending events, you would have to add some kind of mechanism in your platform that causes you to bail immediately. One approach I have implemented in my own work is to throw a Number rather than an Error; e.g. throw 3 behaves a lot like exit(3) in C. #2 is far more likely and gives you total control. Either you can ignore pending events, or you can wait to service them. #2 not only plays well with the browser, but would be very easy to integrate with something like libev if you wanted to implement a platform like Node.js. I would be tickled pink if something like this appeared in SpiderMonkey. What I was saying is, if I run this program through V8 right now (with its theoretical future support of setTimeout() included), then what will happen: function fn() { print(hello); } for (var i=0; i10; i++) { setTimeout(fn,i*1000); } That for-loop will finish very quickly (probably 1 ms). Would V8 (or any other JS engine) finish in the sense that the calling embedding code thinks this program is completely finished, and it returns back control to the C/C++ embedding layer when: a) right after the for-loop finishes; OR b) after only the first call to `fn`, since it's timeout was effectively 0, and so would have been immediately after the main program finished; OR c) after all of the queued up calls to `fn` have finished, about 9 seconds later? a) is my #2, and I believe the right solution -- but I stress that this is an engine question and not a spec question. b) should never happen, and anyhow, it's a special case of either a or c. c) is my #1, and I believe is not a solution any browser-vendor's engine would implementunless the JS engine's event loop also ran the browser, which strikes me as a backwards design. In other words, to put it simply, if program A can call setTimeout(), and I want to run program A and then program B, I have to be able to make sure that I don't try to run program B until everything is fully finished in A. As V8 stands now, there's no way to do anything non-synchronous, so when A finishes, I know it's totally finished. I'm concerned that there'd be some new way with setTimeout()'s that this wouldn't be true. If V8 implements something like #2, they will need to include some kind of an API letting the embedder (you) know about pending events so that you can run them. Like I said, I don't see this being an issue for our use-cases, provided the engine implementors continue to make good decisions. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: iteration order for Object
On Fri, Mar 11, 2011 at 10:07 AM, Claus Reinke claus.rei...@talk21.comwrote: I believe it is very very important that the ECMAScript standard specify that when a new Object is created, for..in iteration traverses properties in the order they are added, regardless of whether the properties are numeric or not. Some users might prefer 'in the order of keys'. That is predictable, and allows for efficient implementation (both sparse and dense). Are you suggesting changing the enumeration order which is currently implemented as iteration order matches insertion order under the careful set of conditions Allen enumerated earlier in this thread? (e.g. no enumerable props on prototype). If so - the thought of this makes me pretty nervous. There is undoubtedly significant amounts of code in the wild on the web which depend on the current enumeration order, and changing this would increase the size of the harmony-uptake tax (code audits and refactors). Someone -- Mark Miller? -- suggested an interesting option when this discussion came up last on this list (around Christmas 2010 IIRC). Basically -- enumerate named props in insertion order, and numeric props in numeric. This gets pretty close to what most developers seem to expect, while leaving the door wide open for fast implementation of array-like objects. Most of these are just awkward ways of saying this is the order I want and I also want hashmap access. So why not write that out explicitly, with an optional ordering parameter, making the enumeration explicit when the default ordering isn't suitable: You know, most of the time when I see valid use-cases for an alternate enumeration order, I can't help but think to myself: this might have a better solution if ES had generators, something like what Mozilla prototyped in JavaScript 1.7, and you could make such a generator the enumeration hook for the object in question. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Interesting ES5 side effect / window.hasOwnProperty(x) !== hasOwnProperty(x)
I bumped into something this morning that I thought might be worth pointing out -- mostly because I was surprised to have seemingly-valid ES3 code break on an ES5 browser without strict mode in play. One of my developers has a habit of writing tests like if (!hasOwnProperty(console)) // supply my own console object instead This works fine on our deployment-target browsers, and up until very recently, on Firefox 4 betas. With the latest Firefox Minefield build, this same code throws a surprising (to me) error: Error: can't convert undefined to object. If I understand the relevant Mozilla bug correctly (and I'm not sure that I do) -- https://bugzilla.mozilla.org/show_bug.cgi?id=619283 -- this is because of the way bindings are looked up in ES5 10.2.1.2.4. Interesting. Comments? Obviously, the work-around is easy -- always invoke window.hasOwnProperty instead of hasOwnProperty -- but I wonder what other daemons lurk in the same corners. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Interesting ES5 side effect / window.hasOwnProperty(x) !== hasOwnProperty(x)
Or am I missing something? Yes -- programmers do all kinds of crazy and unexpected things. :) Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Simple Modules: lazy dependency evaluation
On Wed, Jan 26, 2011 at 5:04 PM, Brendan Eich bren...@mozilla.com wrote: CommonJS may do that on the server side, assuming fast enough file i/o. It's not necessarily a good idea even there (Ryan Dahl has talked about this). On the client, it's right out, which is why client-side CommonJS-like module systems require a preprocessor or else a callback. There is work under way at CommonJS to rectify this problem. A few different proposals have emerged, which all have approximately the same theme: - Explicitly decouple exports-lookup and module loading. - require() remains the exports-lookup interface - Introduce a way to know which modules are needed by a program, such as the explicit declaration of dependencies, or static analysis of the source code looking for require() statements. - Before the main module is executed, load all dependencies (recursively) Adding a mandatory function wrapper to the module source code also allows these modules to be loaded and executed directly by DOM script tag injection (an important technique as XHR has cross-domain restrictions); the function wrapper also provides a convenient place to hang dependencies. Here is what a module in one proposal (Modules/2.0-draft7) looks like: module.declare([*lib/dialog*], function(require, exports, module) { /* Any valid Modules/1.1.1 modules goes here */ require(*lib/dialog*).notify(hello, world); }) (Oh -- main-modules are modules which are executed automatically by the CommonJS host environment; e.g. by exec(3) shebang, HTML script tag, or other mechanism; the mechanism is not part of the specification) I should also say that all the proposals also have a way to explicitly load a particular module at run-time, rather than via the dependency graph. The interface specifies a module name (or names) and a callback. Once the module and its dependent modules are loaded, the callback is executed. This lets us do lazy-loading, like Simple Modules loaders, without breaking run-to-completion. On Wed, Jan 26, 2011 at 6:25 PM, Kam Kasravi kamkasr...@yahoo.com wrote: Are you guys following modules 2.0 at all that seems to be a parallel universe of sorts under co mmonjs? Full disclosure - I am the principle author of that document. It is one of the proposals mentioned above. Its current status is pompously-named document designed to get attention - it is not a standard, and carries only the weight of the paper it is printed on. FWIW, it discusses much more than the CommonJS module system -- it also attempts to nail down the execution environment. That said, there is no way Modules/2.0 belongs under consideration by TC39; it is a best-effort with limited tools proposal; Simple Modules gets to use new tools. On Wed, Jan 26, 2011 at 5:40 PM, David Herman dher...@mozilla.com wrote: Just to flesh this out a bit: simple modules were designed to make it possible to import and export variables into lexical scope, and to be compatible with checking valid imports and exports statically, as well as being able to check for unbound variables statically. Including, for example, in the case where you say import M.*; Moreover, they are designed to allow loading modules *without* having to use callbacks, in the common case where they can be pre-loaded at compile-time. James' query comes as attempt to understand design decisions made for Simple Modules with respect to the timing of the evaluation of the module factory function. With loading and exports now decoupled, the question becomes -- when does require actually evaluate the module body? The balancing point seems to be Is it worth breaking backwards compatibility on existing platforms in order to try and mimic Simple Modules?. Breaking backwards compatibility, in this case, means evaluating the factories eagerly, as they are loaded into the environment as the dependency tree is satisfied (before the main module runs). Currently, factories are executed as side-effects of the first require() call (per module - our modules are singletons). This timing is important, as factories have observable side effects (consider the module above). So, what we're talking about is not just the Simple Modules loader, but the static declaration form as well. Static declaration is analogous to loading a list of modules which is comprised of the main module and its recursive dependencies and then executing the main module. FWIW - my take on this is that porting CommonJS to Simple Modules is going to require a code-audit anyhow; I believe that breaking backwards compatibility within the CommonJS family is not worth trying to mimic such a small sliver of Simple Modules semantics. There are much larger mismatches (singletons, module-keyword, lexical scope, require() to name just a few) which make it a moot point IMO. Kris Kowal's query is interesting: is lazy evaluation worth considering for Simple Modules? module M { export var foo = 42; export
Re: Jan 20 meeting notes
On Thu, Jan 20, 2011 at 8:25 PM, Brendan Eich bren...@mozilla.com wrote: This is the killer for me. Do not want to change === and require all-paths runtime test coverage to migrate code into Harmony. You're bang-on about the end user impact of this change - I would not be able to migrate any ES5 code to Harmony without full-on testing (not just automated regression tests), meaning Harmony uptake would be slowed, particularly in environments like mine where it is most cost effective to pick a language version and use it across all platforms (we are heavily invested in ES, and not just on the browser). Changing the semantics of an existing language feature smarts: I got bit pretty hard as a relatively new JS developer with JavaScript 1.2 and am still wincing. Of course, this is a much smaller change, but we have much more code nowadays.. :) Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 35, Issue 25
Precedent and developer conversations I've had strongly suggest that some code wants mutable primordials on the inside of a module that can be consumed without the mutations affecting the importer's primordials. It would be *really* interesting to have module-local prototypes -- and not only the standard classes, but also for user-defined classes which originate from other modules. Imagine, if you will, that modules add an extra layer in the scope chain which somehow intercepts and proxies prototypes, resolving prototype misses up to the real prototype for said class -- analogous to the way property misses are resolved in JavaScript. moduleA.js: Array.prototype.a = hello; exports.foo = []; moduleB.js: Array.prototype.a = world; exports.foo = []; program.js: print(require(moduleA).foo.a, require(moduleB).foo.a)); print(require(moduleA).foo instanceof Array, require(moduleB).foo instanceof Array)); print(typeof Array.prototype.a); output: hello world true true undefined Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss