Re: Function.arguments in JSC

[Oliver Hunt]

We haven’t seen any real problems yet — function.arguments returns a fake 
arguments object with no access to the parameters and that seems to keep sites 
happy.

—Oliver

> On Oct 15, 2014, at 11:52 AM, Tom Schuster  wrote:
> 
> I am curious about how this going. Did you observe any breakage? I will 
> probably look into at least adding a warning for this in Firefox very soon.
> 
> -Tom
> 
> On Sun, Sep 28, 2014 at 10:09 PM, Oliver Hunt  <mailto:oli...@apple.com>> wrote:
> As MarkM said it break on recursion, but we’re also only killing 
> function.arguments, not (alas) function.caller so you can still build 
> “pseudo” stack traces.
> 
> Note that neither .arguments nor .caller work in strict mode functions 
> (they’re specified to throw), and all engines build real stack traces on 
> exceptions nowadays, so presumably you could have 
> function getStackTrace() {
> try {
> throw new Error
> } catch (e) {
> return e.stackTrace; // or whatever it is
> } 
> }
> 
> —Oliver
> 
>> On Sep 28, 2014, at 9:23 AM, Alex Kocharin > <mailto:a...@kocharin.ru>> wrote:
>> 
>>  
>> Yes, it's a powerful meta-programming tool. I don't use it much, but it's 
>> sad to see things like that going away from javascript.
>>  
>> For example, it could allow to build stack traces without any support from 
>> the engine. How do you like this one?:
>>  
>> ```js
>> function type(n) { return typeof n }
>>  
>> function show_trace() {
>>   var me = arguments.callee
>>  
>>   for (var i=0; i<10; i++) {
>> console.log((me.name <http://me.name/> || '')
>>   + ' (' + [].slice.call(me.arguments).map(type) + ')')
>> me = me.caller
>>   }
>> }
>>  
>> function foo() {
>>   show_trace()
>> }
>>  
>> function bar() {
>>   foo(1, 2, 3)
>> }
>>  
>> bar('some string')
>> ```
>>  
>> ```
>> $ node test.js 
>> show_trace ()
>> foo (number,number,number)
>> bar (string)
>>  (object,function,object,string,string)
>>  (string,string)
>>  (object,string)
>>  (string)
>>  (string,object,boolean)
>>  ()
>> startup ()
>> ```
>>  
>>  
>> 28.09.2014, 13:59, "Axel Rauschmayer" > <mailto:a...@rauschma.de>>:
>>> Out of historical curiosity: was `Function.arguments` ever useful for 
>>> anything? Why not simply use `arguments`?
>>> 
>>> On Sep 28, 2014, at 6:51 , John Lenz >> <mailto:concavel...@gmail.com>> wrote:
>>> 
>>>> I took a look at Google's internal code index for reference to 
>>>> Function.prototype.arguments and turned up many references to it 
>>>> (PhpMyAdmin, some Intel benchmark, some internal code, etc).  This is only 
>>>> code used internally at Google (or was at one time) and not by any means 
>>>> an index of the entire web, but it does use the Closure Compiler and type 
>>>> information to accurately find references.  These are not just simply 
>>>> references to an "arguments" property but are references to the 
>>>> "arguments" property off of objects know to be functions.These 
>>>> references roughly (from my quick perusal), were about 50% were V8 or 
>>>> similar unit tests, 25% references that could be trivially replaced with a 
>>>> reference to the active function's "arguments" variable, and 25% were 
>>>> doing something tricky  (Function.caller.arguments, 
>>>> someevent.handler.arguments).
>>>>  
>>>> I'm sure you didn't expect that there would be zero breakage, but I wanted 
>>>> to give you a heads up that there might be more than you expect. 
>>>>  
>>>>   
>>>> 
>>>> On Sat, Sep 27, 2014 at 11:38 AM, Oliver Hunt >>> <mailto:oli...@apple.com>> wrote:
>>>> Hi all, as a heads up we’re going to be doing an experiment in our tree to 
>>>> see if we can kill off the function.arguments property entirely.
>>>>  
>>>> We’re super hopeful we can make it go away safely, and we’ll post a follow 
>>>> up when we have some actual information about what happens.
>>>>  
>>>> If you’re interested in following directly you can track the bug: 
>>>> http://webkit.org/b/137167 <http://webkit.org/b/137167>
>>>>  
>>>> —Oliver
>>> 
>>> -- 
>>> Dr. Axel Rauschmayer
>>> a...@rauschma.de <mailto:a...@rauschma.de>
>>> rauschma.de <http://rauschma.de/>
>>> 
>>> ,
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
>>> https://mail.mozilla.org/listinfo/es-discuss 
>>> <https://mail.mozilla.org/listinfo/es-discuss>___
>> es-discuss mailing list
>> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss 
>> <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Throwing errors on mutating immutable bindings

[Oliver Hunt]

> On Oct 1, 2014, at 9:05 AM, Mark S. Miller  wrote:
> 
> Good point. If we can require all such assignments to be rejected statically, 
> why is a runtime assignment to a const variable even possible? Can't we just 
> assert that this cannot occur?

You mean duplicate assignment? IIRC the problem is code that does

const x;
x=blah;

or 

if (foo)
const x = bar
else
const x = wiffle

etc

Whether this is actually still something that exists - I recall in JSC many 
years ago we had to allow:
for (..) {
const x = ...
...
}

Even though that is technically duplicate assignment.

But i guess that last case is less relevant as const is now always block scoped 
isn't it?

--Oliver
   

> 
> 
> On Wed, Oct 1, 2014 at 8:59 AM, Allen Wirfs-Brock  > wrote:
> 
> On Oct 1, 2014, at 8:39 AM, Mark S. Miller wrote:
> 
> ...
> 
> I was with you until you got to the following point
> 
> >
> > If there is an intervening "with" or sloppy direct eval, then there is not 
> > a statically apparent assignment to a const variable. Since this can only 
> > occur in sloppy code anyway, it seems more consistent with the rest of 
> > sloppy mode for this failed assignment to be silent, rather than 
> > dynamically throwing an error.
> >
> 
> const is a new kind of declaration unlike any declaration form that previous 
> existed in ES, so Ii don't think its handling introduces any legacy 
> consistency issues.  If somebody is using const, regard less of mode, they 
> pretty clearly expect assignments to any const bindings to be illegal.  And, 
> I don't think any body wants new silent failure errors, even in sloppy mode.  
> The most consistent thing is for runtime detected assignments to const 
> bindings to always be noisy errors.  Early where possible, at runtime in the 
> rest of the cases.
> 
> Allen
> 
> 
> 
> 
> -- 
> Cheers,
> --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Throwing errors on mutating immutable bindings

[Oliver Hunt]

JSC does lazy parsing of nested functions and we have no problem reporting 
static errors, so i’m not sure what you believe is the problem here.

—Oliver

> On Oct 1, 2014, at 7:09 AM, Erik Arvidsson  wrote:
> 
> The static error is problematic. I'm pretty sure that engines that do lazy 
> parsing of functions is not going to report static errors before doing a full 
> parse of the function.
> 
> I think we need to either enforce this or remove this restriction. Anything 
> in between will lead to inconsistent behavior between engines.
> 
> On Tue, Sep 30, 2014 at 8:58 PM, Allen Wirfs-Brock  > wrote:
> 
> On Sep 30, 2014, at 5:09 PM, Shu-yu Guo wrote:
> 
>> Hi all,
>> 
>> In the current draft, I see 2 different places where assigning to an 
>> immutable binding ('const') throws an error:
>> 
>> 1) Dynamically throwing a TypeError in SetMutableBinding, 
>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-declarative-environment-records-setmutablebinding-n-v-s
>>  
>> 
>> 2) Statically throwing a Syntax Error in assignment expressions, 
>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-static-semantics-early-errors
>>  
>> 
> see bug https://bugs.ecmascript.org/show_bug.cgi?id=3148 
>  the "can" in that sentence 
> isn't meant to be interpreted as "best effort" but instead more along the 
> lines of "it is provable".
> 
> We need to refine that language, but the test is approximately that there are 
> no with blocks inside the scope of the const declaration and surrounding the 
> reference to the const. binding
> 
>> 
>> 1) throws only in strict mode code, while 2) throws regardless. 2) is also 
>> best effort; seems to be implementation-dependent what "can statically 
>> determine" entails.
>> 
>> Is the intention that assigning to consts silently nops if the 
>> implementation cannot determine the assignment to be to a const statically, 
>> in non-strict code, but implementations *should* make a best effort to 
>> report such cases eagerly, regardless of strictness? Seems kind of odd to 
>> me; perhaps I am misreading?
> 
> 1) looks like a bug to me.  I pretty sure it was never the intent for 
> assignments to const binding to silently fail in non-strict code. The current 
> semantics of SetMutableBinding is a carry over from ES5 where immutable 
> bindings were only used (I have to double check this) for FunctionExpression 
> function name bindings. The legacy of ES3 (hence non-strict ES5) was to did 
> not throw on assignments to such function name bindings.
> 
> I'll probably have to do some extra special casing to preserve the ES3/5 
> semantics for assignment to function names and make the throw unconditional 
> to other immutable bindings
> 
> Allen
> 
> 
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org 
> https://mail.mozilla.org/listinfo/es-discuss 
> 
> 
> 
> 
> 
> -- 
> erik
> ___
> 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: Having a non-enumerable Array.prototype.contains may not be web-compatible

[Oliver Hunt]

The problem is not people actively developing it, or creating new content with 
it.  The problem is _existing_ content that might break. All libraries have 
periods where they are in vogue, and then fade out leaving detritus that hangs 
around for years/decades on major sites.

--Oliver


> On Sep 30, 2014, at 12:45 PM, Andrea Giammarchi  
> wrote:
> 
> "the current state of the web" ... with all due respect for that library, 
> it's been years since I've heard anything about it.
> 
> It's also common on the old web to loop over Arrays via `for/in` to avoid 
> checks for sparse indexes through the entire length ... so making anything 
> enumerable in that native prototype would break something else too form days 
> where `getOwnPropertyNames` was unknown.
> 
> long story short: I definitively +1 what Michał Wadas already said, it's 
> already patched and people must update software anyway due security problems, 
> **patches**, etc etc.
> 
> just my .02
> 
> 
> 
> On Tue, Sep 30, 2014 at 8:18 PM, Boris Zbarsky  > wrote:
> On 9/30/14, 2:45 PM, Michał Wadas wrote:
> Bug in MooTools is not a reason to make any method of Array.prototype
> enumerable.
> 
> I didn't say we need to make it enumerable.
> 
> I said that given the current state of the web, a web browser cannot ship a 
> non-enumerable method named "contains" on Array.prototype.
> 
> The options, therefore, are:
> 
> 1)  Make the method enumerable.
> 2)  Name the method something else.
> 3)  Don't ship the method until every site that currently uses the
> buggy versions of MooTools (which is every site that uses
> MooTools, since they only fixed it 4 days ago).
> 
> I'm perfectly fine with option 3, personally.  Note that in practice that 
> likely means "never ship it" unless people make some sort of concerted effort 
> to get sites to update their MooTools version.
> 
> -Boris
> 
> P.S. It may be worth avoiding the method names mootools sets up but doesn't 
> force-copy in the future.  Even better would be getting them to fix their 
> code so there are no such method names, of course.
> 
> ___
> 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

Re: Function.arguments in JSC

[Oliver Hunt]

As MarkM said it break on recursion, but we’re also only killing 
function.arguments, not (alas) function.caller so you can still build “pseudo” 
stack traces.

Note that neither .arguments nor .caller work in strict mode functions (they’re 
specified to throw), and all engines build real stack traces on exceptions 
nowadays, so presumably you could have 
function getStackTrace() {
try {
throw new Error
} catch (e) {
return e.stackTrace; // or whatever it is
} 
}

—Oliver

> On Sep 28, 2014, at 9:23 AM, Alex Kocharin  wrote:
> 
>  
> Yes, it's a powerful meta-programming tool. I don't use it much, but it's sad 
> to see things like that going away from javascript.
>  
> For example, it could allow to build stack traces without any support from 
> the engine. How do you like this one?:
>  
> ```js
> function type(n) { return typeof n }
>  
> function show_trace() {
>   var me = arguments.callee
>  
>   for (var i=0; i<10; i++) {
> console.log((me.name || '')
>   + ' (' + [].slice.call(me.arguments).map(type) + ')')
> me = me.caller
>   }
> }
>  
> function foo() {
>   show_trace()
> }
>  
> function bar() {
>   foo(1, 2, 3)
> }
>  
> bar('some string')
> ```
>  
> ```
> $ node test.js 
> show_trace ()
> foo (number,number,number)
> bar (string)
>  (object,function,object,string,string)
>  (string,string)
>  (object,string)
>  (string)
>  (string,object,boolean)
>  ()
> startup ()
> ```
>  
>  
> 28.09.2014, 13:59, "Axel Rauschmayer" :
>> Out of historical curiosity: was `Function.arguments` ever useful for 
>> anything? Why not simply use `arguments`?
>> 
>> On Sep 28, 2014, at 6:51 , John Lenz > <mailto:concavel...@gmail.com>> wrote:
>> 
>>> I took a look at Google's internal code index for reference to 
>>> Function.prototype.arguments and turned up many references to it 
>>> (PhpMyAdmin, some Intel benchmark, some internal code, etc).  This is only 
>>> code used internally at Google (or was at one time) and not by any means an 
>>> index of the entire web, but it does use the Closure Compiler and type 
>>> information to accurately find references.  These are not just simply 
>>> references to an "arguments" property but are references to the "arguments" 
>>> property off of objects know to be functions.These references roughly 
>>> (from my quick perusal), were about 50% were V8 or similar unit tests, 25% 
>>> references that could be trivially replaced with a reference to the active 
>>> function's "arguments" variable, and 25% were doing something tricky  
>>> (Function.caller.arguments, someevent.handler.arguments).
>>>  
>>> I'm sure you didn't expect that there would be zero breakage, but I wanted 
>>> to give you a heads up that there might be more than you expect. 
>>>  
>>>   
>>> 
>>> On Sat, Sep 27, 2014 at 11:38 AM, Oliver Hunt >> <mailto:oli...@apple.com>> wrote:
>>> Hi all, as a heads up we’re going to be doing an experiment in our tree to 
>>> see if we can kill off the function.arguments property entirely.
>>>  
>>> We’re super hopeful we can make it go away safely, and we’ll post a follow 
>>> up when we have some actual information about what happens.
>>>  
>>> If you’re interested in following directly you can track the bug: 
>>> http://webkit.org/b/137167 <http://webkit.org/b/137167>
>>>  
>>> —Oliver
>> 
>> -- 
>> Dr. Axel Rauschmayer
>> a...@rauschma.de <mailto:a...@rauschma.de>
>> rauschma.de
>> 
>> 
>> ,
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss 
>> <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

Function.arguments in JSC

[Oliver Hunt]

Hi all, as a heads up we’re going to be doing an experiment in our tree to see 
if we can kill off the function.arguments property entirely.

We’re super hopeful we can make it go away safely, and we’ll post a follow up 
when we have some actual information about what happens.

If you’re interested in following directly you can track the bug: 
http://webkit.org/b/137167 

—Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Early error on '0' followed by '8' or '9' in numeric literals does not seem to be web-compatible

[Oliver Hunt]

JavaScriptCore has never allowed octal sequences (anything other than a . or x 
after 0) in strict mode, and we haven't had any problems with it.

--Oliver


> On Aug 5, 2014, at 11:13 AM, Allen Wirfs-Brock  wrote:
> 
> 
> On Aug 5, 2014, at 8:38 AM, Mathias Bynens wrote:
> 
>> On 5 Aug 2014, at 17:19, Mark S. Miller  wrote:
>> 
>>> On Tue, Aug 5, 2014 at 8:17 AM, Mathias Bynens  wrote:
>>> 
 The literals under discussion (e.g. `08` and `09`) are not octal literals.
>>> 
>>> Strict mode should reject these even more vehemently! (Allen, can we have 
>>> an early vehement error?)
> 
> I think we weren't clear enough in the ES5 spec.  The base-line grammar says 
> that starting a decimal literal (other than a single '0') with a 'o' is not 
> valid syntax.  You should expect to get a syntax error for 00, or 07, or 08, 
> or0123456789, or 01234567, etc.  ES5 Annex B defines an extension that makes 
> sequences of digits (excluding '8' or '9') legal syntax.  But section 7.8.3 
> says that that particular extension is not allowed in strict mode code.
> 
> The problem is that there is another extensions (that is not in ES5 Annex B) 
> that allows and gives meaning for '0' followed by digit sequences that 
> include the digits '8' and/or '9'.  I'm pretty sure that when drafting ES5 we 
> thought the restriction in 7.8.3 was making making both of these extensions 
> illegal in strict mode. Apparently most real world browsers didn't interpret 
> things that way which is unfortunate.
> 
>> 
>> Now I’m confused again. That contradicts what Allen said earlier in this 
>> thread:
>> 
>> On 5 Aug 2014, at 16:20, Allen Wirfs-Brock  wrote:
>> 
>>> Regarding, leading 0 constants in strict mode. The long term plan is to 
>>> eventually make them legal decimal constants.
>> 
>> I stand by my earlier suggestion:
>> 
>> 1. Accept decimal integer literals with leading `0`, even in strict mode.
>> 2. Interpret the value of such literals as octal in case they consist of 
>> octal digits only. (Note: this is already in Annex B – see 
>> `LegacyOctalIntegerLiteral`.)
>> 
>> Strict mode would accept `08` as it’s a zero-prefixed decimal literal but 
>> not `07` since that’s an octal literal.
>> 
>> This matches what all browsers already do (except Firefox), and fulfills the 
>> long-term plan Allen was talking about.
> 
> I think this is more or less the strategy we should follow.
> 
> All browsers in all modes apparently interpret leading 0 numbers that contain 
> the digits "8" or "9" as decimal literals.  We should make that part of the 
> base language for ES6.
> 
> The ES6 base language should make leading 0 numbers containing only octal 
> digits ("1"-"7") syntactically illegal.
> 
> Annex B can continue to define the meaning for  such leading 0 octal numbers. 
>  And strict mode still makes that annex B extension illegal
> 
> Someday, when strict mode/modules is more dominant we can relax the 
> restriction of leaning 0 numbers without "8" or "9" and make all leading 0 
> numbers decimal literals in strict mode.
> 
> Allen
> 
> 
> 
> ___
> 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: "use es6"; Any plans for such a mode?

[Oliver Hunt]

> On Jul 29, 2014, at 12:02 PM, Christoph Martens  wrote:
> 
> Hey all,
> 
> I just read a bit about the ParallelJS project, Typed Objects (StructType) 
> and was curious if I could implement bindings for v8 today.
> 
> Link to wiki document: 
> http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects 
> 
> 
> 
> I realized that I don't know what to do if someone has code like this:
> 
> typeof uint8; // "undefined" in ES5
> 
> This code will be valid in an ES5 environment, because uint8 is an undefined 
> reference/variable. But as uint8 is a built-in value type, what should happen 
> in an ES6 environment?

uint8 is not a value of type uint8, it's the name of the type itself so 
presumably it will return "object" or some such (i haven't read structural type 
spec yet). Anyway, this typeof check is used to identify support for the API 
rather than anything else.

I'm also opposed to adding yet another mode switch, as just "use strict" has 
added complexity throughout JSC, and has minimal benefit.  This would have even 
less benefit than that, I think the problem here is that you're assuming a lot 
more static inference than actually occurs - JS is a dynamic language so most 
performance/correctness work is performed dynamically as it is unavoidable.

--Oliver


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Trailing comma for function arguments and call parameters

[Oliver Hunt]

On Jul 3, 2014, at 3:52 PM, Dmitry Soshnikov  wrote:

> Hi,
> 
> Will it makes sense to standardize a trailing comma for function arguments, 
> and call parameters?
> 
> We have it for Array and Object initialisers, and people like using them for 
> long lists with prediction of new items adding in the future:
> 
> ```
> var modes = [
>   read,
>   write,
> ];
> 
> var platforms = {
>   web,
>   canvas,
> };
> ```

I suspect, but brendan could tell us otherwise, that the allowance of trailing 
commas is a result of a bug in the _early_ _early_ days of JS, which then got 
matched by the wonders of bug for bug compat, and so became necessary for web 
compatibility.

Also, i’m not sure that your intended uses is sufficiently compelling to 
justify non-backwards compatible syntax (i’m not against adding new syntax, i 
just feel that it needs to have substantial benefits)

Hence, i don’t think this should be extended to other constructs.

—Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: .entries() vs. the web

[Oliver Hunt]

@@unscopeable doesn't work as they are not using |with|

The logic is something along the lines of 

if (foo.entries) ...

It looks like there are paths that objects or arrays may path through, with 
"entries" being a perfectly reasonable property name in the object case, but 
now the array case hits the entries property on Array.prototype

--Oliver

> On Jun 16, 2014, at 4:10 PM, Erik Arvidsson  wrote:
> 
> That is why you need to implement @unscopables too.
> 
> On Jun 16, 2014 7:08 PM, "Oliver Hunt"  wrote:
> It turns out there are a number of sites (such as mobile.twitter.com) that 
> are property detecting .entries on objects, and that means that they're 
> breaking when Array.prototype.entries is provided.
> 
> We're removing it from JSC now, until we can find a way to expose it without 
> causing site breakage, although this does seem like fixing it would require 
> bringing back the awful "pretend that you're undefined" horror.
> 
> --Oliver
> 
> 
> ___
> 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

.entries() vs. the web

[Oliver Hunt]

It turns out there are a number of sites (such as mobile.twitter.com) that are 
property detecting .entries on objects, and that means that they're breaking 
when Array.prototype.entries is provided.

We're removing it from JSC now, until we can find a way to expose it without 
causing site breakage, although this does seem like fixing it would require 
bringing back the awful "pretend that you're undefined" horror.

--Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Safari 8 ES6-ish implementation.

[Oliver Hunt]

All these bugs can be filed at bugs.webkit.org (which is a much better place 
than a mailing list), anyway:

On Jun 4, 2014, at 1:08 PM, C. Scott Ananian  wrote:

> So... Safari 8's betas were just released.  It contains a partial ES6 
> implementation -- but one which fails many of `es6-shim`s test cases.  See 
> https://github.com/paulmillr/es6-shim/issues/252#issuecomment-45141791
> 
> Is anyone on es6-discuss in contact with the Safari team?  Can we get Safari 
> 8 made spec-compliant before release, so that es6-shim doesn't have to shim 
> around a broken implementation?
> 
> In particular:
> * `ArrayIterator` is exposed as a global
https://bugs.webkit.org/show_bug.cgi?id=133494

> * `Array#find` and `Array#findIndex` don't work right on sparse arrays or 
> array-like objects
Fixed in trunk

File bugs on anything you encounter - we can’t fix bugs if we don’t know that 
they’re there.

—Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: RFE: Allow newline when returning an anonymous object

[Oliver Hunt]

> On May 28, 2014, at 11:48 AM, cowwoc  wrote:
> 
> 
> That's an unfortunate side-effect. I think that developers should be able to 
> pick their own code styles. After all, most of these choices are subjective. 
> Anyway, thanks for the head's up.

They can choose their own style, just not their own syntax.

> 
> Gili

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: RFE: Allow newline when returning an anonymous object

[Oliver Hunt]

> On May 28, 2014, at 11:39 AM, cowwoc  wrote:
> 
> 
> 
> Don't we use a semicolon to denote the end of an expression context? Perhaps 
> I'm missing something, but I see no ambiguity in the example you gave. I 
> expect:
> 
>   return {};
> 
> and
> 
>   return
>   {};
> 
> to return an object literal, whereas:
> 
>   return; {}
> 
> or
> 
>   return;
>   {}
> 
> denote a return expression followed by a block.

No, the semicolon is not relevant as it is optional, the rules for ASI result in

return
{}

being converted to 
return ; 
{};

If you remove the newline restriction from return then ASI becomes ambiguous as 
well.

--Oliver

> 
> Gili

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: RFE: Allow newline when returning an anonymous object

[Oliver Hunt]

> On May 28, 2014, at 11:23 AM, cowwoc  wrote:
>> 
>> if (foo)
>>   return
>> {
>> L: print(something)
>> }
>> 
>> The only way to disambiguate this in the general case is to have a rule
>> such as 
>> 
>> to allow us to be sure that the opening brace is in an expression context
>> and not a statement.
>> 
>> --Oliver
> 
> Hi Oliver,
> 
> Excuse my ignorance, but can you explain (or point me to a layman
> explanation) of the difference between the two forms?
> 

I'm not sure what you mean by two forms - i'm assuming that you mean that 
you're interpreting the {}'s in both

return {}

and

return
{}

As being object literals, when in fact the second is a return statement, 
followed by a  block statement.

This ambiguity is why the opening brace is only consider an object literal if 
we are already in an expression context.  If you are not in an expression 
context, you must be starting a statement, and so the open brace is the start 
of a block statement.

What you're asking for is grammatically ambiguous in a way that would 
potentially break existing content, and (generally) leads to really interesting 
parsing behaviour.

--Oliver

> Thanks,
> Gili
> 
> 
> 
> --
> View this message in context: 
> http://mozilla.6506.n7.nabble.com/RFE-Allow-newline-when-returning-an-anonymous-object-tp316480p316482.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at 
> Nabble.com.
> ___
> 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: RFE: Allow newline when returning an anonymous object

[Oliver Hunt]

> On May 28, 2014, at 11:10 AM, cowwoc  wrote:
> 
> I would like the specification to also allow the following syntax: 
> 
> return 
> { 
>  key: "value" 
> }; 

This is currently valid syntax, and has an entirely different behaviour (and 
side effects) from returning an object literal. This means that even if we 
wanted to we could not change that behaviour without potentially breaking 
existing content.

That said our reason for the required newline is that it provides a mechanism 
to disambiguate the grammar and semantics of object literal vs. block 
statements.

The following for instance has totally different behaviour depending on whether 
the new line is used:

if (foo)
   return
{
L: print(something)
}

The only way to disambiguate this in the general case is to have a rule such as 
 to allow us to be sure that the opening brace is in an expression 
context and not a statement.

--Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bytecode

[Oliver Hunt]

On May 15, 2014, at 10:24 PM, Andrea Giammarchi  
wrote:

> but you mentioned very old one I think nobody cares much anymore ;-)

People may not “care” about them today, but that doesn’t mean that no one uses 
them - there are many millions of webpages that use these libraries still, and 
that means performance of those libraries is extremely important to end _users_.

Regarding the original topic of this thread: I think there have been many many 
prior discussions of a standardised bytecode on es-discuss, and people should 
really be reading those before bringing this up again.  It’s not going to 
happen as no one has ever demonstrated an actual benefit over simply using JS.

—Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring and evaluation order

[Oliver Hunt]

On Apr 25, 2014, at 10:42 AM, Allen Wirfs-Brock  wrote:

> 
> On Apr 25, 2014, at 10:25 AM, Oliver Hunt wrote:
> 
>> 
>> On Apr 25, 2014, at 4:24 AM, Andreas Rossberg  wrote:
>> 
>>> The way destructuring assignment currently is specified leads to
>>> rather inconsistent evaluation order. Consider:
>>> 
>>> let o = {}
>>> function f() { print(1); return o }
>>> function g() { print(2); return 5 }
>>> 
>>> f().x = g()// 1, 2
>>> {a: f().x} = {a: g(}}   // 2, 1
>>> 
>>> That is, destructuring assignments violate the left-to-right
>>> evaluation that is otherwise maintained.
>>> 
>> 
>> I don’t believe that there is any reason to break from left-to-right 
>> evaluation order.  Even if it was uncommon it’s still an unnecessary hazard.
>> 
>> Spec bug maybe?
> 
> Nope, it's always been designed this, going back to the original wiki 
> strawman 
> http://wiki.ecmascript.org/doku.php?id=harmony:destructuring#semantics and I 
> assume the original FF implementation.
> 
> It has also been something that we has been discussed here and in TC39 
> multiple times.  If we wan to revisit this decision we really need to dredge 
> up all of those previous discussions to see if there is new data that would 
> cause us to change this decision. 
> 
> Basically for destructing assignment, each property element can be an 
> arbitrary assignment expression and all of their Reference values would have 
> to be saved to get left to right order. 

Yup.  Honestly I don’t think destructuring to an arbitrary expression would be 
that common so I think it’s worth it to define order of operations as being 
left to right and leave it to the engines to optimise things sanely.

Burning some stack space to hold the intermediate slots doesn’t seem that bad, 
although that said I’ve forgotten what the semantics for

o = {__proto__: {set foo() {print(“bar”)}}
o.foo = (o.__defineSetter__(“foo”, function(){ print(“foo”)})), 5

Is expected to be (I could see what we actually _do_ but that’s no guarantee 
that it’s the right thing).

—Oliver


> 
> Allen
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring and evaluation order

[Oliver Hunt]

On Apr 25, 2014, at 4:24 AM, Andreas Rossberg  wrote:

> The way destructuring assignment currently is specified leads to
> rather inconsistent evaluation order. Consider:
> 
>  let o = {}
>  function f() { print(1); return o }
>  function g() { print(2); return 5 }
> 
>  f().x = g()// 1, 2
>  {a: f().x} = {a: g(}}   // 2, 1
> 
> That is, destructuring assignments violate the left-to-right
> evaluation that is otherwise maintained.
> 

I don’t believe that there is any reason to break from left-to-right evaluation 
order.  Even if it was uncommon it’s still an unnecessary hazard.

Spec bug maybe?

—Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Initializer expression on for-in syntax subject

[Oliver Hunt]

I’ve landed the change to JSC to silently ignore the assignment in the 
non-strict “var ident =“ case, everything else is still an error so 
deconstruction and |of| enumeration will trigger a syntax error.

—Oliver

On Mar 15, 2014, at 2:01 PM, Brendan Eich  wrote:

> Brendan Eich wrote:
>> Peter van der Zee wrote:
>>> 
>>> Which browsers currently don't accept this construct? I wasn't even aware 
>>> that JSC didn't support it at some point.
>>> 
>> 
>> Did anyone say JSC lacked support? I think KJS followed ES3, and this was in 
>> the ES1 grammar, so I doubt it was never supported.
> 
> Of course I was excluding the recent removal per draft ES6 that Oliver 
> mentions in the root of this thread, "JSC has been trying to kill off the 
> initialiser expression in the for(in) statement" -- sorry for confusion. Just 
> to be clear, this is recent and per ES6, intentional.
> 
> Hoping my site evang pals can get somewhere with battlefield.com.
> 
> /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

Initializer expression on for-in syntax subject

[Oliver Hunt]

JSC has been trying to kill off the initialiser expression in the for(in) 
statement, but we've encountered a bunch of reasonably significant content that 
breaks with it disallowed (a particularly prominent one currently is 
http://battlelog.battlefield.com/bf4/), so we will be bringing back support for

for (var Identifier = Expression in Expression)

--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error objects in W3C APIs

[Oliver Hunt]

On Feb 5, 2014, at 12:05 AM, Jonas Sicking  wrote:

> On Tue, Feb 4, 2014 at 9:49 AM, Domenic Denicola
>  wrote:
>> From: es-discuss  on behalf of Allen 
>> Wirfs-Brock 
>> 
>>> I've designed exception handling systems before and designed and worked 
>>> with complex exception hierarchies. My main caveat is that they are 
>>> somewhat of an attractive nuisance.  It's easy to get into designing  
>>> beautiful classification hierarchies of dozens of different kinds of 
>>> exceptions, each with their own specific failure information that is 
>>> captured. In practice, I've found very little actual utility for them.
>> 
>> My (more limited) experience is the same.
> 
> I agree. Creating hierarchies of error "types" seems fragile to me.
> 

The other problem (an extension of “fragile”) is error objects when more than 
one global object/realm is involved.  Once you’re in that scenario type 
selection (e.g. making use of |instanceof|) can no longer be used in any 
meaningful way.

—Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Oliver Hunt]

On Jan 30, 2014, at 11:27 AM, John Lenz  wrote:

> I don't argue that it isn't a useless "let".  I do point out that in "sloppy" 
> mode, that other declaration are allow in practices by browsers.  Chrome 
> allows function, const, and var in the body of an if without block.  
That’s because they _have_ to be allowed as these constructs are used on 
millions (billions?) of web pages.  Disallowing that behaviour would break the 
web and we can’t do that.

Introducing new constructs that expose the same coding problems is not worth it 
- maybe we would want to change something in the future but we would already 
have been burned by existing content using this code incorrectly.

—Oliver

> 
> It does seems like an unnecessary restriction, and with it I'll need to make 
> sure that Closure Compiler doesn't introduce these when stripping blocks, not 
> a big deal just one more thing to deal with.
> 
> I was just hoping that the restriction was enabling something and not just 
> noise.
> 
> 
> On Thu, Jan 30, 2014 at 11:00 AM, Brendan Eich  wrote:
> John Barton wrote:
>  Not silly. Can you suggest any on-line that most JS developers can 
> understand discussing how these two forms differ?
> 
> Here are some that describe them as equivalent:
> 
> http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
> http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx 
> 
> 
> http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no
> http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
> http://msdn.microsoft.com/en-us/library/ms173143.aspx
> 
> and so on across multiple languages.  Whether or not you think these forms 
> should be different, programmers don't expect them to differ.
> 
> This is all beside the point, since the unbraced let as consequent of if 
> cannot make a useful binding (if you use comma-separated multiple 
> declarators, you still can't use any of the values that initialize the 
> bindings except in later useless-outside-the-single-declaration consequent).
> 
> /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: restrictions on let declarations

[Oliver Hunt]

On Jan 30, 2014, at 8:07 AM, Dean Landolt  wrote:

> 
> 
> 
> On Thu, Jan 30, 2014 at 10:59 AM, John Barton  wrote:
> 
> 
> 
> On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich  wrote:
> John Lenz wrote:
> Generally, I've always thought of:
> 
> "if (x) ..." as equivalent to "if (x) { ... }"
> 
> let and const (and class) are block-scoped. {...} in your "if (x) {...}" is a 
> block. An unbraced consequent is not a block, and you can't have a 
> "conditional let binding".
> 
> The restriction avoids nonsense such as
> 
> let x = 0; { if (y) let x = 42; alert(x); }
> 
> What pray tell is going on here, in your model?
> 
> I'm with John: the alert should say 0 and I can't see why that is not obvious.
> 
> 
> It's not obvious at all -- what happens when you drop the initial `let x = 
> 0;` and you just have `{ if (y) let x = 42; alert(x); }` -- now what happens? 
> Is x declared or not?
> 
> To my mind `if (y) let x = 42;` reads like it's own 1-line noop block -- at 
> least, that's what I'd expect of the scope. So while it could be allowed in 
> that sense, it'd only serve as a footgun when y is true.

This is exactly foot gun the language restriction is intended to avoid.

Most modern [Obj-]C[++] will warn on this (well, s/let/int/)

You might be getting confused because of the bizarro var hoisting semantics of 
var

if (y) let x = “nope"; alert(x)

Results in an unusable binding of x, and so this would throw (the foot gun 
occurs if you’re shadowing x, that’s another shadow that i think C compilers 
will warn on), e.g..
y = true; let x = “whoops”; if (y) let x = “nope"; alert(x) // “whoops"

The var case

y = true; var x = “whoops”; if (y) var x = “nope"; alert(x); // “nope"

is actually interpreted as

var x; y= true; x = “whoops”; if (y) x = “nope”; alert(x); // “nope"

That craziness is the whole point of block scoping let.  More interestingly

if (window.SomeCrazyDomFeature) var foo = true;

is a common web idiom as it brings foo into scope for everything, so makes 
later "if (foo) “ statements safe.  Anyone trying to do this with a |let| would 
get incorrect (from their PoV) behaviour.  Again that’s why we error out.

Give that this is the behaviour of every other block scoped language i don’t 
see why this is confusing.

—Oliver

> ___
> 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: detecting JS language mode for tools

[Oliver Hunt]

I believe the conclusion with |let| was to identify let syntax:
let foo(=*) is syntactically unambiguous, just a bit more work to identify.

yield is only valid in generators (function*) so that gets reserved the moment 
you enter a generator definition 

—Oliver

On Jan 24, 2014, at 9:11 AM, John Lenz  wrote:

> You don't get "let", "function" block scoping, "yield" or other incompatible 
> constructs. (let and yield aren't a reserved word in ES5 "loose)
> 
> 
> On Fri, Jan 24, 2014 at 8:49 AM, Tab Atkins Jr.  wrote:
> On Fri, Jan 24, 2014 at 8:48 AM, John Lenz  wrote:
> > For static language parsers there seems to be a bit of a dilemma with ES6
> > modules.  I would appreciate a correct or hint.
> >
> > Here is my understanding:
> >
> >   - standard scripts as we know them today will parse in the browser as
> > "loose" code
> >   - scripts with the standard "use strict" will parse as "strict" with
> > access to all ES6 goodness
> 
> Loose code will also get all the ES6 goodness.  1JS and all that.
> 
> ~TJ
> 
> ___
> 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: Name of WeakMap

[Oliver Hunt]

(I know Anne knows this argument, but i’m emailing this logic for people who 
aren’t aware of it)

The reason for prefixing APIs is to allow a feature to be shipped and used by 
developers before the final api semantics are settled on.  In the event the 
spec doesn’t change then they simply alias, but if the spec does change it 
allows an engine to continue to maintain the old behaviour in the prefixed API 
and so not break any content that depends on the API.

Saying that you should never ship anything if it would need prefixing means 
that you can never see real examples of usage because no _real_ site is going 
to use a feature that isn’t available in actual shipping browsers.  If the API 
is not prefixed then once it ships and is used it can never be fixed under the 
same name (see localStorage being stuck with a string backing store).  That’s 
why prefixed APIs exist — it’s not so we can say the API is unstable, it’s so 
that the API can be changed once developers have started using preliminary 
versions.

In my opinion the cost of maintaining an old version of the API may be 
annoying, but is vastly outweighed by the ability to put features in the hands 
of authors without forcing the API to be stuck with it’s early draft semantics.

—Oliver


On Dec 16, 2013, at 1:42 PM, Anne van Kesteren  wrote:

> On Mon, Dec 16, 2013 at 7:01 PM, Andrea Giammarchi
>  wrote:
>> We are all use to write abominations such `var url = window.webkitURL ||
>> windows.mozURL || windows.URL` and similar stuff all over, the reason
>> utilities libraries are often preferred, so while I am very happy that IE
>> team finally has been able to catch up and be even in front of other
>> browsers, I do believe that incomplete specifications or those still under
>> discussion should be adopted with prefixes until finalized in their form in
>> order to promote less mistakes in the long term.
> 
> That way you end up with e.g. having to support mozMatchesSelector()
> forever in addition to matches(). We're certainly going to avoid doing
> that in Gecko.
> 
> If you're unclear on the name, just make it clear in the specification
> that the name is not stable and that therefore it cannot ship yet (you
> could implement it and ship it in nightlies and such of course).
> 
> 
> -- 
> http://annevankesteren.nl/
> ___
> 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: Name of WeakMap

[Oliver Hunt]

The problem i have with SideTable as a name is that it’s implying a very 
specific use case (one that could equally be served by private names), it’s 
also not an obvious name to developers who are not aware of terms of art.

I said a long time ago that the name WeakMap did not match the expected 
semantics of other languages, nor what was expected by developers but we 
couldn’t think of a good alternative name, and (i thought) decided that 
sticking with WeakMap was the best of the bad options.

—Oliver

On Dec 16, 2013, at 1:09 PM, Allen Wirfs-Brock  wrote:

> 
> On Dec 16, 2013, at 9:34 AM, Bjoern Hoehrmann wrote:
> ...
>> 
>> (The name "SideTable" makes me think I seriously need to re-evaluate
>> what `WeakMap` is supposed to be.)
> 
> That is what was so attractive about changing the name.  
> 
> Allen
> ___
> 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: Function.prototype.apply() & Function.prototype.call() with `undefined` or `null` as `thisArg`

[Oliver Hunt]

new Function is simply calling a constructor - the fact that it creates a 
callable object is irrelevant as there is nothing magical about the constructor 
itself.

The new function object itself is also scoped to the root lexical environment, 
not the strict mode function it is being called from, so it wouldn’t make sense 
for it to gain lexical state form the caller.

—Oliver

On Dec 10, 2013, at 10:13 AM, Andrea Giammarchi  
wrote:

> and don't forget the lovely "de-stricter" ^_^
> 
> ```javascript
> function wut() {
>   'use strict';
>   // oh wait, not anymore ...
>   return Function('return this')();
> }
> 
> wut() === window; // true
> ```
> 
> Anyway, trying to retrieve the native global a part, I don't think there's 
> any other meaningful use case for having null or undefined "translated" into 
> an object so "use strict" in this case (giving the possibility to retrieve 
> the global via Function) is actually welcome: ES6 should follow, imo
> 
> 
> On Tue, Dec 10, 2013 at 7:54 AM, Allen Wirfs-Brock  
> wrote:
> 
> On Dec 10, 2013, at 5:32 AM, Mathias Bynens wrote:
> 
>> Turns out this is a bug in the spec: 
>> https://bugs.ecmascript.org/show_bug.cgi?id=2370
> 
> I'll respond further when i deal with the actual bug report , but for now, 
> I'm not sure I agree with your conclusion.
> 
> What you have been talking about (and what Annex C describes) is the 
> end-to-end behavior of using call/apply to invoke a function.  That includes 
> the local semantics of call/apply, but also the semantics of various [[Call]] 
> internal methods and the entry semantics of strict, non-strict, and built-in 
> functions. 
> 
> The Note attached to the spec. of the Call/Apply function is highlighting an 
> essential change to their local semantics that was introduced in ES5.  
> However, that local change has no effect on the observable end-to-end 
> behavior of calling a non-strict function.  It is observable for strict 
> functions. 
> 
> In general, you have to follow the spec. end-to-end to understand the 
> end-to-end semantics.
> 
> Perhaps, it is reasonable to assume that implementation have already made the 
> transition from ES3 to ES5 semantics and the local note is no longer need in 
> the ES6 spec.
> 
> Allen
> 
> 
> ___
> 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

Re: Formalize error.stack?

[Oliver Hunt]

Righto, filed https://bugs.webkit.org/show_bug.cgi?id=124220

—Oliver

On Nov 12, 2013, at 12:30 PM, Mark Miller  wrote:

> FWIW, the code I linked to, which arv refers to, when it finds itself on SM, 
> normalizes the SM error stack string to approx v8's format. But the more 
> important part of the answer is the parsed form provided by getCWStack. 
> 
> 
> On Tue, Nov 12, 2013 at 12:20 PM, Oliver Hunt  wrote:
> Righto, do we know whether Carakan/V8’s text or SM’s text is preferred?
> 
> Currently it seems like JSC’s is a little bit weird compare to others, and as 
> i’ve said earlier i’m happy to change it to match another engine (we all have 
> the same info in varying ways, so we can all technically produce the same 
> view in our .stack string)
> 
> —Oliver
> 
> On Nov 12, 2013, at 11:17 AM, Erik Arvidsson  wrote:
> 
>> On Tue, Nov 12, 2013 at 12:35 PM, Oliver Hunt  wrote:
>> The only formatting requirement for the stack property is that if it is 
>> present, it must be a string.
>> 
>> No. There is a lot of code out there that parses this string and depend on 
>> the format.
>> 
>> 
>> See Mark's reply for one such case.
>>  
>> 
>> —Oliver
>> 
>> On Nov 12, 2013, at 9:23 AM, Erik Arvidsson  wrote:
>> 
>>> When I started investigating this I had the hope that stack could be 
>>> standardized. However, the format of the string is cannot be changed 
>>> without breaking the web so the way forward is to introduce a new property 
>>> name. But since we are introducing a new property name we should return 
>>> structured data instead of a plain old string.
>>> 
>>> I haven't had the time to work on this since my initial analysis of the 
>>> state of the stack property.
>>> 
>>> 
>>> On Mon, Nov 11, 2013 at 7:51 PM, John Barton  wrote:
>>> Note that in Chrome the devtools are remote and error.stack is a getter 
>>> which issues a remote method call to the backend.  Only when the stack 
>>> property is accessed will the internal representation be converted to a 
>>> string. Anything else is too expensive. 
>>> 
>>> A plain JS object format would be much more useful for development tools 
>>> developers.
>>> 
>>> jjb
>>> 
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> erik
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> 
>> 
>> -- 
>> erik
> 
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
> Text by me above is hereby placed in the public domain
> 
>   Cheers,
>   --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Formalize error.stack?

[Oliver Hunt]

Righto, do we know whether Carakan/V8’s text or SM’s text is preferred?

Currently it seems like JSC’s is a little bit weird compare to others, and as 
i’ve said earlier i’m happy to change it to match another engine (we all have 
the same info in varying ways, so we can all technically produce the same view 
in our .stack string)

—Oliver

On Nov 12, 2013, at 11:17 AM, Erik Arvidsson  wrote:

> On Tue, Nov 12, 2013 at 12:35 PM, Oliver Hunt  wrote:
> The only formatting requirement for the stack property is that if it is 
> present, it must be a string.
> 
> No. There is a lot of code out there that parses this string and depend on 
> the format.
> 
> 
> See Mark's reply for one such case.
>  
> 
> —Oliver
> 
> On Nov 12, 2013, at 9:23 AM, Erik Arvidsson  wrote:
> 
>> When I started investigating this I had the hope that stack could be 
>> standardized. However, the format of the string is cannot be changed without 
>> breaking the web so the way forward is to introduce a new property name. But 
>> since we are introducing a new property name we should return structured 
>> data instead of a plain old string.
>> 
>> I haven't had the time to work on this since my initial analysis of the 
>> state of the stack property.
>> 
>> 
>> On Mon, Nov 11, 2013 at 7:51 PM, John Barton  wrote:
>> Note that in Chrome the devtools are remote and error.stack is a getter 
>> which issues a remote method call to the backend.  Only when the stack 
>> property is accessed will the internal representation be converted to a 
>> string. Anything else is too expensive. 
>> 
>> A plain JS object format would be much more useful for development tools 
>> developers.
>> 
>> jjb
>> 
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> 
>> 
>> -- 
>> erik
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
> erik

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Formalize error.stack?

[Oliver Hunt]

The only formatting requirement for the stack property is that if it is 
present, it must be a string.

—Oliver

On Nov 12, 2013, at 9:23 AM, Erik Arvidsson  wrote:

> When I started investigating this I had the hope that stack could be 
> standardized. However, the format of the string is cannot be changed without 
> breaking the web so the way forward is to introduce a new property name. But 
> since we are introducing a new property name we should return structured data 
> instead of a plain old string.
> 
> I haven't had the time to work on this since my initial analysis of the state 
> of the stack property.
> 
> 
> On Mon, Nov 11, 2013 at 7:51 PM, John Barton  wrote:
> Note that in Chrome the devtools are remote and error.stack is a getter which 
> issues a remote method call to the backend.  Only when the stack property is 
> accessed will the internal representation be converted to a string. Anything 
> else is too expensive. 
> 
> A plain JS object format would be much more useful for development tools 
> developers.
> 
> jjb
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
> erik
> ___
> 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: Removing Array.prototype.values

[Oliver Hunt]

For reference, i’ve just removed the API from JSC.  Default iterator still does 
the right thing.

—Oliver

On Nov 11, 2013, at 12:51 PM, Rick Waldron  wrote:

> 
> 
> 
> On Mon, Nov 11, 2013 at 3:13 PM, Allen Wirfs-Brock  
> wrote:
> Right, but the revised spec. for @@unscopables isn't in the Rev21 draft.   
> 
> See https://bugs.ecmascript.org/show_bug.cgi?id=1908 for the changes that 
> will be in Rev22.
> 
> 
> Sorry, I misread this, please ignore my previous response.
> 
>  
> Allen
> 
> 
> 
> 
> On Nov 11, 2013, at 12:01 PM, Rick Waldron wrote:
> 
>> 
>> 
>> 
>> On Mon, Nov 11, 2013 at 2:59 PM, Boris Zbarsky  wrote:
>> On 11/11/13 2:47 PM, Oliver Hunt wrote:
>> Alas in addition to assuming that the Arguments object does not have the 
>> Array prototype, ExtJS also relies on the Array prototype not containing a 
>> property named values.
>> 
>> So, it seems that we’ll need to remove .values from the Array prototype.
>> 
>> Oliver,
>> 
>> Just to check, have you read the existing threads on the topic and on 
>> possible proposed solutions?  Starting at 
>> https://mail.mozilla.org/pipermail/es-discuss/2013-June/031390.html for 
>> example, and I'm pretty sure it's been discussed since as well...
>> 
>> 
>> Right—this is why we have @@unscopeables.
>> 
>> 
>> Rick
>> 
>> ___
>> 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

Re: Removing Array.prototype.values

[Oliver Hunt]

I thought @@unscopeables were (essentially) Symbols, have i been confused?  Are 
we overloading @@ to mean different things?

—Oliver

On Nov 11, 2013, at 12:01 PM, Rick Waldron  wrote:

> 
> 
> 
> On Mon, Nov 11, 2013 at 2:59 PM, Boris Zbarsky  wrote:
> On 11/11/13 2:47 PM, Oliver Hunt wrote:
> Alas in addition to assuming that the Arguments object does not have the 
> Array prototype, ExtJS also relies on the Array prototype not containing a 
> property named values.
> 
> So, it seems that we’ll need to remove .values from the Array prototype.
> 
> Oliver,
> 
> Just to check, have you read the existing threads on the topic and on 
> possible proposed solutions?  Starting at 
> https://mail.mozilla.org/pipermail/es-discuss/2013-June/031390.html for 
> example, and I'm pretty sure it's been discussed since as well...
> 
> 
> Right—this is why we have @@unscopeables.
> 
> 
> Rick
> 
> ___
> 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: Removing Array.prototype.values

[Oliver Hunt]

Apparently i missed that thread entirely

Something i pondered before just removing .values () (that SM has already done) 
was essentially adding yet another property mode, essentially “ignore in 
|with|”.  It’s technically fairly heavyweight, but it would resolve the general 
problem of libraries using with(), despite the years of being told not to.

—Oliver

On Nov 11, 2013, at 11:59 AM, Boris Zbarsky  wrote:

> On 11/11/13 2:47 PM, Oliver Hunt wrote:
>> Alas in addition to assuming that the Arguments object does not have the 
>> Array prototype, ExtJS also relies on the Array prototype not containing a 
>> property named values.
>> 
>> So, it seems that we’ll need to remove .values from the Array prototype.
> 
> Oliver,
> 
> Just to check, have you read the existing threads on the topic and on 
> possible proposed solutions?  Starting at 
> https://mail.mozilla.org/pipermail/es-discuss/2013-June/031390.html for 
> example, and I'm pretty sure it's been discussed since as well...
> 
> -Boris
> ___
> 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

Removing Array.prototype.values

[Oliver Hunt]

Alas in addition to assuming that the Arguments object does not have the Array 
prototype, ExtJS also relies on the Array prototype not containing a property 
named values.

So, it seems that we’ll need to remove .values from the Array prototype.

—Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: an idea for replacing arguments.length

[Oliver Hunt]

On Nov 10, 2013, at 2:12 PM, Andrea Giammarchi  
wrote:

> I think I've completely missed the `undefined === absent` conversation ... so 
> if I have an object, and `obj.key = void 0` why `key` would be considered 
> absent, exactly? `undefined` is a very well described "value", passing stuff 
> around thinking has a value but getting ignored by signatures and who knows 
> what else is a door to hell in the real world.
> 

void 

simply evaluates expression and sets the return continuation value to undefined.

void 0 is identical to |undefined| unless a containing scope has declared a 
variable named “undefined” locally.  void … does not result in a special value.

—Oliver


> my 2 cents
> 
> 
> On Sun, Nov 10, 2013 at 1:49 PM, Mark S. Miller  wrote:
> On Sun, Nov 10, 2013 at 1:30 PM, K. Gadd  wrote:
> JSIL and embind both need arguments.length for efficient method call dispatch 
> when dealing with overloaded functions. Is it your intent that all such 
> scenarios must now pay the cost of creating an array (to hold the rest 
> arguments) and then destructuring it, for every call? At present it's 
> possible to avoid this overhead in V8 and SpiderMonkey by using 
> arguments.length + arguments[n] or by using arguments.length + patterned 
> argument names.
> 
> Hi Katelyn,
> 
> No one is taking arguments away. Perhaps we would if we could but we can't. 
> So as I said just now to Allen, if you really need to do this, go ahead and 
> use arguments.length.
> 
> But do you really need to do this? Assuming for a moment that we were all 
> agreed that the best practice is to treat absence the same as undefined, why 
> not go with the best practice and be done?
> 
> 
> 
>  
> 
> On Sun, Nov 10, 2013 at 1:24 PM, David Bruant  wrote:
> Le 10/11/2013 22:19, Brendan Eich a écrit :
> 
> On Nov 10, 2013, at 9:12 PM, Andrea Giammarchi  
> wrote:
> 
> Not sure why this is so needed though.
> Allen's posts make the case: webidl and varargs-style functions. Not all 
> legacy.
> WebIDL creates spec, not code. The language syntax doesn't need to evolve for 
> that. Allen showed that rest params+destructuring allows self-hosting without 
> |arguments|
> Varargs functions have rest parameters.
> 
> David
> 
> ___
> 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
> 
> 
> 
> 
> -- 
> Cheers,
> --MarkM
> 
> ___
> 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

Re: an idea for replacing arguments.length

[Oliver Hunt]

The mere fact the this discussion is coming up, is a good argument (to me 
anyway) that default parameter behaviour should have been in terms of argument 
count, not |undefined|.  Again, sentinel values that are regular valid values 
are a bad thing.

I still cannot recall what the usage scenario that required undefined => not 
provided was, but this seems like a very good argument for that decision being 
wrong.

—Oliver

On Nov 10, 2013, at 1:19 PM, Brendan Eich  wrote:

>> On Nov 10, 2013, at 9:12 PM, Andrea Giammarchi  
>> wrote:
>> 
>> Not sure why this is so needed though.
> 
> Allen's posts make the case: webidl and varargs-style functions. Not all 
> legacy.
> 
> /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: an idea for replacing arguments.length

[Oliver Hunt]

Sorry, ignore the line noise I just remembered that we decided to treat 
undefined as missing.

I do recall actually making the argument w.r.t defaults, that treating 
undefined as “not provided” would cause us difficulty if anyone ever wanted to 
distinguish undefined from not provided.

—Oliver

On Nov 10, 2013, at 12:52 PM, Oliver Hunt  wrote:

> I don’t fully understand this — what is the reason for needing to know actual 
> argument count?  The historical reason was that if i have a var arg function 
> with a few required parameters i don’t have any nice way of iterating the 
> optional args.
> 
> Default and rest parameters seem to solve this use case.
> 
> —Oliver
> 
> On Nov 10, 2013, at 10:12 AM, Allen Wirfs-Brock  wrote:
> 
>> One of the the few remaining uses of a function's 'arguments' binding is to 
>> determine the actual number of passed arguments.  This is necessary in some 
>> overloading scenarios where a function has different behavior when an 
>> argument is completely absent then it has when undefined (or any other 
>> default value) is explicitly passed in that parameter position.  That 
>> situation occurs in a number of DOM APIs and even a few ES library functions.
>> 
>> For example(see https://bugs.ecmascript.org/show_bug.cgi?id=1877 ), 
>> Array.prototype.splice returns different results for:
>>[1,2,3].splice()
>> and
>>[1,2,3].splice(undefined)
>> 
>> The natural ES6 declaration for a splice function is:
>> 
>>function splice(start, deleteCount, ...items) {...
>> 
>> but if you write it this way then within the body you have to have a test 
>> like:
>> 
>> if (arguments.length == 0) {...
>> 
>> to implement the correct  web-compatable behavior.
>> 
>> Or, alternatively you could declare the functions as:
>> 
>> function splice(...actualArgs) {
>>  let [start, stop, ...item] = actualArgs;
>>  ...
>>  if (actualArgs.length == 0) {...
>> 
>> So, to implement a Web-compaable version of splice you either have to use 
>> 'arguments' to determine the actual number of passed objects or you need to 
>> declare it with a bogus parameter pattern and use explicit or implicit 
>> destructuring to parse out the positional parameters.
>> 
>> One way around this dilemma would be to provide a syntactic affordance for 
>> determing the actual argument count.  For example, one possibility would be 
>> to allow the last item of any formal parameter list to be an item of the 
>> syntactic form:
>> 
>> ActualArgumentCount : '#' BindingIdentifier
>> 
>> So, the declaration for splice could then be:
>> 
>>function splice(start, deleteCount, ...items, #argCount) {
>>   ...
>>   if (argCount == 0) {...
>> 
>> Thoughts?
>> 
>> Allen
>> 
>> 
>> ___
>> 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

Re: an idea for replacing arguments.length

[Oliver Hunt]

I don’t fully understand this — what is the reason for needing to know actual 
argument count?  The historical reason was that if i have a var arg function 
with a few required parameters i don’t have any nice way of iterating the 
optional args.

Default and rest parameters seem to solve this use case.

—Oliver

On Nov 10, 2013, at 10:12 AM, Allen Wirfs-Brock  wrote:

> One of the the few remaining uses of a function's 'arguments' binding is to 
> determine the actual number of passed arguments.  This is necessary in some 
> overloading scenarios where a function has different behavior when an 
> argument is completely absent then it has when undefined (or any other 
> default value) is explicitly passed in that parameter position.  That 
> situation occurs in a number of DOM APIs and even a few ES library functions.
> 
> For example(see https://bugs.ecmascript.org/show_bug.cgi?id=1877 ), 
> Array.prototype.splice returns different results for:
>[1,2,3].splice()
> and
>[1,2,3].splice(undefined)
> 
> The natural ES6 declaration for a splice function is:
> 
>function splice(start, deleteCount, ...items) {...
> 
> but if you write it this way then within the body you have to have a test 
> like:
> 
> if (arguments.length == 0) {...
> 
> to implement the correct  web-compatable behavior.
> 
> Or, alternatively you could declare the functions as:
> 
> function splice(...actualArgs) {
>  let [start, stop, ...item] = actualArgs;
>  ...
>  if (actualArgs.length == 0) {...
> 
> So, to implement a Web-compaable version of splice you either have to use 
> 'arguments' to determine the actual number of passed objects or you need to 
> declare it with a bogus parameter pattern and use explicit or implicit 
> destructuring to parse out the positional parameters.
> 
> One way around this dilemma would be to provide a syntactic affordance for 
> determing the actual argument count.  For example, one possibility would be 
> to allow the last item of any formal parameter list to be an item of the 
> syntactic form:
> 
> ActualArgumentCount : '#' BindingIdentifier
> 
> So, the declaration for splice could then be:
> 
>function splice(start, deleteCount, ...items, #argCount) {
>   ...
>   if (argCount == 0) {...
> 
> Thoughts?
> 
> Allen
> 
> 
> ___
> 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: Formalize error.stack?

[Oliver Hunt]

I think there’s a comment on that page to the effect of “it has to be a 
string”, i think amazon was one of the sites that interpret the existence of 
.stack as implying it’s a string.

All things being equal i think that i prefer the current Carakan/V8 string 
format, and would be happy to change JSC’s message to that.

As far as eager vs. late creation, I’ve seen - and recall from Java - that 
people try to get a stack trace with (new Error).stack, which i guess is an 
argument for creation with the error object.  On the other hand appending 
.stack to an arbitrary object on throw means anything can have a stack trace 
(this is what JSC does).  Despite the “yay whatever object i want” advantage, 
as time has gone by i’ve found myself feeling that appending at Error 
construction is a better model and would not be opposed to that being the 
standard.

That said the “new Error().stack” or in JSC "try {throw {}}catch(e){e.stack}” 
(woo concise!) construct is sufficiently common that i think we should provide 
a decent stack introspection API, as terrible as that idea is :(

My main concern with that is that it could expose implementation specific 
details (though not necessarily as bad as .caller).

—Oliver 


On Nov 9, 2013, at 5:04 PM, Rick Waldron  wrote:

> Here is the current work 
> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
> 
> 
> On Sat, Nov 9, 2013 at 7:50 PM, Nicholas C. Zakas 
>  wrote:
> Reading through the recent ES draft, I was surprised to see that there is no 
> definition for the "stack" instance property on Error or NativeError. This is 
> supported in all browsers (including IE 10+) and Node.js, and it seems like 
> it's supported in a reasonably consistent way that would lend itself to 
> formal definition.
> 
> Is this a spec oversight or is the exclusion intentional?
> 
> Thanks.
> 
> -- 
> ___
> Nicholas C. Zakas
> http://www.nczonline.net
> 
> ___
> 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

Re: Weak callbacks?

[Oliver Hunt]

On Nov 6, 2013, at 3:14 PM, Rick Waldron  wrote:

> 
> 
> 
> On Wed, Nov 6, 2013 at 2:15 PM, Domenic Denicola 
>  wrote:
> Thanks Mark for the education, especially on the pre- vs. post-morterm 
> finalization distinction. I don't think I was specifically advocating for 
> pre-mortem in my OP, since I didn't really understand the difference :P. 
> Post-mortem finalization sounds quite reasonable. What do people think of 
> introducing it into ECMAScript?
> 
> This may be a naïve question, but how would the handler know which 
> object/weakref had been gc'ed?
> 
You wouldn’t :)

I’m kind of anti-finalisers in JS for all of the reasons people have raised - 
they are extremely hazardous, expose non-deterministic behaviour, etc

Given our general desire to avoid exposing internal GC semantics, and the 
difficulty in defining observable GC behaviour (I suspect this would be a 
non-starter in any case), I can’t see any specification that would allow useful 
finalisers or WeakRefs.

If MarkM has an idea for WeakRefs that don’t leak observable GC behaviour i’d 
love to hear, but in general i’m opposed to both them and finalisers :-/

—Oliver

> Rick
> 
> ___
> 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: Cross-global instanceof

[Oliver Hunt]

On Nov 1, 2013, at 7:23 PM, Andrea Giammarchi  
wrote:

> also, your reviver would receive objects from the realm I am checking with 
> that code ... so your reviver will receive object from the **expected** realm 
> ... just to clarify, for future readers.
> 

I don’t understand what you’re saying here

if your reviver is in realm A, and says

function reviver(foo) {
…
  if (foo instance of Array) alert(“Array!”)
...
}

And realm B says

JSON.parse(…, realm A.reviver)

You will never get to the alert.

As far as use cases, i recall multiple websites using invisible iframes as 
“modules” where multiple realms would use a shared group of functions from a 
single realm

—Oliver

> Still all ears listening to that case I've never, honestly, considered!
> 
> Thanks
> 
> 
> On Thu, Oct 31, 2013 at 11:07 PM, Andrea Giammarchi 
>  wrote:
> Sure, so Allen asked me a real case to show, and I've done it. Now you please 
> show me a real case when you pass a revival function to `JSON.parse` that is 
> from another realm, explaining why, as I've done for mine, thanks.
> 
> Best Regards
> 
> 
> On Thu, Oct 31, 2013 at 7:41 PM, Oliver Hunt  wrote:
> 
> On Nov 1, 2013, at 2:46 PM, Andrea Giammarchi  
> wrote:
> 
> > Allen, in which place on current known universe, when you parse a 
> > JSON.string, your reviver function receives objects from another realm, 
> > exactly?
> Please try to keep the discourse polite.
> 
> That said this is fairly trivial
> 
> 
> function reviver(…) { … }
> 
> 
> 
> JSON.parse(… .reviver …)
> 
> 
> now the realm of the objects created by the JSON object differ from the realm 
> that the reviver function is working in.
> 
> —Oliver
> 
> 
> 
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cross-global instanceof

[Oliver Hunt]

On Nov 1, 2013, at 2:46 PM, Andrea Giammarchi  
wrote:

> Allen, in which place on current known universe, when you parse a 
> JSON.string, your reviver function receives objects from another realm, 
> exactly?
Please try to keep the discourse polite.

That said this is fairly trivial


function reviver(…) { … }



JSON.parse(… .reviver …)


now the realm of the objects created by the JSON object differ from the realm 
that the reviver function is working in.

—Oliver



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Math.sign vs ±0

[Oliver Hunt]

As currently specified Math.sign has 5 different return values and, as far as i 
can tell, does not solve the problem I thought it was trying to address. That 
is the difficulty in distinguishing positive and negative numbers without 
having to manually do the divide -> ±Infinity cruft.

What is the rational for this behaviour?

Current Math.sign is a new, and unexpectedly complex API that doesn’t solve the 
common use case.

—Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal to simplify Generators impact

[Oliver Hunt]

On Oct 26, 2013, at 4:59 PM, Lucio Tato  wrote:

> Rick: I understand. But it is always a trade-off.
> 
> If the reason to introduce a new construct is because there may already be 
> code that defines a function called `yield`, it seems to me as a bad 
> trade-off. (advantages vs disadvantages)
> 
> In your example... 
> function yield() {... <- will raise a parsing error.
> 

You can’t make yield a reserved word — which is what you’re asking for here.  
This isn’t a matter of whether or not you use generators, it’s a matter of 
whether other code in the same environment ever uses a property named yield.  
All of the options necessarily require breaking yield in existing code


> Anyway, there are other ways to solve that.
> You can put the asterisk in "yield" instead of the important "function". It's 
> a lot less confusing.
> 
> function fibonacci() {
> let [prev, curr] = [0, 1];
> for (;;) {
> [prev, curr] = [curr, prev + curr];
> yield*(curr);

This already parses a (yield)*(curr)

Please stop trying to get rid of the *, there isn’t any other viable option, 
and this has been covered ad nauseum on es-discuss

—Oliver___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Iteration of the Arguments object

[Oliver Hunt]

I know we would like people to stop using the Arguments object, but just to be 
sure, is it intentional that the Arguments Object does not have an @@iterator ?

—Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are there any plans to introduce Date/Time literals?

[Oliver Hunt]

On Oct 9, 2013, at 1:35 AM, Claude Pache  wrote:

> 
> Le 8 oct. 2013 à 23:43, Andrew Fedoniouk  a écrit :
> 
>> Quite often Date values are used in data exchanges in form of JS
>> literals or JSON.
>> 
>> It would be beneficial if JS (and JSON as derivative) will have an
>> ability to represent dates literally  . For example:
> 
> Even if there had been a dedicated syntax to write literal dates in JS, it 
> doesn't mean that JSON would have allowed such a representation.
> For instance, the following entities have literal representation in JS, but 
> do not exist in JSON, by the will of its designer: Infinity, NaN, and regular 
> expressions.

Infinity and NaN a identifiers referencing properties on the global object — 
they’re not literals (nor is undefined).

These are all valid (but you shouldn’t do it):

function f(undefined, NaN, Infinity) {
// dooomm
}


function f() {
var undefined = null /* fix that silly null vs. undefined shenanigans */, NaN = 
Math.sqrt(2) /* make sure nan is not rational */, Infinity = 1000 /* this 
should be big enough */
}

—Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Oliver Hunt]

Shipping JSC supports Symbols (although by the old name, Name, alas)

—Oliver

On Sep 30, 2013, at 12:49 PM, David Bruant  wrote:

> Le 30/09/2013 19:30, Rick Waldron a écrit :
>> On Mon, Sep 30, 2013 at 12:54 PM, Kevin Smith  wrote:
>> 
>> 
>> I think all we want here is make HTMLCollection interoperate better
>> with other lists. For new features we moved away from HTMLCollection
>> for the reason you mention.
>> 
>> What do you think an HTMLCollection @@iterate method should do?  Iterate 
>> like an array, or like a map?
>> 
>> In Firefox (regular and Nightly), HTMLCollection objects are iterable (with 
>> a the temporary placeholder "iterator" method):
> drive-by comment to say that "iterator" is going to be changed to 
> "@@iterator" (the string) until symbols are implemented at which point a 
> symbol will be used.
> Progress can be seen at https://bugzilla.mozilla.org/show_bug.cgi?id=907077 
> (which I had filed for a completely different purpose but whatever)
> 
> David
> ___
> 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: Deconstructing assignment and reader/modify/write operands

[Oliver Hunt]

I'll try to rephrase:

As I read the spec this is not a syntax error, and so gets delayed to runtime.  
Given that we're already doing work to determine whether we should be 
destructuring (which results in different runtime semantics), it seems we 
should promote (demote?)to a 
syntax error -- it seems like it would be an easy typo to make so detecting it 
earlier would seem a plus.

FWIW I'm not sure I agree with brendan on this idea being a misfeature, but I 
think we really should try to make it at least an early error.

--Oliver

On Sep 24, 2013, at 11:33 AM, Brendan Eich  wrote:

> Oliver may be asking "why?" The reductiionistic answer is because L += R is 
> evaluated as if by L = L + R but with L evaluated to a Reference once only.
> 
> The deeper question (if I may stand in for Oliver) is why wouldn't we want 
> some nicer new semantic for [a, b] += [c, d] -- a "parallel add-and-assign." 
> We could do that, but it would deviate from the straightforward meaning of 
> the assignment operators composed with destructuring, by quite a bit.
> 
> When composing two things leads to an unexpected result, there's a smell. It 
> could be handy, but it's probably better off done with a distinct special 
> form.
> 
> /be
> 
>> Allen Wirfs-Brock 
>> September 24, 2013 8:42 AM
>> 
>> 
>> 
>> No, see http://people.mozilla.org/~jorendorff/es6-draft.html#sec-12.13.2 
>> 
>> 
>> Destructuring is only  checked for in the  LHS = RHS case.
>> 
>> The LHS AssignmentOperator RHS case is just like ES5 and doesn't do any 
>> destructuring.
>> 
>> Allen
>> ___
>> 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

Deconstructing assignment and reader/modify/write operands

[Oliver Hunt]

I am reading the spec and it looks (to me at least) like we expect [a,b,c] += 
[1,2,3] to be equivalent to a+=1; b+=2; c+=3 — is that correct or have i 
misread something?

—Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Continuing woes in reading the ES6 spec language

[Oliver Hunt]

On Sep 13, 2013, at 7:19 PM, Brendan Eich  wrote:

>> Axel Rauschmayer <mailto:a...@rauschma.de>
>> September 14, 2013 12:36 AM
>> 
>> Thanks! I didn’t look at the spec section, I (incorrectly) assumed I knew 
>> how they worked. Then I don’t see a use case for this, I’d find it confusing.
> 
> What alternative do you want?
> 
> 1. Parameter default value before default-free parameter means call without 
> arity match throws?
> 
> 2. What Oliver may have feared in switching to named parameters: actual 
> argument list shorter than formal list with default on left causes parameter 
> binding to skip defaults? This is not coherent:
> 
> function foo(x, y = a, z = y) {...}
> 
> foo()// x=undefined, y=a, z=a
> foo(1)   // x=1, y=a, z=a
> foo(1, 2)// x=1, y=a, z=2???
Why the ???

This makes sense, and it is what other languages with default values do

> foo(1, 2, 3) // x=1, y=2, z=3
> 
> 3. What ES6 draft says.
> 
> /be
>> 
>> -- 
>> Dr. Axel Rauschmayer
>> a...@rauschma.de <mailto:a...@rauschma.de>
>> 
>> home: rauschma.de <http://rauschma.de>
>> twitter: twitter.com/rauschma <http://twitter.com/rauschma>
>> blog: 2ality.com <http://2ality.com>
>> 
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> Axel Rauschmayer <mailto:a...@rauschma.de>
>> September 13, 2013 11:06 PM
>> 
>> As an aside: This can be useful. For example:
>> 
>> ```js
>> function getRandomInteger(lower = 0, upper) {
>>return Math.floor(Math.random() * (upper - lower)) + lower;
>> }
>> ```
>> 
>> Implementing this function in some other manner is much more complicated.
>> 
>> But I agree that you want to name parameters if there are more than 2.
>> 
>> -- 
>> Dr. Axel Rauschmayer
>> a...@rauschma.de <mailto:a...@rauschma.de>
>> 
>> home: rauschma.de <http://rauschma.de>
>> twitter: twitter.com/rauschma <http://twitter.com/rauschma>
>> blog: 2ality.com <http://2ality.com>
>> 
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> Oliver Hunt <mailto:oli...@apple.com>
>> September 13, 2013 5:39 PM
>> On Sep 13, 2013, at 9:18 AM, Brendan Eich  wrote:
>> 
>>>> Oliver Hunt<mailto:oli...@apple.com>
>>>> September 13, 2013 6:11 PM
>>>> Okay so we were discussing among ourselves, and we thought that a sane 
>>>> "desugaring" for
>>>> 
>>>> function f(x=expr) {
>>>> ...
>>>> }
>>>> 
>>>> would be
>>>> 
>>>> function f(x) {
>>>> if (arguments.length<  1) x=expr;
>>>> ...
>>>> }
>>> ES6 has two things that go against this, already in consensus among those 
>>> at the meetings (we miss you shiny fruit-company people ;-):
>> More of the consensus discussion need to happen on es-discuss, this is the 
>> only standards body i'm involved in that seems to require details be 
>> hammered out in F2F meetings.  It's one of the things I find disappointing 
>> about the ES standard - the avoidance of es-discuss when discussing language 
>> features makes it actively difficult for input from the wider dev community.
>> 
>>> * You can have default parameters before parameters without defaults.
>> The spec explicitly states that any parameter without a default, but after 
>> another parameter that does have a default assignment implicitly has a 
>> default property of undefined
>> 
>>> * You can pass undefined to trigger defaulting -- this is important for 
>>> composition / delegation.
>> No, it's a terrible feature :D i'm unaware of any language that supports 
>> arbitrary ordering of arguments.
>> 
>> The elegant solution i saw someone mention was
>> 
>> function f({option1, option2, option3} = {option1:default option1, ...}) { … 
>> }
>> 
>> That gives you nicely named parameters!  (It was this example that made me 
>> start looking at default parameters in the first place)
>> 
>> 
>>> I think we all agree that new formal parameter syntax gets rid of 
>>> arguments. Yay!
>> 
>> If only we could kill it everywhere!  My proposal was to simply ban 
>> arguments as an identifier entirely
>> 
&

Re: Continuing woes in reading the ES6 spec language

[Oliver Hunt]

On Sep 13, 2013, at 11:09 AM, Andreas Rossberg  wrote:
> 
> OK, I assumed you were talking about TDZ in general, and not just for
> the specific case of parameter lists. For parameter lists, I agree
> that there is no reason to treat them as mutually recursive. However,
> if scoping of bindings is supposed to be sequential, but each default
> expression shall see the previous parameters, then the only clean
> solution is to conceptually have each parameter open a new nested
> scope (like is the case in some other languages).  That solves your
> 'eval' case as well.  I'd be happy with that, but I remember concerns
> about more fine-grained scoping on the committee.

Introducing a new scope for each argument could be extraordinarily expensive, 
also would make some semantics weird:

function f(a=1, b=function(){return a}) {
var a = 2;
return b() // What's this?
}

if we say sequential scoping it becomes inconsistent for b to return 1, but the 
parameter shadowing of var means that it should.

--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Continuing woes in reading the ES6 spec language

[Oliver Hunt]

On Sep 13, 2013, at 9:58 AM, Andreas Rossberg  wrote:

> On 13 September 2013 18:39, Oliver Hunt  wrote:
>> The problem with temporal dead zones is that they lead to weird behaviour in 
>> edge cases, and almost all of them should be syntactically identifiable as 
>> errors up front.  The problem is that you can only _almost_ get syntax 
>> checked behaviour upfront because eval.
> 
> There must be a misunderstanding -- eval is not relevant to the issue
> that TDZ is addressing.  The issue is mutual recursion between
> bindings that can perform arbitrary (higher-order) computations.  In
> that situation, it is generally impossible to ensure the absence of
> errors without a type system.  And even with one, it is tedious to the
> degree that it is arguably impractical.  So, as long as JavaScript
> allows that (and I don't see how we can change that), TDZ is the
> best/only we can do.
> 
> What "weird edge case" do you have in mind? I cannot imagine anything
> that isn't even weirder without TDZ.
> 

It isn't eval doing anything magic here - you can syntactically identify and 
use of not yet live properties, except eval(), e.g.

function f1(a=b, b=...) ... // can syntax error easily
function f2(a=function () {return b}, b=...) ... // again you can syntax error, 
or you can be clever and say we're not calling it and not error
function f3(a=function () {return b}(), b=...) ... // syntax error as we can 
prove you're going to use b
function f4(a=eval("b"), b=...) ... // eval makes things opaque

Personally I don't believe TDZ's are a good solution - they essentially add 
another null/undefined value internally.  They make things more complex for 
developers.

I certainly don't get what the TDZ win is for default parameters, and example 
would help me reason about it.

> /Andreas

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Continuing woes in reading the ES6 spec language

[Oliver Hunt]

On Sep 13, 2013, at 9:18 AM, Brendan Eich  wrote:

>> Oliver Hunt <mailto:oli...@apple.com>
>> September 13, 2013 6:11 PM
>> Okay so we were discussing among ourselves, and we thought that a sane 
>> "desugaring" for
>> 
>> function f(x=expr) {
>> ...
>> }
>> 
>> would be
>> 
>> function f(x) {
>> if (arguments.length < 1) x=expr;
>> ...
>> }
> 
> ES6 has two things that go against this, already in consensus among those at 
> the meetings (we miss you shiny fruit-company people ;-):
More of the consensus discussion need to happen on es-discuss, this is the only 
standards body i'm involved in that seems to require details be hammered out in 
F2F meetings.  It's one of the things I find disappointing about the ES 
standard - the avoidance of es-discuss when discussing language features makes 
it actively difficult for input from the wider dev community.

> 
> * You can have default parameters before parameters without defaults.
The spec explicitly states that any parameter without a default, but after 
another parameter that does have a default assignment implicitly has a default 
property of undefined

> 
> * You can pass undefined to trigger defaulting -- this is important for 
> composition / delegation.
No, it's a terrible feature :D i'm unaware of any language that supports 
arbitrary ordering of arguments.

The elegant solution i saw someone mention was

function f({option1, option2, option3} = {option1:default option1, ...}) { … }

That gives you nicely named parameters!  (It was this example that made me 
start looking at default parameters in the first place)


> 
> I think we all agree that new formal parameter syntax gets rid of arguments. 
> Yay!

If only we could kill it everywhere!  My proposal was to simply ban arguments 
as an identifier entirely

> 
> The real issue that Andreas's proposal addressed was the insanity of body 
> declarations hoisting to be in view of default. But it sounds like we do not 
> have consensus on whether or not that's crazy.
>> 
>> This would produce a consistent and easy to follow semantic for default 
>> evaluation, it doesn't introduce any new types of scope, nor does it require 
>> any new concepts (temporal dead zones, etc) to be learned by a developer who 
>> just wants default parameter values.
> 
> The hoisting issue still hits your non-consensus actual parameter count 
> (arguments.length) thing, though. When reading the function in source order, 
> one sees a default expression. Mentally moving the defaulting to the body 
> means that hoisted body decls trump outer bindings for names in the 
> expression, indeed. But mentally moving is the objectionable part -- 
> cognitive load, and non-source-order evaluation (more hoisting).
> 
> Hoisting need not perpetuate itself this way. We can do better, or at least 
> Andreas proposes that we do. I'm sympathetic.
> 
> Temporal dead zones are indeed weirder but perhaps pay for themselves by 
> catching errors. But is it an error to use an outer name binding in the 
> default expression, given its position in the formal parameter list? I think 
> not.

The problem with temporal dead zones is that they lead to weird behaviour in 
edge cases, and almost all of them should be syntactically identifiable as 
errors up front.  The problem is that you can only _almost_ get syntax checked 
behaviour upfront because eval.

>> 
>> We also felt that if you use default or rest parameters we should consider 
>> that as a opt out from the magic arguments object, and just poison the 
>> arguments identifier entirely (no read, write, or declare)
> 
> SpiderMonkey's prototype implementation does this, and I asserted above that 
> ES6 specs it. Not so?

The ES6 spec (as far as i can read it) only bans declaration of parameters/vars 
named "arguments" it doesn't ban reading them.

> 
> /be
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Continuing woes in reading the ES6 spec language

[Oliver Hunt]

Okay so we were discussing among ourselves, and we thought that a sane 
"desugaring" for

function f(x=expr) {
...
}

would be

function f(x) {
  if (arguments.length < 1) x=expr;
  ...
}

This would produce a consistent and easy to follow semantic for default 
evaluation, it doesn't introduce any new types of scope, nor does it require 
any new concepts (temporal dead zones, etc) to be learned by a developer who 
just wants default parameter values.

We also felt that if you use default or rest parameters we should consider that 
as a opt out from the magic arguments object, and just poison the arguments 
identifier entirely (no read, write, or declare)

--Oliver



On Sep 13, 2013, at 4:43 AM, Andreas Rossberg  wrote:

> On 13 September 2013 11:27, Till Schneidereit  
> wrote:
>> On Thu, Sep 12, 2013 at 11:14 PM, Allen Wirfs-Brock 
>> wrote:
>>> 
>>> On Sep 12, 2013, at 1:50 PM, Brendan Eich wrote:
>>> 
 I thought we agreed with Andreas Rossberg's proposal to isolate default
 expressions from hoisted body declarations, as if (kind of) desugaring
>>> 
>>> Damned if I know...there is a big note in the draft that says: "This
>>> version reflects the consensus as of the Sept. 2012 TC39 meeting.  However,
>>> it now appears that the binding semantics of formal parameters  is likely to
>>> change again. "  So, this may not be the latest consensus and I'm not
>>> actually sure there is a current consensus.
>>> 
>>> I know some of us weren't very happy with that de-sugaring.
>>> 
>>> I'm pretty sure some decisions were left hanging.  I'll need to review
>>> notes, etc.
>> 
>> It looks like the last time tc39 discussed this was 2012-11-29[1]
>> 
>> The resolution back then was that Andreas should draft a proposal for the
>> next meeting. I can't find any mention of that being discussed in later
>> meetings, though, so this seems to have been left undecided indeed.
>> 
>> [1]:
>> https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#scoping-for-default-arguments-revisited
>> [2]:
>> https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#conclusionresolution-1
> 
> Ouch. I'm sorry, I obviously dropped the ball on this. I'll try to
> draft something for next week.
> 
> /Andreas
> ___
> 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: Continuing woes in reading the ES6 spec language

[Oliver Hunt]

On Sep 12, 2013, at 12:40 PM, Jason Orendorff  wrote:

> Just as a worked example, answering Oliver's question about default
> expressions took me the better part of an hour.
> 
> The default-expression h() in code like
> 
>function f(x=h(), y) {
>function h() { ... }
>}
> 
> is evaluated in the scope of f, as I expected, so {x, h, y} are all in
> scope there.
> 
> But I was surprised by the timing; h() is evaluated
> (a) before y is populated with the actual argument value;
> (b) before the arguments object is fully initialized.
> 
> That last surprise seems really unfortunate, since the expression can
> access the arguments object, observing it before and after
> CompleteMapped/StrictArgumentsObject, or even cause those to fail. Can
> we change that?
>From talking to SpiderMonkey folk it sounds like SM nukes the |arguments| 
>identifier entirely if you use any of the new parameter logic (deconstruction, 
>defaults, or rest params).  I would be happy with that.

The spec (from my understanding) says that we can't declare a parameter named 
arguments but does limit reads of it.  Also that doesn't limit declarations of 
a local named arguments 

--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Continuing woes in reading the ES6 spec language

[Oliver Hunt]

On Sep 12, 2013, at 7:51 AM, Andreas Rossberg  wrote:

> On 12 September 2013 01:41, Allen Wirfs-Brock  wrote:
>> For now, I'm going to try giving each semantic routine in a subsection, a 
>> section number.  Note this may include multiple algorithms corresponding to 
>> various productions.  I'll also add a "see also" under each such heading 
>> that references other subsections that implement the same semantic action 
>> for other productions.  That should make it easier to navigate to all 
>> implementation of, for example, "BindingInitialisation".
>> 
>> What we have here is a highly polymorphic nonlinear program and as old 
>> Smalltalker knows, the best way to find your way around is at any reference 
>> to a name to be able to popup a navigable list of both implementaors and 
>> callers of that name.  Maybe that's something we could get working in the 
>> HTML version.  We're already halfway there with some of the definition links.
> 
> Well, yes, but just to be clear, the readability problems are not due
> to polymorphism or non-linearity as such but mainly due to OO-style
> decomposition. That is simply not a good match for a language spec (to
> put it mildly). Tool support may be a viable work-around for dealing
> with code, but not for something whose primary communication form is
> in (physical or virtual) print.

I absolutely agree with this - the primary user of the spec document is 
implementers and ES developers, not tools.  For that reason the spec should be 
tailored to human readers, with machine readability seen as a nice optional 
extra.

> 
> A spec is a system which (a) wants to be transparent (as opposed to
> encapsulated), and (b) is pretty much closed-world (extension points
> notwithstanding). Consequently, none of the advantages of OO apply,
> and it becomes primarily a barrier.
> 
> (I'm not proposing any change to that at this stage, obviously. But it
> is a growing technical debt that we might consider clearing at some
> point.)

I disagree here, a spec that is hard to read, is a spec that is hard to 
implement correctly.  It doesn't matter if it is technically unambiguous if it 
is hard enough to read that an implementer can't determine what the unambiguous 
behavior is.

I've spent a lot of time now trying to read this spec, and have still not been 
able to determine the semantics of a number of the new language features.  I 
guess it's possible i'm just being thick, but I'd like to imagine that after so 
many years I know how to read and implement a spec.

> /Andreas

--Oliver

> ___
> 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

Continuing woes in reading the ES6 spec language

[Oliver Hunt]

Okay, I'm having a really hard time navigating and following the current spec 
layout.  The many different places that behavior is specified for the same 
productions, and the absence of direct links between makes extraordinarily hard 
to read and understand.

In my current reading I was attempting to determine in what scope default 
initializers are evaluated, but from reading the spec (starting at #14.1) I 
could not find initialization of any environment record, and while there was 
reference to various places in which we determine the expected argument count, 
or whether there are initializers, i could not find anything that handle 
default initializers.  I'm sure it's there but it I have spent many hours 
following random names from place to place in the spec (again, this is hard as 
the same productions are described repeatedly for the many different semantic 
modes that they're in), and I still do not know what the expected results of 
evaluation are.

The current spec layout seems to be a substantial regression in terms of 
usability vs. the old spec.  Some of this would be helped if we were using html 
and links, but a lot of it seems controlled by the decision to remove the 
step-by-step evaluation ordering of the ES5 spec.

--Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Non-extensibility of Typed Arrays

[Oliver Hunt]

On Sep 4, 2013, at 4:15 PM, Filip Pizlo  wrote:

> 
> On Sep 4, 2013, at 3:09 PM, Brendan Eich  wrote:
> 

>> But with ES5 Object.preventExtensions, etc., the horse is out of the barn.
> 
> It's there and we have to support it, and the fact that you can do 
> preventExtensions() to an object is a good thing.  That doesn't mean it 
> should become the cornerstone for every new feature.  If a user wants to 
> preventExtensions() on their object, then that's totally cool - and I'm not 
> arguing that it isn't.
> 
> The argument I'm making is a different one: should an object be 
> non-expandable by default?

Actually, here's a very good example:  Why do Maps and Sets allow expandos?

* They are logically buckets so an expando properties seem unnecessary
* We have seen in the past that people get really confused about property 
access -- see the enumerable "associative array" articles that do "new Array()" 
to get there magical associative array.  For (probably) common cases of string 
and numeric properties:
  - someMap["foo"]="bar" and someMap["foo"]; vs.
  - someMap.set("foo", "bar") and someMap.get("foo")

are sufficiently close to "the same" that developers _will_ do this, and think 
that they're using a Map.

So should Map be inextensible by default? The argument against supporting 
expandos on a  typed array seems even stronger for these collection types.

--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: 'function *' is not mandatory

[Oliver Hunt]

On Aug 31, 2013, at 12:15 PM, Yuichi Nishiwaki  
wrote:

> Hi all, I just found a post that the current generator syntax
> (function *) seems have decided in:
> 
> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
> 
> According to the post, the biggest reason the star syntax is adopted
> for now is that you cannot write empty generators with star-less
> functions in a consistent simple way. But the situation has changed,
> and in the current spec (rev 17) yield* is now capable of taking any
> kind of iterator, so you can make empty generators just like
> 
> ```js
> function * () {
>yield * [];
> }
> ```
> 
> This looks enough good and simple at least to me. And I wonder if even
> now generators still need to be declared with 'star's. What are the
> advantages of 'star'ed generators rather than 'star'-lesses? If not
> exist, shouldn't it be removed (for the simplicity)?
> 

The reason for the * is substantially (IIRC) to make it possible for an engine
to help prevent developers from unintentionally creating a generator function,
and to make it possible for someone attempting to use a function to identify 
immediately
whether it is a generator or a regular function.

--Oliver

> Thank you.
> 
> --
> Yuichi Nishiwaki
> ___
> 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: Non-extensibility of Typed Arrays

[Oliver Hunt]

On Aug 30, 2013, at 10:13 AM, David Herman  wrote:

> On Aug 30, 2013, at 9:39 AM, Allen Wirfs-Brock  wrote:
> 
>> I think the right-way to think about structs is as an record structure with 
>> no properties fixed behavior provided by a "wrapper".  Very similar to the 
>> ES primitives except that structs can be mutable.  The way to associate 
>> properties with structs is to encapsulate them in an object, preferably via 
>> a class definition. If we go that route we can reach the point where ES 
>> classes have fixed-shape internal state defined as-if by a struct.
> 
> I might give a slightly different angle on this, and describe structs as 
> objects with a fixed template for their own properties. They are still 
> objects, they still inherit from prototypes. But they have a predefined set 
> of own properties.
> 
>> Typed Arrays are a different beast that already exist in the real world.  I 
>> don't see any need for consistency between Typed Arrays and struct types. 
>> Consistency between Typed Arrays and Array is more important.
> 
> Mostly agreed, except I'd just refine that to say there's no need for 
> consistency *in this dimension*. It would be a shame if typed arrays weren't 
> generalized by the typed objects API in general, and I worked hard to make 
> the pieces fit together. That nuance aside, the fact that, in practice, 
> arrays are patched with additional properties (in fact, IIRC the ES6 template 
> strings API adds properties to arrays) suggests that non-extensibility would 
> be a real incompatibility between arrays and typed arrays. So I'm cool with 
> making typed arrays -- but not structs -- extensible.

I think of TypedArrays as being Arrays of structs with a fixed type/shape - the 
Array itself is a regular object with regular property characteristics, whereas 
the individual elements are all value types .

For example, say i have a struct type S, and make a regular Array filled with 
S.  Aside from the poor performance, this is now essentially what a typed array 
of structs is.  What is the reason for making the fast version of an array of 
structs lose the features of a regular array filled with structs?

--Oliver

> 
> Dave
> 
> ___
> 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: Letting RegExp method return something iterable?

[Oliver Hunt]

On Aug 29, 2013, at 1:13 AM, Brendan Eich  wrote:

> Axel Rauschmayer wrote:
>> * /g flag must be set
>> * lastIndex must be 0
>> * can’t inline the regex, because it is needed as a pseudo-iterator (more of 
>> an anti-pattern, anyway, but still)
>> * side effects via lastIndex may be a problem
> 
> Anything we do of the execAll/execIter kind had better be immune to the awful 
> Perl4-infused "mutable lastIndex state but only if global" kind. 
> Compositionality required.
> 
> The design decision to face is what to do when a global regexp is used. 
> Throw, or ignore its lastIndex?

I would favor ignoring lastIndex rather than throwing, but to be sure can you 
clarify what you mean by global regexp?

If we're talking /.../g, then my feeling is that the /g should be ignored -- if 
you're wanting a regexp iterator for a string (or whatever) I would think that 
the API would imply that all regexps were intended to be "global".

If we're talking about multiple concurrent iterators with the same 
regexp/string then it should definitely be ignored :D

Erm.

I'm not sure if that's coherent, but the TLDR is that I favor ignoring all the 
old side state warts (i would not have iterators update the magic $ properties, 
etc)

--Oliver

> 
> /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: Non-extensibility of Typed Arrays

[Oliver Hunt]

On Aug 27, 2013, at 3:49 PM, David Herman  wrote:

> On Aug 27, 2013, at 9:47 AM, Filip Pizlo  wrote:
> 
>> I do. Placing named properties on arrays makes sense. Consider a matrix 
>> implemented as a Float32Array, with named properties telling you the numRows 
>> and numCols. Just one example. 
> 
> There are of course other ways to achieve this that don't involve patching 
> the array object, such as building a data abstraction for matrices that has-a 
> Float32Array, or creating a new array type with additional methods:
> 
>var Matrix = new ArrayType(float32);
>Matrix.prototype.numRows = function() { ... }
>// or
>Object.defineProperty(Matrix.prototype, { get: function() { ... }, ... });

So what is the answer for jQuery like libraries that want to be able to add 
metadata?

It's possible (if you want) to preventExtensions() on any type, but you can't 
undo it.

> 
>>> TA instances having no indexed expandos but allowing named ones is weird. 
>>> Better to be consistent to users
>> 
>> Consistency would imply doing what other indexed types do. 
> 
> Consistency arguments won't get you very far. The indexed properties of typed 
> arrays by design act very differently from other indexed types. That's their 
> whole reason for existence.
> 
> And the other consistency dimension is between array types and struct types. 
> Is anyone arguing that structs should also have expandos?

No, but i would expect expandos to be possible on an Array of them.  The same 
argument being made in favor of preventExtensions() on TAs applies to all new 
types in ES6 -- why should i be able to add expandos to a Map or any other 
type?  (Map is particularly severe given the overloaded nature of [] in other 
languages and often "correctish" enough behavior of toString() in ES, e.g. 
m=new Map; m[someInt]=foo; … m[someInt])

--Oliver

> 
> Dave
> 
> ___
> 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: Non-extensibility of Typed Arrays

[Oliver Hunt]

Existing types with magic index properties (other than Array) just drop numeric 
expandos on the floor so it's logically a no-op.  Unless there was a numeric 
accessor on the prototype (which non-extensibility does not save you from).

My complaint is that this appears to be removing functionality that has been 
present in the majority of shipping TA implementations, assuming from LH's 
comment that Chakra supports expandos.

--Oliver

On Aug 27, 2013, at 9:26 AM, Domenic Denicola  
wrote:

> I am not aware of all the nuances of the discussion, but as a developer I 
> would find the behavior for numeric expandos confusing. For a typed array of 
> length 1024, setting `ta[1023]` would do something completely different from 
> setting `ta[1024]`. Unlike normal arrays, setting `ta[1024]` would not change 
> `ta.length`, and presumably `ta[1024]` would not be exposed by the various 
> iteration facilities.
> 
> I would much rather received a loud error (in strict mode), which will either 
> alert me to my code being weird, or possibly to my code committing an 
> off-by-one error.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Non-extensibility of Typed Arrays

[Oliver Hunt]

The curent argument for non-extensibility seems to be mozilla doesn't support 
them.  It sounds like all other engines do.

There are plenty of reasons developers may want expandos - they're generally 
useful for holding different kinds of metadata.  By requiring a separate object 
to hold that information we're merely making a developer's life harder.  This 
is also inconsistent with all other magically-indexable types in ES and the DOM.

I'm also not sure what the performance gains of inextensibility are, if DH 
could expand it would be greatly appreciated.

--Oliver
 

On Aug 27, 2013, at 9:04 AM, Allen Wirfs-Brock  wrote:

> see meeting notes 
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-24.md#54-are-typedarray-insances-born-non-extensible
>  
> 
> On Aug 26, 2013, at 5:34 PM, Oliver Hunt wrote:
> 
>> So I noticed in the last revision to the TA spec that a decision was made to 
>> prevent extensibility of them.  Can someone say why that decision was made? 
>> It makes TAs somewhat unique vs. all other builtin types and doesn't match 
>> the behavior of Blink or WebKit implementations.
>> 
>> While I am usually in favour of conservative behaviour I'd like more 
>> information on the reasoning behind this choice.
>> 
>> --Oliver
>> ___
>> 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

Non-extensibility of Typed Arrays

[Oliver Hunt]

So I noticed in the last revision to the TA spec that a decision was made to 
prevent extensibility of them.  Can someone say why that decision was made? It 
makes TAs somewhat unique vs. all other builtin types and doesn't match the 
behavior of Blink or WebKit implementations.

While I am usually in favour of conservative behaviour I'd like more 
information on the reasoning behind this choice.

--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: More concise arrow functions

[Oliver Hunt]

On Jul 26, 2013, at 8:50 AM, Domenic Denicola  
wrote:

> Why do arrow functions require a parameter list and a body? That is, none of 
> the following are allowed:
> 
> - `=> foo`

I guess this could be lexically unambiguous, but i'm unconvinced that the "win" 
of losing two characters in the strictly less common no parameters is worth the 
syntactic confusion

> - `bar =>`
> - `=>`

I think an optional tail would be a huge coding hazard - a typo could result in 
bizarre behaviour, take:

blah(=>,5)

vs

blah(=>5)


> 
> Instead you need the more-verbose
> 
> - `() => foo`

Honestly I'm not sold on the {} free production, but i understand the arguments 
for it.  Randomly (and because i'm too lazy to check) how would
a => b => c

produce?  I mean aside from making the maintainers cry.


--Oliver

> - `bar => {}`
> - `() => {}`
> 
> Any chance of relaxing this a bit?
> ___
> 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: Still waiting for Integer Division

[Oliver Hunt]

On Jul 25, 2013, at 12:11 PM, Waldemar Horwat  wrote:

> 
> 
> On Thu, Jul 25, 2013 at 12:00 PM, Brendan Eich  wrote:
> Michael Haufe wrote:
> In 2008 I first proposed the addition of an integer division operator to the 
> language. At the time Brendan noted his regret for this oversight and desire 
> for the operator as well. I am not seeing this operator available in the 
> current draft. Can/will this be rectified?
> 
> a div b = (a - a % b) / b
> 
> This turns out to be equivalent to
> 
>  (a/b)|0
> 
> 
> which is how asm.js optimizes to avoid the FPU already.
> 
> It's not equivalent for values greater than 2^31. The | version wraps around; 
> div would give the correct answer.

I presume brendan meant

((a|0/b|0)|0)

Which seems to be the asm.js way -- although that said, there shouldn't be any 
requirement on a compile flag to tell us what we can simply turn this into an 
idiv...

--Oliver

> 
> Waldemar
>  
> ___
> 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: Unlimited Integers (was: more numeric constants please (especially EPSILON))

[Oliver Hunt]

On Jul 15, 2013, at 8:15 AM, Mark S. Miller  wrote:
> 
> No wrapping object type -- those are legacy, to be avoided. See 
> http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing 
> is value not reference semantics.
> 
> On that page: "It’s forwards-compatible with future mechanisms for 
> user-defined value objects." How can we be confident of this? I would like to 
> be.

That's a concern I have as well -- i'm not 100% sold on user-defined value 
objects, but i think i'd prefer that we get those done before bolting on 
[u]int64 and hoping that they're forwards compatible.  I don't want to deal 
with any "we can't do x due to uint64" style problems.

--Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JS Ctypes

[Oliver Hunt]

Python isn't use to run arbitrary untrusted code, from untrusted websites.

The reality is that we thinking about features you want in ES, it's not enough 
for another language to have the feature, you have to ask yourself whether the 
other language is primarily used for untrusted code.

--Oliver

On Jul 12, 2013, at 11:17 AM, Andrea Giammarchi  
wrote:

> python has ctypes and is widely used, having something similar in JS would 
> have been awesome too, didn't know it was unsafe.
> 
> Is that because of the proposal or because JS is not suitable for user 
> managed structs?
> 
> Thanks
> 
> 
> On Fri, Jul 12, 2013 at 11:01 AM, Brendan Eich  wrote:
> JSCTypes is unsafe, it won't be standardized and we restrict access to 
> Firefox add-ons and "chrome" (privileged UX implementation) code.
> 
> Binary data and value objects cover the "fast typed structs/primitives".
> 
> Unsafe FFI is a different issue and should not be mixed up with structs and 
> scalar/SIMD-vector types. It's also not "awesome" because unsafe.
> 
> /be
> 
> Andrea Giammarchi wrote:
> I wonder if there is any interest/plan/scheduled TC39 slot about JS Ctypes, 
> mentioned by [Brendan Eich in his famous TXJS 
> talk](https://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/) but never 
> again discussed in this ml.
> 
> Seeing `asm.js` passing through all usual procedures before `JS Ctypes` I 
> wonder if the latter one is still "a thing" or it will be abandoned (or it 
> has already been abandoned)
> 
> Not only other JS engines do not expose these nice and potentially ultra fast 
> typed structs/primitives, when I've benchmarked them a while ago somebody 
> mentioned these are not even JITed in any *Monkey engine.
> 
> Thanks for any news about this once awesome idea.
> 
> Best Regards
> ___
> 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

Re: Why is .bind so slow?

[Oliver Hunt]

Just to clarify, JSRegress is not a "benchmark" in the sunspider/kraken/etc 
sense, as the tests tend far more towards microbenchmarks than full "real" 
programme tests.  As the name suggests its main purpose is to help us make sure 
we're not regressing core language primitives.

--Oliver

On Jul 12, 2013, at 10:49 AM, Filip Pizlo  wrote:

> 
> On Jul 12, 2013, at 10:09 AM, "Mark S. Miller"  wrote:
> 
>> If you can manage it, most effective would be to get .bind (or any other 
>> operation you want to be faster) into some widely quoted benchmark suite.
> 
> In WebKit at least, we have a thing called JSRegress which is meant to be a 
> dumping ground for benchmarks for interesting corners of the language. 
> Microbenchmarks are welcome; the goal is to just expand coverage of things 
> that we measure timings of. It's not widely quoted, and it doesn't get the 
> same priority as "macrobenchmark" suites, but we do care about it and we do 
> optimize for it. For example, all of our optimization a for typeof, switch, 
> and 'in' arose from JSRegress tests, since none of those things were hot 
> enough in any of the "major" benchmarks. 
> 
> We don't have coverage for bind, and it would be great to fix that. 
> 
> If you have a standalone program that uses bind, you can either post a patch 
> on bugs.webkit.org that adds it to JSRegress (I.e. 
> LayoutTests/fast/js/regress/script-tests), or if you're lazy, you can just 
> email the program to me and I can do the footwork. The less micro-benchmarky 
> the better, but we'll take what we can get. If you have multiple such 
> benchmarks for bind then that's even better still. 
> 
> TL;DR getting a benchmark to have visibility among implementors is as easy as 
> telling them about it. 
> 
> -Filip
> 
>> 
>> 
>> On Fri, Jul 12, 2013 at 9:46 AM, Allen Wirfs-Brock  
>> wrote:
>> you might consider ticketing performance bugs against the various 
>> implementations.
>> 
>> Allen
>> 
>> 
>> On Jul 10, 2013, at 9:16 AM, Claus Reinke wrote:
>> 
>> > The TypeScript project tries to emulate arrow functions through the
>> > "_this = this" pattern and keeps running into corner cases where a
>> > semi-naïve renaming is not sufficient.
>> >
>> > I have been trying to suggest using .bind to emulate arrow functions
>> > instead, but the counter-arguments are (a) .bind might not be available
>> > (supporting pre-ES5 targets) and (b) .bind is slow.
>> >
>> > The polyfill isn't the problem, but I'm a bit shocked every time
>> > someone reminds me of the performance hit for using .bind. Given
>> > that a bound function has strictly more info than an unbound one,
>> > I wouldn't expect that (I expected a bound function to be roughly
>> > the same as an unbound function that does not use "this"). Unless
>> > there is no special casing for the just-add-this case, and .bind is
>> > always treated as a non-standard (meta-level) call.
>> >
>> > While playing with test-code, I also found that v8 does a lot better
>> > than other engines when using an .apply-based .bind emulation.
>> >
>> > Can anyone explain what is going on with .bind, .apply and the
>> > performance hits?
>> >
>> > The TypeScript issue is https://typescript.codeplex.com/workitem/1322 .
>> > My test code (*) is attached there as "bind-for-arrows.html".
>> >
>> > Claus
>> > http://clausreinke.github.com/
>> >
>> > (*) I also tried to make a jsperf test case, but the way jsperf
>> >   runs the loop seems to prevent the optimization that makes
>> >   v8 look good for the .apply-based bind.
>> >
>> > ___
>> > 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
>> 
>> 
>> 
>> -- 
>> Cheers,
>> --MarkM
>> ___
>> 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

Re: Questions on clz and toInteger

[Oliver Hunt]

On Jul 12, 2013, at 10:19 AM, Mark S. Miller  wrote:

> No. Even if toInteger meant "no fractional component", I would still expect 
> it only to return true if there is some specific mathematical integer that 
> the JS number can be said to exactly represent. For the same reason, I think 
> isInteger(-0) should be true and isInteger(NaN) should be false.

Oh i agree with that, i was making an observation that the behaviour (i think) 
will confuse people just on the basis of people equating Int32 with Integer

--Oliver

> 
> 
> On Fri, Jul 12, 2013 at 10:16 AM, Oliver Hunt  wrote:
> 
> On Jul 12, 2013, at 8:58 AM, Luke Hoban  wrote:
> 
> >> From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
> >>
> >> On Jul 11, 2013, at 9:01 PM, Luke Hoban wrote:
> >>
> >>> Two questions on new Number APIs:
> >>>
> >>> 1) Is it intentional that clz is on Number.prototype instead of Number?  
> >>> Why?
> >>
> >> I think there is a stronger case to me made for Math.clz(number).  
> >> Number.prototype and Math both seem like plausible homes for clz.  In the 
> >> end, I placed it on Number prototype because it is an operation that is 
> >> specific to a particular numeric encoding rather than an implementation of 
> >> a general mathematical function.
> >>
> >
> > Yeah, I think Math would have been less surprising.  I don't feel strongly, 
> > but Number.prototype wasn't what I had expected.
> 
> I agree with luke, Math.clz seems like a better place than the prototype, 
> otoh there's a nice conciseness to foo.clz() …
> 
> 
> >
> >>>
> >>> 2) Is it intentional that Number.toInteger(Infinity) returns true?
> >> Huh? How's that?
> >>
> >> Number.toInteger is specified as the single step:
> >>
> >>   1 Return ToInteger(number)
> >>
> >> and step 4 of the abstract operation ToInteger(number):
> >>
> >> 4 If number is +0, -0, +∞, or -∞, return number.
> >>
> >
> > Sorry, I meant 'isInteger'.  Per your quoted section, toInteger(Infinity) 
> > is Infinity, so isInteger(Infinity) is true.
> 
> I agree with MarkM that it seems bizarre that non-finite numbers may return 
> true, but i think this is rooted in .isInteger() sounding like it means a 
> 32bit integer (such that bitops won't modify the value) when it is actually a 
> "no fractional component" test.
> 
> --Oliver
> 
> > ___
> > 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
> 
> 
> 
> -- 
> Cheers,
> --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Questions on clz and toInteger

[Oliver Hunt]

On Jul 12, 2013, at 8:58 AM, Luke Hoban  wrote:

>> From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] 
>> 
>> On Jul 11, 2013, at 9:01 PM, Luke Hoban wrote:
>> 
>>> Two questions on new Number APIs:
>>> 
>>> 1) Is it intentional that clz is on Number.prototype instead of Number?  
>>> Why?
>> 
>> I think there is a stronger case to me made for Math.clz(number).  
>> Number.prototype and Math both seem like plausible homes for clz.  In the 
>> end, I placed it on Number prototype because it is an operation that is 
>> specific to a particular numeric encoding rather than an implementation of a 
>> general mathematical function. 
>> 
> 
> Yeah, I think Math would have been less surprising.  I don't feel strongly, 
> but Number.prototype wasn't what I had expected.

I agree with luke, Math.clz seems like a better place than the prototype, otoh 
there's a nice conciseness to foo.clz() …


> 
>>> 
>>> 2) Is it intentional that Number.toInteger(Infinity) returns true?
>> Huh? How's that?
>> 
>> Number.toInteger is specified as the single step:
>> 
>>   1 Return ToInteger(number)
>> 
>> and step 4 of the abstract operation ToInteger(number):
>> 
>> 4 If number is +0, -0, +∞, or -∞, return number.
>> 
> 
> Sorry, I meant 'isInteger'.  Per your quoted section, toInteger(Infinity) is 
> Infinity, so isInteger(Infinity) is true.

I agree with MarkM that it seems bizarre that non-finite numbers may return 
true, but i think this is rooted in .isInteger() sounding like it means a 32bit 
integer (such that bitops won't modify the value) when it is actually a "no 
fractional component" test.

--Oliver

> ___
> 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: Banning assignment to a function call

[Oliver Hunt]

I would be pro-killing this particular misfeature.  I know we have tests that 
verify that we accept the syntax, but i'm not sure if there's still *real* 
content the depends on it.

Does strict mode disallow it? IIRC strict mode has a blanket ban on 
non-reference lhs in assignment expressions but I don't have the spec handy.

--Oliver

On Jun 19, 2013, at 7:40 AM, Jason Orendorff  wrote:

> The program
> 
> if (0) Math.sin(0) = 1;
> alert("OK");
> 
> is permitted in all the major browsers. This was explicitly optional in 
> ES1-5, but dropped from ES6:
> 
> https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-11/nov-29.md#eliminate-functions-returning-reference-values-from-the-specification
> 
> And good riddance, if we really think implementations can drop support for 
> this cursed-legacy syntax. I'm willing to experiment with making this an 
> early ReferenceError in Firefox. But if anyone has tried and run into Web 
> compatibility issues, please speak up and save me some wasted effort!
> 
> Thanks,
> -j
> ___
> 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: Precedence of yield operator

[Oliver Hunt]

Hmmm, my initial thought was against this (and for this specific case i'm not 
sure i've been sold on it), but I do kind of like the concept.  Alas this is me 
we're talking about so I do have a few issues with it

* I'm a little concerned that this could make for easily misread code, even for 
other characters (! obviously disappears into line noise in english)
* Adding a new syntax for a single (though admittedly major) use case is 
worrying to me, i don't really want to see ES disappear into line noise 
territory where code changes meaning based on a single character
* It also seems a little inflexible

After reading Mark's email I did ponder what it would mean if we allowed 
"operators" to be described, e.g. 

function .???(...) {
   throw "Because he hates us all"
}

"This is terrible why is oliver suggesting this".???


I'm really not enamored with this, but I thought I'd throw it out here

--Oliver


On Jun 15, 2013, at 7:46 PM, "Mark S. Miller"  wrote:

> I hadn't thought of the "urgent" implication -- interesting. I agree that 
> this has the contrary connotations which is unfortunate.
> 
> E and AmbientTalk use "<-" which I always thought read well. In E, the "then" 
> concept is named "when" and is also supported as a syntactic form using the 
> "-> syntax. These work well together, as both indicate asynchrony, with the 
> direction of the arrow indicating what is eventually being delivered to what.
> 
> In JS, "a <- b" already parses as "a < -b" so introducing a "<-" token is a 
> non-starter. Process calculi languages like Pict (based on Pi Calculus), and 
> languages inspired by process calculi notions like Erlang and Scala use an 
> infix "!" for message sending, with the receiver on the left and the payload 
> on the right. This started with Tony Hoare's CSP (Communicating Sequential 
> Processes) and was picked up by Occam, where it was synchronous. Technically 
> it is synchronous in the Pi Calculus too. But in Pict, Erlang, and Scala it 
> is asynchronous. (Pict is based on the asynchronous subset of the Pi 
> Calculus.)
> 
> More importantly for our audience, for JS (and similarly for Scala), there's 
> also a nice mnemonic rule: Wherever you can write an infix "." you can write 
> an infix "!" instead, changing the meaning of the construct from synchronous 
> to asynchronous. The "!" symbol has a "." at the bottom of it, so you can 
> think of it as "an enhanced dot" or even "a dot with a trail" if you'd like.
> 
> In any case, once the eye gets used to it the need for these mnemonics 
> rapidly drops away. Having lived with both "<-" and "!", I've come to prefer 
> the "!". I'm not really sure why.
> 
> 
> 
> 
> On Sat, Jun 15, 2013 at 7:23 PM, Rick Waldron  wrote:
> 
> 
> On Saturday, June 15, 2013, Mark S. Miller wrote:
> If we do provide such special syntax, then I suggest (a variant on some 
> else's suggestion -- I forget who) that "yield" is to "function* as "await" 
> is to "function!", amplifying the association of "!" with asynchrony. Rather 
> than say "async function" or whatever, we'd just say "function!". Since 
> "function!" would be new in ES7, there's no reason to reserve anything in ES6 
> to prepare for this.
> 
> Mark, is there a particular rationale for the reuse of "!" as the eventual 
> send operator and here for similar semantics? I recall this also appeared in 
> you Distributed Electronic Rights paper. Putting its strong existing meaning 
> aside (negation), when I see "!" I think of "urgent" things—quite the 
> opposite of the behavior described in the paper and above.
> 
> Rick
> 
> 
>  
> 
> 
> 
> 
> On Sat, Jun 15, 2013 at 2:40 AM, Bruno Jouhier  wrote:
> If this is on the agenda for ES7 maybe ES6 should at least reserve "await" as 
> a keyword in function* scopes. 
> 
> 
> 2013/6/15 François REMY 
> I'm maybe biased, but I would love to consider "yield" as a function. Indeed, 
> it calls another code, which can return you a value. That looks very similar 
> to a function call to me. If we do this, the predecence becomes intuitive 
> again:
> 
>var x = yield(a) + yield(b);
>yield(a+b);
> 
> I think there was a proposal to allow parenthesis-free function call at some 
> point at the root of a statement. When it lands, you'll be able to do things 
> like
> 
>yield a+b;
> 
> as a normal statement again. In the mean time we can just use parentheses, 
> that's not a huge issue and it helps clarity.
> 
> 
> 
> But maybe this is too late to change ES6, it's just an idea I had while 
> reading this thread, not a strong call for change.
> 
> 
> 
> 
> 
> 
> -Message d'origine- From: Brendan Eich
> Sent: Saturday, June 15, 2013 6:17 AM
> To: Dean Tribble
> Cc: Bruno Jouhier ; es-discuss@mozilla.org
> Subject: Re: Precedence of yield operator
> 
> 
> This is all on the agenda for ES7. It cleanly missed ES6 in May 2011(!).
> 
> https://mail.mozilla.org/pipermail/es-discuss/2011-May/014748.html
> 
> /be
> 
> Dean Tribble wrote:
> This is a familiar d

Re: Array#sort() implementations not interoperable

[Oliver Hunt]

JSC switched to an always stable sort years ago due to compatibility problems 
with content targeting firefox and IE depending on it.

We also had issues with inconsistent comparison functions, but i can't recall 
exactly what the reasoning behind it was (nor the exact behavior we felt was 
necessary), but we ended up with an AVL tree being involved, so we may be 
attempting to only compare two elements with each other once.  Unfortunately 
this code is a little bit gnarly for me to read and understand today :-(

I believe that the spec should mandate a stable sort, but i'm not sure just how 
far we can go in trying to standardize exact behavior of the sort without tying 
implementations to a single implementation for all time.

--Oliver


On Jun 13, 2013, at 12:16 PM, Kevin Gadd  wrote:

> I have read the ES specs multiple times, and still accidentally shipped an 
> application that was broken by Array.sort's default behavior in the wild. I 
> know other people who have had the same issues, and people who have read the 
> spec and don't happen to have particular quirks defined in the spec 
> memorized. People are not great at remembering spec details. Simply demanding 
> that all JS developers in the wild read the spec will *not* address these 
> issues. Modern application development occurs on multiple platforms, in 
> multiple languages, using multiple libraries. No matter how many times the 
> spec is read, if the developer is regularly writing and thinking in different 
> languages using different primitives, the primitives that defy trends and act 
> in unexpected ways will always be a stumbling block. The v8 issue and related 
> issue reports against Underscore both serve to demonstrate this.
> 
> I don't understand why you would intentionally sidetrack a discussion about a 
> simple problem with academic details. Yes, if your goal is to write proofs or 
> rigorously demonstrate that your software is correct all the time, the exact 
> definition of different sort algorithms and terminology really does matter, 
> and yes, it is valuable for people to read the spec. But that is not remotely 
> relevant to the original post in this discussion thread and was not suggested 
> by my replies either. This thread *should* be about whether the ES spec can 
> protect developers from subtle mistakes and errors by changing the 
> specification of Array.sort. Is the point trying to be made here that it is 
> impossible for the spec to clearly communicate that implementations should 
> not do what V8 does, and this communication is impossible because of the 
> academic definition? You haven't even once addressed the original core 
> question of whether it would be possible to switch Array.sort to being 
> stable, and what the obstacles to that would be.
> 
> There are examples out there in the wild of how difficult it is to write a 
> performant sort in JS from scratch; you need only look at the Bugzilla bug 
> about self-hosting Array.sort in Spidermonkey. Or we can look at the number 
> of *broken* binary search implementations out in the wild caused by people 
> copying from broken algorithms in textbooks that behave incorrectly in 
> boundary cases. Please, for the love of $deity, do not just tell developers 
> to type a query into stackoverflow and grab the top result. I don't 
> necessarily think that it is automatically the right choice to say 'do it 
> yourself' for a problem like this, though it could easily be correct in this 
> specific case, since Underscore ships a stable sort function. Most developers 
> probably use jQuery and/or Underscore already to make up for the small number 
> of useful primitives in the JS standard library, and that's fine.
> 
> -kg
> 
> 
> On Thu, Jun 13, 2013 at 9:50 AM, David Bruant  wrote:
> Le 13/06/2013 17:56, Kevin Gadd a écrit :
> 
> I don't really care about the precise language or semantics.
> Maybe you should. In my opinion, that would certainly help having your case 
> better understood and heard.
> 
> 
> I just don't want applications to break in the wild because an Array.sort 
> implementation's stability changes based on the number of elements.
> A stable sort is just a particular case of an unstable sort. So, if a sort is 
> "sometimes unstable", then it is "always unstable". The impression of a 
> stability for some cases is just a distraction.
> 
> It's also not like if "sort" was confusing like isNaN. "sort" does its job.
> 
> 
> That feels like a much easier problem to solve than the problem of some 
> browsers being unstable and some being stable. This is absolutely the sort of 
> thing that would bite me as a JS dev and will bite every person who uses my 
> compiler to convert an application. Why would they test with both small and 
> large element counts?
> They can also read the spec and learn they can't rely on sort stability 
> (second sentence of ES5 - 15.4.4.11 !). Specs aren't just for implementors. 
> As a web developer, I feel it's a time-consum

Re: additional Math function

[Oliver Hunt]

I landed support for Math.imul in JSC yesterday as well.

Can't find actual documentation on the expected behavior so just copied what 
mozilla does.

--Oliver

On Apr 26, 2013, at 10:58 AM, Rick Waldron  wrote:

> 
> On Apr 26, 2013 8:42 AM, "Tom Schuster"  wrote:
> >
> > Math.imul support was just added to the v8 trunk:
> > https://code.google.com/p/v8/source/detail?r=14450.
> > Is there any ongoing effort to standardize it?
> >
> 
> As with Firefox, which you actually implemented :)
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=808148
> 
> There is no record of consensus (that I can locate) since this thread first 
> began. I don't see why anyone object, but we should get it on record.
> 
> Rick
> 
> 
> 
> 
> > On Fri, Nov 2, 2012 at 9:24 PM, Brendan Eich  wrote:
> > > David Herman wrote:
> > >>
> > >> On Nov 2, 2012, at 12:05 PM, Yehuda Katz  wrote:
> > >>
> > >>> Seems like a small surface-area with a large impact on compilers.
> > >>>
> > >>> At first glance, looks good to me.
> > >>>
> > >>> Curiosity: Does this overlap with Brendan's work on value objects (i.e.
> > >>> will it become moot in the face of them)
> > >>
> > >>
> > >> It could become unnecessary if you're working with value objects. If you
> > >> had ordinary numbers, you'd have to coerce them to u32 and then multiply:
> > >>
> > >>  var a = 0x7fff, b = 0x7fefefef; // both doubles
> > >>  var result = int32(a) * int32(b);   // int32
> > >>
> > >> But value objects are still uncertain
> > >
> > >
> > > I'm focusing on int64 and uint64 but making the framework as general under
> > > the hood as possible (e.g., the operators stuff, a multimethod variation
> > > that's inline-cacheable, based on an idea from Christian Plesner Hansen).
> > >
> > > The need for 64-bit ints is pretty strong in Node.js and I think this 
> > > means
> > > value objects are a priority for ES7.
> > >
> > >
> > >>   and at the very least much farther off into the future -- post-ES6.
> > >> Engines could implement and ship Math.imul in very short order.
> > >
> > >
> > > Agreed, and this kind of micro-evolution is important to support even 
> > > while
> > > working on value objects for post-ES6. It may be we end up with int32 and
> > > uint32, but we don't need to if there's no strong use-case not satisfied 
> > > by
> > > Math.imul.
> > >
> > > Note that there's no micro-evolutionary step involving Math.imul64 that
> > > satisfies the int64/uint64 use-cases Node faces (buffer and file
> > > sizes/offsets). You need 64-bit addition, subtraction, and probably other
> > > operators -- and you need the data type, not just operations that could be
> > > Math methods.
> > >
> > > /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
> ___
> 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: memory safety and weak references

[Oliver Hunt]

On Apr 1, 2013, at 3:12 PM, "Hudson, Rick"  wrote:

> If the compiler can prove x does not escape the block and it is not used 
> again then it is dead and the compiler is free to reuse the stack slot 
> holding the last reference.
> 
> So I am arguing that x = null; is not required to kill x.
> 

That semantic would mean that the interpreter would need to do escape analysis, 
and then the moment a variable became dead it would be required to clear it, 
even if it did not need that slot for anything else.

The world is filled with papers on ways to reduce the conservatism of a GC, but 
you have to balance the cost of work required for that increased conservatism 
against the win you might get from reduced liveness.

But all of this is kind of moot, as weak refs are by definition going to have 
some degree of non-determinism w.r.t liveness, and the initial discussion was 
of weak refs to primitives which have their own, completely separate problems 
(as was already covered)

--Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: memory safety and weak references

[Oliver Hunt]

There are numerous problems with weak references and primitives, mostly 
revolving around the ability to regenerate a primitive, e.g.

someWeakRef.set("foo")
gc()
var something = "foo"
someWeakRef.get() // null or "foo"?

 vs.

someWeakRef.set("foo")
var something = "foo"
gc()
someWeakRef.get() // null or "foo"?

vs.

someWeakRef.set("foo")
var something = "fo"
something += "o"
gc()
someWeakRef.get() // null or "foo"?

And of course all this just becomes worse for numeric primitives -- All 
existing engines use tagged values for some set of numeric values, and can also 
end up with the same value stored in different ways.  V8 (at least in 32bit) gc 
allocates doubles, but not a subset of integers, this means that if you get the 
value 1 as a double then it might be gc'd and so the weak ref could go away, 
but if it were in the tagged int form it would not.

JSC doesn't immediately intern strings, but over time duplicates do get merged, 
at which point weakness starts acquiring odd behaviour.  Because off the 
implicitly shared heap in different pages this may even be exploitable as a way 
to find out information about other pages (essentially the weak reference to a 
primitive allows a side channel for determining content of other pages that you 
would not otherwise have access to)

This means that any consistent semantic for primitives results in useless 
behaviour - either the weak ref has to be (essentially) strong on primitives, 
or be cleared on ever gc() regardless of "liveness" of other references.

--Oliver


On Apr 1, 2013, at 1:22 PM, Marius Gundersen  wrote:

> This seems to be more a problem with the garbage collector than with weak 
> references. If I understood it correctly, any double value can look like a 
> pointer, and the garbage collector will check what it is pointing at. To me 
> this seems like a source for memory leaks. This problem exists even without 
> weak references (or weak iterable maps/sets); the weak references just makes 
> it observable. Does this mean the main reason weak references (or, again, 
> weak iterable maps/sets) are not to be implemented is because of a bug in the 
> garbage collector of popular JS enginges? As noted earlier, the 
> implementation of the garbage collector is not specified in the ecmascript 
> standard, so this is a problem with implementors, not with the specification. 
> 
> Again, I'm far from an expert on GC or JS implementations (and would love a 
> simplified explanation if I have misunderstood the problem), but this seems 
> less like a problem with weak references, and more like a problem with 
> specific implementations of GCs. 
> 
> Marius Gundersen
> 
> 
> On Fri, Mar 29, 2013 at 3:47 AM, Oliver Hunt  wrote:
> 
> On Mar 29, 2013, at 7:36 AM, David Herman  wrote:
> 
> > On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt  wrote:
> >
> >> On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt  wrote:
> >>> That said I believe that this does kill any dreams i may have had w.r.t 
> >>> primitive-keyed WeakMaps, kudos to MarkM.
> >>
> >> Wouldn't a primitive-keyed WeakMap just be a strong Map for those
> >> keys?  And therefore immune to any GC attacks?
> >
> > Indeed, and also deeply misleading (a weak map with strongly held 
> > entries?), which is why I argued that WeakMap should disallow primitive 
> > keys.
> >
> > Oliver-- can you clarify what you were hoping for?
> 
> I was dreaming of primitive keys, i was convinced in an earlier meeting of 
> the problems that they would cause, but this security problem is a nail in 
> the coffin :-/
> 
> >
> > Dave
> >
> 
> ___
> 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: memory safety and weak references

[Oliver Hunt]

On Mar 29, 2013, at 7:36 AM, David Herman  wrote:

> On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt  wrote:
> 
>> On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt  wrote:
>>> That said I believe that this does kill any dreams i may have had w.r.t 
>>> primitive-keyed WeakMaps, kudos to MarkM.
>> 
>> Wouldn't a primitive-keyed WeakMap just be a strong Map for those
>> keys?  And therefore immune to any GC attacks?
> 
> Indeed, and also deeply misleading (a weak map with strongly held entries?), 
> which is why I argued that WeakMap should disallow primitive keys.
> 
> Oliver-- can you clarify what you were hoping for?

I was dreaming of primitive keys, i was convinced in an earlier meeting of the 
problems that they would cause, but this security problem is a nail in the 
coffin :-/

> 
> Dave
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observability of NaN distinctions — is this a concern?

[Oliver Hunt]

On Mar 27, 2013, at 7:53 PM, Jussi Kalliokoski  
wrote:
> 
> Given that we can't guarantee that the bit pattern will remain unchanged the 
> spec should mandate normalizing to the non-signalling NaN.
> 
> --Oliver
> 
> It's not trivially exploitable, at least not in SM or V8. I modified the 
> example Mark made [1] and ran it through js (SpiderMonkey) and node (V8) to 
> observe some of the differences of how they handle NaN. Neither could be 
> pwned using the specified method. In V8, the difference is observable only if 
> you assign the funny NaN directly to the array (i.e. it doesn't go through a 
> variable or stuff like that). In SM, the difference is more observable, i.e. 
> the bit pattern gets transferred even if you assign it to a variable in 
> between, but no observable enough to make pwning possible. Of course, feel 
> free to fork the gist and show me how it can be exploited. :)
> 

Of _course_ it's not trivially exploitable in V8, SM, or JSC - You even say 
that you can see the different NaNs come and go.  In general we try not to ship 
trivially exploitable code.  

To my knowledge all engines convert signaling NaNs to a safe non signaling NaN 
on _load_.  That is an absolutely unavoidable cost given the untyped backing 
stores that typed arrays insist on.

If you were to say "signaling NaNs must be preserved" modern engines would have 
to essentially drop NaN boxing, and take a huge hit to general performance and 
memory use.  The alternative would be a land of trivial exploitation - If you 
want to see how bad it would be you'll need to modify your engine of choice to 
stop it from performing NaN canonicalization on read, and then see what happens 
when you do stuff like

doubleArray[indexOfBogusNaN].toString()

As an implementer I can tell you that you'll be able to make it crash.  And 
exploiting it would not be too much harder.

--Oliver




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: memory safety and weak references

[Oliver Hunt]

On Mar 27, 2013, at 1:56 PM, David Herman  wrote:

> Interestingly, I wonder if the idea of only collecting weak references 
> between turns is immune to such attacks, since it's not possible to have a 
> bogus reference on the stack between turns, where there is no stack.

If you could induce an integer with a controlled value to be on the stack 
between turns (not entirely inconceivable) it may be attackable, but once 
you're talking about a fixed number of samples per _turn_ i suspect the time 
required renders the attack infeasible.

That said I believe that this does kill any dreams i may have had w.r.t 
primitive-keyed WeakMaps, kudos to MarkM.

--Oliver

> 
> Dave
> 
> On Mar 26, 2013, at 5:55 PM, David Herman  wrote:
> 
>> Patrick Walton send me this link to a fascinating approach to exploiting 
>> weak references in engines using conservative stack scanning to discover the 
>> address of objects:
>> 
>>   https://github.com/justdionysus/gcwoah
>> 
>> I don't fully grok all the details, but IIUC the attacker sprays the heap 
>> with objects that it holds weak references to, synthesizes a fake reference 
>> as an integer, triggers a conservative GC, and then uses the state of the 
>> weak references to figure out which object lived at that address. As a 
>> concrete example of how this can be used to do bad things: in conjunction 
>> with an exploit that allows jumping to an arbitrary memory location, this 
>> would effectively enable arbitrary code execution.
>> 
>> One immediate takeaway: Mark deserves serious kudos, because Dionysus was 
>> not able to figure out how to use this attack on WeakMaps. He explicitly 
>> mentions the work on WeakMaps and credits them for having been well designed 
>> for security. Well done!
>> 
>> But we need to take this into account as we consider what to do about weak 
>> references in ES7.
>> 
>> Dave
>> 
>> ___
>> 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

Re: Observability of NaN distinctions — is this a concern?

[Oliver Hunt]

On Mar 26, 2013, at 9:12 PM, Jussi Kalliokoski  
wrote:

> That's just because ES has had no notion of bits for floating points before. 
> Other than that, ES NaN works like IEEE NaN, e.g.
> 
> 0/0 === NaN // false
> isNaN(0/0) // true

That's true in any language - comparing to NaN is almost always defined 
explicitly as producing false.  You're not looking at bit patterns, here so 
conflating NaN compares with bit values is kind of pointless.



> 
>  
> 
>  
>  
> We need to stop raising "this causes performance problems" type issues 
> without a concrete example of that problem.  I remember having to work very 
> hard to stop WebGL from being a gaping security hole in the first place and 
> it's disappointing to see these same issues being re-raised in a different 
> forum to try and get them bypassed here.
> 
> Before saying security hole, please elaborate. Also, when it comes to 
> standards, I think change should be justified with data, rather than the 
> other way around.
> 
> Done.
> 
> You'll have to do better than that. ;)

Ok, I'll try to go over this again, because for whatever reason it doesn't 
appear to stick:

If you have a double-typed array, and access a member:
typedArray[0]

Then in ES it is a double that can be one of these values: +Infinitity, 
-Infinity, NaN, or a discrete value representable in IEEE double spec.  There 
are no signaling NaNs, nor is there any exposure of what the underlying bit 
pattern of the NaN is.

So the runtime loads this double, and then stores it somewhere, anywhere, it 
doesn't matter where, eg.
var tmp = typedArray[0];

Now you store it:
typedArray[whatever] = tmp;

The specification must allow a bitwise comparison of typedArray[whatever] to 
typedArray[0] to return false, as it is not possible for any NaN-boxing engine 
to maintain the bit equality that you would otherwise desire, as that would be 
trivially exploitable.  When I say security and correctness i mean it in the 
"can't be remotely pwned" sense.

Given that we can't guarantee that the bit pattern will remain unchanged the 
spec should mandate normalizing to the non-signalling NaN.

--Oliver


> 
> Cheers,
> Jussi
>  
> 
>  
> 
> Cheers,
> Jussi
> 
> 
> --Oliver
> 
> > Allen
> >
> >
> >
> >
> >>
> >> /be
> >>
> >> On Mar 25, 2013, at 4:33 PM, Kenneth Russell  wrote:
> >>
> >>> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich  wrote:
>  Allen Wirfs-Brock wrote:
> >
> > On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
> >
> >> Allen Wirfs-Brock wrote:
> >>>
> >>> BTW, isn't cannonicalization of endian-ness for both integers and 
> >>> floats
> >>> a bigger interop issue than NaN cannonicalization?  I know this was
> >>> discussed in the past, but it doesn't seem to be covered in the latest
> >>> Khronos spec.  Was there ever a resolution as to whether or not 
> >>> TypedArray
> >>> [[Set]] operations need to use a cannonical endian-ness?
> >>
> >> Search for "byte order" at
> >> https://www.khronos.org/registry/typedarray/specs/latest/.
> >
> >
> > I had already search for "endian" with similar results.  It says that 
> > the
> > default for DataViews gets/sets that do not specify a byte order is
> > big-endean. It doesn't say anything (that I can find) about such 
> > accesses on
> > TypedArray gets/sets.
> 
> 
>  Oh, odd -- I recall that it used to say little-endian. Typed arrays are 
>  LE
>  to match dominant architectures, while DataViews are BE to match packed
>  serialization use-cases.
> 
>  Ken, did something get edited out?
> >>>
> >>> No. The typed array views (everything except DataView) have used the
> >>> host machine's endianness from day one by design -- although the typed
> >>> array spec does not state this explicitly. If desired, text can be
> >>> added to the specification to this effect. Any change in this behavior
> >>> will destroy the performance of APIs like WebGL and Web Audio on
> >>> big-endian architectures.
> >>>
> >>> Correctly written code works identically on big-endian and
> >>> little-endian architectures. See
> >>> http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a
> >>> detailed description of the usage of the APIs.
> >>>
> >>> DataView, which is designed for input/output, operates on data with a
> >>> specified endianness.
> >>>
> >>> -Ken
> >>> ___
> >>> 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

Re: Observability of NaN distinctions — is this a concern?

[Oliver Hunt]

On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock  wrote:

> 
> On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
> 
>> Right, thanks for the reminder. It all comes back now, including the "how to 
>> write correct ending-independent typed array code" bit.
> 
> Ok, so looping back to my earlier observation.  It sounds like endian-ness 
> can be observed by writing into an Float64Array element and then reading back 
> from a Uint8Array that is backed by the same buffer.  If there is agreement 
> that this doesn't represent a significant interoperability hazard can we also 
> agree that not doing NaN cannonicalization on writes to FloatXArray is an 
> even less significant hazard and need not be mandated?
> 

The reason I have pushed for NaN canonicalization is because it means that it 
allows (and in essence requires) that typedArray[n] = typedArray[n] can modify 
the bit value of typedArray[n].

An implementation _may_ be able to optimize the checks away in some cases, but 
most engines must perform checks on read unless they can prove that they were 
the original source of the value being read.

Forcing canonicalization simply means that you are guaranteed that a certain 
behavior will occur, and so won't be bitten by some tests changing behavior 
that you may have seen during testing.  I know Ken hates these sorts of things, 
but seriously in the absence of a real benchmark, that shows catastrophic 
performance degradation due to this, simply saying "this is extra work that 
will burn cpu cycles" without evidence is a waste of time.  Also there is 
absolutely no case in which abstract performance concerns should ever outweigh 
absolute security and correctness bugs.

We need to stop raising "this causes performance problems" type issues without 
a concrete example of that problem.  I remember having to work very hard to 
stop WebGL from being a gaping security hole in the first place and it's 
disappointing to see these same issues being re-raised in a different forum to 
try and get them bypassed here.

--Oliver

> Allen
> 
> 
> 
> 
>> 
>> /be
>> 
>> On Mar 25, 2013, at 4:33 PM, Kenneth Russell  wrote:
>> 
>>> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich  wrote:
 Allen Wirfs-Brock wrote:
> 
> On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
> 
>> Allen Wirfs-Brock wrote:
>>> 
>>> BTW, isn't cannonicalization of endian-ness for both integers and floats
>>> a bigger interop issue than NaN cannonicalization?  I know this was
>>> discussed in the past, but it doesn't seem to be covered in the latest
>>> Khronos spec.  Was there ever a resolution as to whether or not 
>>> TypedArray
>>> [[Set]] operations need to use a cannonical endian-ness?
>> 
>> Search for "byte order" at
>> https://www.khronos.org/registry/typedarray/specs/latest/.
> 
> 
> I had already search for "endian" with similar results.  It says that the
> default for DataViews gets/sets that do not specify a byte order is
> big-endean. It doesn't say anything (that I can find) about such accesses 
> on
> TypedArray gets/sets.
 
 
 Oh, odd -- I recall that it used to say little-endian. Typed arrays are LE
 to match dominant architectures, while DataViews are BE to match packed
 serialization use-cases.
 
 Ken, did something get edited out?
>>> 
>>> No. The typed array views (everything except DataView) have used the
>>> host machine's endianness from day one by design -- although the typed
>>> array spec does not state this explicitly. If desired, text can be
>>> added to the specification to this effect. Any change in this behavior
>>> will destroy the performance of APIs like WebGL and Web Audio on
>>> big-endian architectures.
>>> 
>>> Correctly written code works identically on big-endian and
>>> little-endian architectures. See
>>> http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a
>>> detailed description of the usage of the APIs.
>>> 
>>> DataView, which is designed for input/output, operates on data with a
>>> specified endianness.
>>> 
>>> -Ken
>>> ___
>>> 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

Re: Throwing StopIteration in array extras to stop the iteration

[Oliver Hunt]

On Mar 3, 2013, at 12:05 PM, Brendan Eich  wrote:

> (a) not a compatible change for engines already prototyping StopIteration.
> (b) wrong hammer for this nail.
> 
> Are the some and every names confusing? Would any and all be better?

I think the naming boat has sailed, and i'm not sure if any and all are 
superior anyway (the fact that this has come up is evidence of the similarity 
of the terms and futility of choosing one set of names to represent all 
things).  If someone really cares about it they'll just make aliases like 
all/any/$woo/etc..

> 
> I think this is an RTFM thing, and people are smart, they memorize what they 
> need to know.
Agreed.

> 
> /be

--Oliver


> David Bruant wrote:
>> Le 03/03/2013 20:29, Brendan Eich a écrit :
>>> If you want some or every and not forEach, they are there -- use them. No 
>>> exception required.
>> I've found myself multiple times in a situation where I needed the index of 
>> the first element responding to some conditions. I solved it the following 
>> way:
>> 
>>var index;
>>array.some(function(e, i){
>>if(someCondition(e)){
>>index = i;
>>return false;
>>}
>> 
>>return true;
>>})
>> 
>> It works, but felt a bit awkward. It's a hack on .some because there is no 
>> other way to stop an iteration in other array methods.
>> Also spending hours on debugging because someone confused "some" for "every" 
>> (mixed the meaning of true/false) isn't fun.
>> 
>>var index;
>>array.forEach(function(e, i){
>>if(someCondition(e)){
>>index = i;
>>throw StopIteration;
>>}
>>})
>> 
>> would look more explicit in my opinion.
>> 
>> David
>> 
> ___
> 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: Check out Dart's iterators

[Oliver Hunt]

On Feb 11, 2013, at 1:58 PM, Brendan Eich  wrote:

> Oliver Hunt wrote:
>> 
>> So what you're saying is that people who attend in person meetings are able 
>> to veto proposals,
> 
> No, I didn't say that. You are good at logic, I've seen your code. I know you 
> grok P -> Q does not imply !P -> !Q.

It seems reasonable to interpret your statement as saying that vetos are  
possible, but they aren't available to people unless they attend meetings.

Or are you saying that vetos aren't possible in the meetings?

>> People aren't required to attend TPAC to have input at least considered for 
>> inclusion in W3 specs.
> 
> They don't get to throw unilaterla vetos there either.

I'm not actually sure where I threw a veto.

> 
> /be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Check out Dart's iterators

[Oliver Hunt]

On Feb 11, 2013, at 1:33 PM, Jason Orendorff  wrote:

> On Mon, Feb 11, 2013 at 12:30 PM, Oliver Hunt  wrote:
> 
> For now I would say that we shouldn't expose the internal implementation 
> behaviour of yield (which is what being able to explicitly create or call a 
> generator produces).  That fairly trivially resolves the StopIteration 
> behaviour by pushing it out of the ES6 spec.  If there's enough demand for 
> manually creating or 'calling' a generator then we can fix it in ES6.x/7
> 
> Can you be more concrete? Generator-iterators must at least be first-class 
> values that can be created and then passed around.

I was meaning you don't have the ability to directly executing a generator - 
you can pass it around, hang properties of it, etc but not directly trigger 
enumeration

so you couldn't go generator.next() or generator() or whatever, but you could 
go for (... of generator) or [ ... generator], etc

> -j

--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Check out Dart's iterators

[Oliver Hunt]

On Feb 11, 2013, at 1:29 PM, Brendan Eich  wrote:

> Domenic Denicola wrote:
>> From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on 
>> behalf of Oliver Hunt [oli...@apple.com]
>> 
>>> For now I would say that we shouldn't expose the internal implementation 
>>> behaviour of yield (which is what being able to explicitly create or call a 
>>> generator produces).  That fairly trivially resolves the StopIteration 
>>> behaviour by pushing it out of the ES6 spec.  If there's enough demand for 
>>> manually creating or 'calling' a generator then we can fix it in ES6.x/7
>> 
>> Would this prevent TaskJS from working in ES6?
> 
> Sorry, we are not going to do that.

I still don't know what is being talked about here :D

> 
> Oliver was around at at least one of the meetings where iterators got 
> consensus or kept it. He's been AWOL enough that I'm going to say right here 
> that he doesn't get to throw a veto.

So what you're saying is that people who attend in person meetings are able to 
veto proposals, and input from people who don't attend those meetings don't, 
and get much less input into the standard?  That's a fairly closed approach, 
especially when compared to more or less every other web standard.

People aren't required to attend TPAC to have input at least considered for 
inclusion in W3 specs.

--Oliver




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Check out Dart's iterators

[Oliver Hunt]

On Feb 11, 2013, at 10:35 AM, Domenic Denicola  
wrote:

> From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on 
> behalf of Oliver Hunt [oli...@apple.com]
> 
>> For now I would say that we shouldn't expose the internal implementation 
>> behaviour of yield (which is what being able to explicitly create or call a 
>> generator produces).  That fairly trivially resolves the StopIteration 
>> behaviour by pushing it out of the ES6 spec.  If there's enough demand for 
>> manually creating or 'calling' a generator then we can fix it in ES6.x/7
> 
> Would this prevent TaskJS from working in ES6?
> 
> If so, I'm so sorry I started this thread, I take it all back!! :P
I'm not sure what you're talking about here - if a framework is using for(of) 
or yield they shouldn't need to create custom generators (at a very basic 
overview a JS implementation of pseudo yield is unlikely to be able to beat 
what the JS engine+runtime will be able to do), and if you're unable to use 
yield or for(of) due to backwards compat concerns then you are already 
implementing custom generator like behaviour that has no engine/runtime/syntax 
dependencies.

--Oliver

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Check out Dart's iterators

[Oliver Hunt]

On Feb 11, 2013, at 8:54 AM, Jason Orendorff  wrote:

> 
> 
> 
> On Sun, Feb 10, 2013 at 4:05 PM, Oliver Hunt  wrote:
>> It turns out (at least in Python) that while you rarely have to directly 
>> implement the raw iterator protocol, you seriously almost *never* have to 
>> directly consume it. So it was the right design decision, in Python at 
>> least, to optimize the protocol for ease of use on the *implementing* side.
> 
> Sorry, I don't follow what you're saying here - which implementer? the 
> language implementer or the developer?
> 
> Developer.
>  
> using the python example below your iterator would be:
> 
> function myCustomGenerator() {
> while (line = this.readline())
>yield line
> }
> 
> Agreed. The raw iterator protocol only ever matters if you're trying to avoid 
> the generator overhead or something.

Saving the cost of "generator overhead" by making all iteration technically 
slower by depending on exceptions (correct semantics mean even optimising out 
the throw is tricky for default iteration generators).

Additionally get the correct behaviour for StopIterator is non-trivial as you 
aren't simply doing "throw StopIterator" you have to do "throw 
StopIterator(magic value that you know consumer will check for)"

For now I would say that we shouldn't expose the internal implementation 
behaviour of yield (which is what being able to explicitly create or call a 
generator produces).  That fairly trivially resolves the StopIteration 
behaviour by pushing it out of the ES6 spec.  If there's enough demand for 
manually creating or 'calling' a generator then we can fix it in ES6.x/7

> 
> -j

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Check out Dart's iterators

[Oliver Hunt]

On Feb 10, 2013, at 1:55 PM, Jason Orendorff  wrote:

> On Sun, Feb 10, 2013 at 1:55 PM, Oliver Hunt  wrote:
> I do dislike the exception based termination, I _think_ i'd prefer next() and 
> hasNext() style iteration over exceptions, especially given that for the most 
> part these are hidden by clean syntax.
> 
> Yuck. Python's iterator protocol may be a bit ugly to consume, but it is 
> nicer to implement than next/hasNext. (moveNext/current also seems a little 
> easier to implement than next/hasNext.)

I'm fine with moveNext+current - i was simply meaning two functions are 
superior to one that may or may not throw, and may or may not be throwing 
something that may or may not be generator related.

> 
> It turns out (at least in Python) that while you rarely have to directly 
> implement the raw iterator protocol, you seriously almost *never* have to 
> directly consume it. So it was the right design decision, in Python at least, 
> to optimize the protocol for ease of use on the *implementing* side.

Sorry, I don't follow what you're saying here - which implementer? the language 
implementer or the developer? using the python example below your iterator 
would be:

function myCustomGenerator() {
while (line = this.readline())
   yield line
}

The runtime then will ensure correct semantics.

--Oliver

> 
> For example. In Python, file objects are iterators. It works like this (only 
> actually this is implemented in C, not Python):
> 
> class file:
> ...
> def __iter__(self):
> return self
> 
> def next(self):
> line = self.readline()
> if line == '':
> throw StopIteration
> return line
> ...
> 
> It's nice that the iterator protocol does not require the iterator to store 
> the value across method calls, from hasNext() to next(). It's kind of nice, 
> generally, not to have to worry, in the implementation of hasNext(), about 
> whether or not next() was called since the last time hasNext() was called.
> 
> Probably all this is down in the noise though.
> 
> > My personal concern with all of these is how they deal with nested 
> > iterators.
> 
> I see you've already taken this back, but here's what my answer would've been:
> 
> def iter_tree(node):
> if node is not None:
> for v in node.left:
> yield v
> yield node.value
> for v in node.right:
> yield v
> 
> The low-level protocol just doesn't enter into it. The real APIs for working 
> with Python iterators are yield, for-in, and itertools.
> 
> -j
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Check out Dart's iterators

[Oliver Hunt]

On Feb 10, 2013, at 1:01 PM, David Bruant  wrote:

> Le 10/02/2013 20:55, Oliver Hunt a écrit :
>> Just a couple of questions on this wonderous topic:
>> 
>> * how is 'e instanceof StopIteration' intended to work across multiple 
>> global objects?
> StopIteration has a special "StopIteration" [[Brand]] [1], so the 
> cross-global story shouldn't be a problem for the for-of loop.
> Exposing the brand can solve the problem for manual use of iterators. (you'd 
> check if the object has a particular brand instead of "e instanceof 
> StopIteration").
> 
> StopIteration could also be a deeply frozen constructor with same identity 
> across globals.
> 
>> * how firmly are we wedded to this? I can't imagine there is too much code 
>> that currently depends on manually catching StopIteration given ES6 is not 
>> finalized yet, and iterators aren't widely available.
>> 
>> I do dislike the exception based termination, I _think_ i'd prefer next() 
>> and hasNext() style iteration over exceptions, especially given that for the 
>> most part these are hidden by clean syntax.
> The "for the most part these are hidden by clean syntax" argument applies to 
> throwing StopIteration too, no?

Yes, but exception handling for control flow is generally problematic, and you 
end up with things like:

function foo() {
try {
   ...
   yield ...
   ...
} catch(...) { }
}

Maybe this will be caught, maybe it won't.  If we say that yield acts as an 
exception (eg. manual iteration is performed via catch()) then the _intuition_ 
is that the exception handler will break yield.

You get other things like manual generator usage being astonishingly ugly:

while (true) {
try {
value = generator.next();
...
} catch (e instanceof StopIteration) {
break;
}
}

vs.

while (generator.hasNext()) {
   value = generator.next();
   ...
}

If we're not too concerned about the syntax of using generators manually, then 
I'd just say make it a non-goal.  You can pass a generator around but you can 
only iterate using iteration syntax.  This would allow implementations to use 
whatever behaviour works most efficiently for them internally, without exposing 
it to developers.

The more I think about this, the more I like it.  Let's assume you can't 
directly call the iterator - for(of), comprehensions, etc work.

If it becomes sufficiently important to someone to make it "callable" then they 
can do:

Iterator.prototype.next = function() {
for (value of this)
return value;
throw StopIterator; // Or return magic value, etc
}

> 
>> My personal concern with all of these is how they deal with nested iterators.
> I don't see the concern. Can you provide a use case/code sample where nested 
> iterators would be a problem?


You know what?  I don't think I actually care.  I think I was swayed by a 
random blog post about how nested iterators suck :D - i was thinking of things 
like n-ary tree walkers and realised that most "solutions" end up being hideous 
crimes against code anyway :D

--Oliver


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Check out Dart's iterators

[Oliver Hunt]

Just a couple of questions on this wonderous topic:

* how is 'e instanceof StopIteration' intended to work across multiple global 
objects?
* how firmly are we wedded to this? I can't imagine there is too much code that 
currently depends on manually catching StopIteration given ES6 is not finalized 
yet, and iterators aren't widely available.

I do dislike the exception based termination, I _think_ i'd prefer next() and 
hasNext() style iteration over exceptions, especially given that for the most 
part these are hidden by clean syntax.  My personal concern with all of these 
is how they deal with nested iterators.

--Oliver

On Feb 10, 2013, at 7:57 AM, David Bruant  wrote:

> Le 10/02/2013 16:50, David Bruant a écrit :
>> Le 10/02/2013 16:21, David Bruant a écrit :
 Many feel that exceptions for control-flow are a missdesign, myself 
 included
>> That's the only part I disagree with and my answer applied to.
> s/disagree/agree...
> ___
> 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: Refutable pattern

[Oliver Hunt]

On Feb 5, 2013, at 11:00 PM, Brendan Eich  wrote:

> Sorry if I was a thread-killer, posting four times in a row.
> 
> On balance we have:
> 
> prefix-? pros:
> * LR(1) grammar without ambiguity or lookahead restriction.

What's the production that takes this out of LL(1)?

> 
> prefix-? cons:
> * ASI hazard if ? starts an intended destructuring assignment expression.

That's interestingly icky.

> 
> suffix-? pros:
> * Matches CoffeeScript
I don't really consider that a pro, any more than matching any other language.  
This obsession with coffee script comparisons isn't useful.
 
I think prefix ? is easier from a reading point of view, but I'm not really 
married to either.

--Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: excluding features from sloppy mode

[Oliver Hunt]

On Jan 16, 2013, at 11:54 AM, Domenic Denicola  
wrote:

> Coincidentally, I compiled a list of interesting cases a few days ago, for 
> both const and let. They were meant to be used in kangax's ES6 compatibility 
> table:
> 
> https://github.com/kangax/es5-compat-table/issues/58
> 
> In short:
> 
> const x; // SyntaxError
> let x; let x; // SyntaxError
> const x = 5; const x = 5; // SyntaxError
> x; const x = 5; // ReferenceError
> x; let x; // ReferenceError
> const x = 2; { x; const x = 5; } // ReferenceError
> let x; { x; let x; } // ReferenceError
> 
> plus a test of fresh per-loop iteration for let
> 
> Corrections welcome, and kudos to Brandon Benvie on pointing me to the fact 
> that those last four should be ReferenceErrors.

I'm not too interested in what the spec says these should/should not be.  I'm 
interested in what _shipping_ browser engines do.  Presumably IE throws on all 
of them, but we need a nice table for const which is "supported" by multiple 
engines to show the differences in behaviour so that we can determine the best 
intersection.

--Oliver

> 
> ____
> From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on 
> behalf of Oliver Hunt [oli...@apple.com]
> Sent: Wednesday, January 16, 2013 14:40
> To: Brendan Eich
> Cc: Mark S. Miller; Mark Miller; es-discuss@mozilla.org
> Subject: Re: excluding features from sloppy mode
> 
> Even 10?  If that's the case anything using const is inherently tied to 
> jsc,v8,moz,opera behaviour.
> 
> Presumably the strictest of those _works_, but maybe i'm wrong?
> 
> We should probably just enumerate all the differences and see which can be 
> coalesced and which make "sense" in sloppy mode.
> 
> Obvious cases i can think of:
> 
> --
> const x;
> --
> var x;
> const x;
> x = 5;
> --
> const x;
> var x;
> x = 5;
> --
> const x =4;
> var x = 5;
> log(x)
> --
> if (..)
>   const x = 
> else
>   const x = 
> --
> 
> That's it for now.  Maybe block scoping const will work in sloppy mode?  is 
> for (const x = ...) valid?
> 
> --Oliver
> 
> 
> 
> On Jan 16, 2013, at 11:31 AM, Brendan Eich  wrote:
> 
>> There's no const in IE, so we are pretty sure we can take the hit of 
>> breaking "Mozilla" (non-IE branches, also WebKit, maybe Opera) code that 
>> uses const.
>> 
>> /be
>> 
>> Brandon Benvie wrote:
>>> The incompatibilities between let/const as implemented in V8 and 
>>> Spidermonkey and how they're specified in ES6 are an additional factor:
>>> 
>>> * Per iteration loop binding (V8 and Spidermonkey don't do this for 
>>> let/const).
>>> * TDZ. `x; const x = 10` works in V8 and Spidermonkey currently, specified 
>>> to throw ReferenceError in ES6
>>> 
>>> I think there's other differences.
> 
> ___
> 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: excluding features from sloppy mode

[Oliver Hunt]

Even 10?  If that's the case anything using const is inherently tied to 
jsc,v8,moz,opera behaviour.

Presumably the strictest of those _works_, but maybe i'm wrong?

We should probably just enumerate all the differences and see which can be 
coalesced and which make "sense" in sloppy mode.

Obvious cases i can think of:

--
const x;
--
var x;
const x;
x = 5;
--
const x;
var x;
x = 5;
--
const x =4;
var x = 5;
log(x)
--
if (..)
   const x = 
else
   const x = 
--

That's it for now.  Maybe block scoping const will work in sloppy mode?  is for 
(const x = ...) valid?

--Oliver



On Jan 16, 2013, at 11:31 AM, Brendan Eich  wrote:

> There's no const in IE, so we are pretty sure we can take the hit of breaking 
> "Mozilla" (non-IE branches, also WebKit, maybe Opera) code that uses const.
> 
> /be
> 
> Brandon Benvie wrote:
>> The incompatibilities between let/const as implemented in V8 and 
>> Spidermonkey and how they're specified in ES6 are an additional factor:
>> 
>> * Per iteration loop binding (V8 and Spidermonkey don't do this for 
>> let/const).
>> * TDZ. `x; const x = 10` works in V8 and Spidermonkey currently, specified 
>> to throw ReferenceError in ES6
>> 
>> I think there's other differences.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: excluding features from sloppy mode

[Oliver Hunt]

On Jan 16, 2013, at 11:26 AM, Brandon Benvie  wrote:

> The incompatibilities between let/const as implemented in V8 and Spidermonkey 
> and how they're specified in ES6 are an additional factor:
> 
> * Per iteration loop binding (V8 and Spidermonkey don't do this for 
> let/const).

let isn't really relevant in sloppy mode, unless we decide to take let over 
destructuring (which would make me really sad)

> * TDZ. `x; const x = 10` works in V8 and Spidermonkey currently, specified to 
> throw ReferenceError in ES6

I'm not sure adding TDZ to sloppy mode is feasible for const.  OTOH const is 
such a clusterfoo in sloppy mode i'm not sure what the compatibility story is 
-- I haven't looked at the different behaviours sufficiently to see if they can 
be merged.  I suspect that they can be as const doesn't suffer quite as badly 
as block scoped functions.

Off the top of my head:
* JSC will rebind a const if it's in a const declaration, eg. const x = 5; 
log(x)/*5*/; const x = 6;log(x)/*6*/;  x = 7; log(x)/*6*/; 
* Opera in the past used const as an alias to var, i don't know their current 
behaviour

I don't know which version of IE picked up const (i'm assuming 10 has it?)
and i'm not sure what V8/SM do.

--Oliver

> 
> I think there's other differences.
> 
> 
> On Wed, Jan 16, 2013 at 2:00 PM, Oliver Hunt  wrote:
> let can't be used as an opt in (unfortunately :-( ) as it turns out let is 
> used as a variable name in real world code.
> 
> Gavin and I briefly toyed with the concept of having let be a contextually 
> identified, but that's not doable if you have destructuring assignment in 
> sloppy mode.
> 
> My feeling is that destructuring assignment in sloppy mode is more of a win 
> than let, although i'm not sure how others feel.
> 
> Note that this isn't a "opt-in", this is an attempt to try and minimise the 
> differences between strict and sloppy modes.  My ideal is that anything that 
> can be unambiguously supported in sloppy mode should be.
> 
> --Oliver
> 
> On Jan 16, 2013, at 10:33 AM, Brandon Benvie  
> wrote:
> 
>> Without using modules as the indicator, how do you know whether code is 
>> intended to be run as ES6 or not? Do let and const count as ES6 
>> (retroactively applying to code using the old non-standard versions, which 
>> are still currently supported by V8 and Spidermonkey)? Does it apply to code 
>> that appears to use Map, WeakMap, and Set (though the code might well refer 
>> to shimmed versions of these and not otherwise expect to run as strict)?
>> 
>> While there are many things that will absolutely indicate intention to run 
>> as ES6, there's a number of examples of ambiguity that make me doubt how 
>> successful an absolute judgment can be. This is why I think giving modules a 
>> double use as implicit opt-in/pragma has merit.
>> 
>> On Wednesday, January 16, 2013, Andreas Rossberg wrote:
>> On 1 January 2013 07:09, Mark Miller  wrote:
>> > On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich  wrote:
>> >>
>> >> Mark S. Miller wrote:
>> >> I'm pretty happy with Kevin's compromise. Here it is again:
>> >>
>> >> (1) No opt-in required for new syntax, except:
>> >> (2) No breaking changes to sloppy mode, and
>> >> (3) No grammar contortions (e.g. let) to support sloppy mode.  And
>> >> (4) All new syntax forms with code bodies are implicit strict.
>> >>
>> >> What do you say?
>> >
>> > My preference order:
>> >
>> > 1)
>> > 1.a) To the extent clean and practical, new features are available only in
>> > strict mode,
>> > 1.b) Lexical f-i-b is available in sloppy mode as it is in ES6 strict, 
>> > since
>> > no browser will prohibit f-i-b syntax in sloppy mode. Better to have the
>> > f-i-b sloppy semantics be aligned with the ES6 f-i-b strict semantics.
>> > 1.c) modules (both inline and out) implicitly opt-in to strict mode.
>> > 1.d) classes implicitly opt-in to strict mode.
>> > 1.e) nothing else causes an implicit strict mode opt-in.
>> >
>> > 2) Like #1 but without #1.d (which I think of as Andreas' position)
>> 
>> Yes, although I'd even consider removing 1.c inline (matching your
>> option 6 below).
>> 
>> But what do you mean by "to the extent clean and practical"? In my
>> humble opinion, only two options are really acceptable at all: either
>> _all_ ES6 features work only in strict mode (my preference), or _all_
>> ES6 features work in both modes (how 

Re: excluding features from sloppy mode

[Oliver Hunt]

let can't be used as an opt in (unfortunately :-( ) as it turns out let is used 
as a variable name in real world code.

Gavin and I briefly toyed with the concept of having let be a contextually 
identified, but that's not doable if you have destructuring assignment in 
sloppy mode.

My feeling is that destructuring assignment in sloppy mode is more of a win 
than let, although i'm not sure how others feel.

Note that this isn't a "opt-in", this is an attempt to try and minimise the 
differences between strict and sloppy modes.  My ideal is that anything that 
can be unambiguously supported in sloppy mode should be.

--Oliver

On Jan 16, 2013, at 10:33 AM, Brandon Benvie  wrote:

> Without using modules as the indicator, how do you know whether code is 
> intended to be run as ES6 or not? Do let and const count as ES6 
> (retroactively applying to code using the old non-standard versions, which 
> are still currently supported by V8 and Spidermonkey)? Does it apply to code 
> that appears to use Map, WeakMap, and Set (though the code might well refer 
> to shimmed versions of these and not otherwise expect to run as strict)?
> 
> While there are many things that will absolutely indicate intention to run as 
> ES6, there's a number of examples of ambiguity that make me doubt how 
> successful an absolute judgment can be. This is why I think giving modules a 
> double use as implicit opt-in/pragma has merit.
> 
> On Wednesday, January 16, 2013, Andreas Rossberg wrote:
> On 1 January 2013 07:09, Mark Miller  wrote:
> > On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich  wrote:
> >>
> >> Mark S. Miller wrote:
> >> I'm pretty happy with Kevin's compromise. Here it is again:
> >>
> >> (1) No opt-in required for new syntax, except:
> >> (2) No breaking changes to sloppy mode, and
> >> (3) No grammar contortions (e.g. let) to support sloppy mode.  And
> >> (4) All new syntax forms with code bodies are implicit strict.
> >>
> >> What do you say?
> >
> > My preference order:
> >
> > 1)
> > 1.a) To the extent clean and practical, new features are available only in
> > strict mode,
> > 1.b) Lexical f-i-b is available in sloppy mode as it is in ES6 strict, since
> > no browser will prohibit f-i-b syntax in sloppy mode. Better to have the
> > f-i-b sloppy semantics be aligned with the ES6 f-i-b strict semantics.
> > 1.c) modules (both inline and out) implicitly opt-in to strict mode.
> > 1.d) classes implicitly opt-in to strict mode.
> > 1.e) nothing else causes an implicit strict mode opt-in.
> >
> > 2) Like #1 but without #1.d (which I think of as Andreas' position)
> 
> Yes, although I'd even consider removing 1.c inline (matching your
> option 6 below).
> 
> But what do you mean by "to the extent clean and practical"? In my
> humble opinion, only two options are really acceptable at all: either
> _all_ ES6 features work only in strict mode (my preference), or _all_
> ES6 features work in both modes (how I interpret 1JS). Something
> in-between, i.e., deciding inclusion into sloppy mode on a by-feature
> basis, is a non-starter in terms of usability and observable
> complexity. That is, rather (5) than (4) below.
> 
> > 3) Like #1, but #1.e is replaced with
> > 3.e) All code bodies within new function syntax is implicitly strict.
> 
> I'd be strongly opposed to this (and Kevin's point (4) in general).
> 
> > 4) Like #3, but #1.a is replaced with
> > 4.a) To the extent clean and practical, new features are available in sloppy
> > mode.
> > I take it this is essentially your position and Kevin's compromise position?
> >
> > 5) Where things stood at the end of the last TC39 meeting, where we were
> > violating the "clean" of #4.a to kludge things like "let",
> > non-duplicated-formals-sometimes, no-arguments-sometimes, weird scoping for
> > default argument expressions, etc, into sloppy mode.
> >
> > 6) Like #2 but without #1.c. Is this essentially Kevin's pre-compromise
> > position?
> ___
> 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

Re: Pure functions in EcmaScript

[Oliver Hunt]

IIRC NaN is readonly, but you'd need to be able to guarantee the lexical scope 
between your function definition and the global object did have any shadowing :D

--Oliver

On Nov 28, 2012, at 1:32 PM, Axel Rauschmayer  wrote:

> Would returning NaN be impure (apart from running the risk of it having been 
> changed to something different, globally)?
> 
> On Nov 28, 2012, at 21:35 , Oliver Hunt  wrote:
> 
>> 
>> On Nov 28, 2012, at 12:25 PM, Waldemar Horwat  wrote:
>> 
>>> On Wed, Nov 28, 2012 at 5:39 AM, Marius Gundersen  
>>> wrote:
>>> On Wed, Nov 28, 2012 at 1:20 PM, Andreas Rossberg  
>>> wrote:
>>> Second, due to the extremely impure nature of JavaScript, there aren't
>>> many useful pure functions you could even write. For example, your
>>> 'sum' function is not pure, because the implicit conversions required
>>> by + can cause arbitrary side effects.
>>> 
>>> Functions passed to the array methods map, reduce, filter, etc would be 
>>> good candidates for pure/side-effect-free functions. These functions 
>>> shouldn't alter any state; they should only return a new value based on the 
>>> parameter they were sent.
>>> 
>>> You haven't addressed Andreas's point: Almost any function you write is 
>>> nonpure, including your sum example. As a fun exercise, go ahead and write 
>>> a pure version of your sum example.
>>> 
>>> Waldemar
>> Here you go:
>> 
>> function sum(a, b) {
>>var undefined;
>>switch (typeof a) {
>>case "number":
>>case "string":
>>break;
>>default:
>>return +undefined;
>>}
>>switch (typeof b) {
>>case "number":
>>case "string":
>>break;
>>default:
>>return +undefined;
>>}
>>return a + b;
>> } 
>> 
>> 
>> 
>>> 
>>> ___
>>> 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
> 
> -- 
> 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

Re: Pure functions in EcmaScript

[Oliver Hunt]

On Nov 28, 2012, at 1:11 PM, David Bruant  wrote:

> Le 28/11/2012 21:35, Oliver Hunt a écrit :
>> 
>> On Nov 28, 2012, at 12:25 PM, Waldemar Horwat  wrote:
>> 
>>> On Wed, Nov 28, 2012 at 5:39 AM, Marius Gundersen  
>>> wrote:
>>> On Wed, Nov 28, 2012 at 1:20 PM, Andreas Rossberg  
>>> wrote:
>>> Second, due to the extremely impure nature of JavaScript, there aren't
>>> many useful pure functions you could even write. For example, your
>>> 'sum' function is not pure, because the implicit conversions required
>>> by + can cause arbitrary side effects.
>>> 
>>> Functions passed to the array methods map, reduce, filter, etc would be 
>>> good candidates for pure/side-effect-free functions. These functions 
>>> shouldn't alter any state; they should only return a new value based on the 
>>> parameter they were sent.
>>> 
>>> You haven't addressed Andreas's point: Almost any function you write is 
>>> nonpure, including your sum example. As a fun exercise, go ahead and write 
>>> a pure version of your sum example.
>>> 
>>> Waldemar
>> Here you go:
>> 
>> function sum(a, b) {
>>var undefined;
>>switch (typeof a) {
>>case "number":
>>case "string":
>>break;
>>default:
>>return +undefined;
>>}
>>switch (typeof b) {
>>case "number":
>>case "string":
>>break;
>>default:
>>return +undefined;
>>}
>>return a + b;
>> } 
> I don't even... Reading this makes me understand why "return a+b" didn't work 
> and... oh well... JavaScript is quite a language...

my favourite bit in all of this was 
var undefined;
...
return +undefined;

Although i realise that 0/0 is possibly going to be a more efficient way to get 
NaN :D

> 
> David

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss