Re: how many async-modules can js-app practically load?

[Wes Garland]

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.

[Wes Garland]

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?

[Wes Garland]

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, /#!/JoePea  wrote:

> 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

[Wes Garland]

On 27 October 2017 at 01:48, kai zhu  wrote:

> 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

[Wes Garland]

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 Krems  wrote:

> 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

[Wes Garland]

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 Meadows  wrote:

> 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

[Wes Garland]

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 Dutra  wrote:

> 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

[Wes Garland]

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 Meadows  wrote:

> 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

[Wes Garland]

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ösch  wrote:

> 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

[Wes Garland]

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 Auburtin  wrote:

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

[Wes Garland]

 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?

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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?

[Wes Garland]

 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?

[Wes Garland]

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?

[Wes Garland]

 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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

  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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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”

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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 -

[Wes Garland]

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)

[Wes Garland]

  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

[Wes Garland]

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()

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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?

[Wes Garland]

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

[Wes Garland]

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 ?

[Wes Garland]

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

[Wes Garland]

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.

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

 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

[Wes Garland]

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

[Wes Garland]

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)

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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?

[Wes Garland]

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?

[Wes Garland]

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?

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

 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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

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)

[Wes Garland]

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)

[Wes Garland]

  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

[Wes Garland]

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

[Wes Garland]

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

[Wes Garland]

 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