Re: Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

On Jul 6, 2011, at 3:19 PM, Allen Wirfs-Brock wrote: > So, a next step is to look at this in combination with other Harmony > proposals. In particular, the object literal extensions. Yes, I've been dividing and conquering ;-). Thanks for the followup. > There is one pretty obvious ambiguity

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

2011/7/6 Dave Fugate : >     var x = /\1/; > > > > According to 15.10.2.11, the RegExp snippet above should throw something as > there aren’t any capturing parenthesis within the RegExp, yet one is > referenced.  Just now noticed that step 4 of 15.10.2.9 is more precise and > shows a Sy

Re: /\1/ could be a valid RegExp through Chapter 16 Extension clause?

On Jul 6, 2011, at 4:35 PM, Dave Fugate wrote: > var x = /\1/; > > According to 15.10.2.11, the RegExp snippet above should throw something as > there aren’t any capturing parenthesis within the RegExp, yet one is > referenced. Just now noticed that step 4 of 15.10.2.9 is mor

/\1/ could be a valid RegExp through Chapter 16 Extension clause?

var x = /\1/; According to 15.10.2.11, the RegExp snippet above should throw something as there aren't any capturing parenthesis within the RegExp, yet one is referenced. Just now noticed that step 4 of 15.10.2.9 is more precise and shows a SyntaxError gets thrown. Isn't the s

I18N API status update

Hi all, Below is the summary of changes we made on I18N API at the last face-to-face meeting along with the list of open issues to discuss. The summary and the list were prepared by Nebojsa Ciric (c...@google.com). The full API is available at http://wiki.ecmascript.org/

Re: \u0085 whitespace or a random unicode character by ES5?

On Jul 6, 2011, at 3:09 PM, Dave Fugate wrote: > Hi Allen, this is a case where Canary and IE9 agree that \u0085 is whitespace > or a line terminator as far as String.prototype.trim is concerned, but other > browsers do not. I’ll file a spec bug to clarify the text as there seems to > be conf

Re: Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

So, a next step is to look at this in combination with other Harmony proposals. In particular, the object literal extensions. There is one pretty obvious ambiguity introduced by the methods property shorthand. Keep mind that property names are permitted to be keywords. So let ambig1 = {func

RE: \u0085 whitespace or a random unicode character by ES5?

Hi Allen, this is a case where Canary and IE9 agree that \u0085 is whitespace or a line terminator as far as String.prototype.trim is concerned, but other browsers do not. I'll file a spec bug to clarify the text as there seems to be confusion on the Web about this one (e.g., do a search on "EC

Re: Date.prototype mutable internal properties

On Wed, Jul 6, 2011 at 12:06 PM, Allen Wirfs-Brock wrote: > Would a better solution to simply say that Object.freeze also freeze the > values of any internal properties. If there are exceptions we can > explicitly identify them for the specific built-in objects. This seems like > a better solutio

Re: JavaScript parser API

> Ah, sorry. Seems I got the wrong impression from the list archives - perhaps > only the interested parties participated in > those older threads. Thanks for clarifying. I think you're looking for a thumbs-up/thumbs-down answer from TC39, when we haven't really discussed it that much. We've exp

Re: JavaScript parser API

>>> - it is biased towards evaluation, which is a hindrance for other >>> uses (such as faithful unparsing, for program transformations); >> >> It's just a reflection of the built-in SpiderMonkey parser, which was >> designed for the sole purpose of evaluation. I didn't reimplement a >> new

Re: JavaScript parser API

I don't think we have any consensus within TC39 WRT whether such an API should be part of some future version Ecma-262. Personally, this sounds like library functionality that in the future might manifest as a module. I think we need to draw a line at adding very many more such libraries to

Re: JavaScript parser API

On Jul 6, 2011, at 12:55 PM, Oliver Hunt wrote: > I have a vague recollection that the SM parser strips out some characters > prior to > parsing (brendan?) Nothing is stripped other than space (including comments). > and generates bytecode into the ast (though based on dherman's > comments may

Re: JavaScript parser API

>> This is all the stuff that will almost certainly require separate >> implementations from the engine's core parser. And maybe >> that's fine. In my case, I wanted to implement a reflection of >> our existing parser, because it's guaranteed to track the >> behavior of SpiderMonkey's parser. > >

Re: JavaScript parser API

- it is slightly easier to manipulate than an Array-based AST, but More than slightly, IMO. Ok. Though destructuring closes some of the gap. lack of pattern matching fall-through (alternative patterns for destructuring) still hurts, and the selectors are lengthy, which ham

Re: Date.prototype mutable internal properties

Would a better solution to simply say that Object.freeze also freeze the values of any internal properties. If there are exceptions we can explicitly identify them for the specific built-in objects. This seems like a better solution then changing a lot of built-in properties to being accessors.

Re: \u0085 whitespace or a random unicode character by ES5?

On Jul 6, 2011, at 11:09 AM, Dave Fugate wrote: > > > -Original Message- > From: Peter van der Zee [mailto:e...@qfox.nl] > Sent: Wednesday, July 06, 2011 10:57 AM > To: Dave Fugate > Cc: es-discuss@mozilla.org > Subject: Re: \u0085 whitespace or a random unicode character by ES5? > >

Type of property names, as seen by proxy traps

While putting together some test cases for Object.keys, I wondered: is it intended that property names are always passed to traps as strings? It seems like a reasonable assumption, but is not currently the case everywhere (e.g. the default implementation for `keys' can violate this assumption when

RE: \u0085 whitespace or a random unicode character by ES5?

-Original Message- From: Peter van der Zee [mailto:e...@qfox.nl] Sent: Wednesday, July 06, 2011 10:57 AM To: Dave Fugate Cc: es-discuss@mozilla.org Subject: Re: \u0085 whitespace or a random unicode character by ES5? On Wed, Jul 6, 2011 at 7:38 PM, Dave Fugate wrote: > Several test262

Re: JavaScript parser API

On Jul 6, 2011, at 10:02 AM, Claus Reinke wrote: >>> the AST API strawman .. >> It hasn't really been championed so far. I was concentrating on >> other proposals for ES.next. > > So it was just timing, not behind-the-scenes disagreements. Ok. I don't think we have any consensus within TC39 WRT

Re: \u0085 whitespace or a random unicode character by ES5?

On Wed, Jul 6, 2011 at 7:38 PM, Dave Fugate wrote: > Several test262 test cases operate on the assumption ‘\u0085’, aka Next > Line, is considered a whitespace character and I’d like to get some > clarification on whether it really is or not as-per ES5.1. > > Table 3 of ES5, Line Terminator Charac

\u0085 whitespace or a random unicode character by ES5?

Several test262 test cases operate on the assumption '\u0085', aka Next Line, is considered a whitespace character and I'd like to get some clarification on whether it really is or not as-per ES5.1. Table 3 of ES5, Line Terminator Characters, does not call out \u0085 as being a valid line termi

Re: JavaScript parser API

On Jul 5, 2011, at 10:45 PM, Brendan Eich wrote: > On Jul 5, 2011, at 10:35 PM, Brendan Eich wrote: > >> On Jul 5, 2011, at 9:00 PM, David Herman wrote: >> >>> Mainstream production JS engines have moved away from parser generators. >> >> Right, indeed most (all but JavaScriptCore, IINM) never

Re: JavaScript parser API

On Jul 5, 2011, at 10:45 PM, Brendan Eich wrote: > On Jul 5, 2011, at 10:35 PM, Brendan Eich wrote: > >> On Jul 5, 2011, at 9:00 PM, David Herman wrote: >> >>> Mainstream production JS engines have moved away from parser generators. >> >> Right, indeed most (all but JavaScriptCore, IINM) never

Re: JavaScript parser API

the AST API strawman .. It hasn't really been championed so far. I was concentrating on other proposals for ES.next. So it was just timing, not behind-the-scenes disagreements. Ok. - it does not support generic traversals, so it definitely needs a pre-implemented traversal, sorting ou

Re: Minor type confusion in proxies proposal?

On 3 July 2011 13:29, Tom Van Cutsem wrote: > Comments? Looks good to me. I agree with Mark's comment that it should do a (shallow) copy of the attributes object, though. I guess the obvious point would be in Object.defineProperty, before passing it to DefineProxyProperty. /Andreas > 2011/7/2

Re: [Harmony proxies] Non-configurable properties: fixed properties VS trap all with invariants enforcement

That's why it would be better if the behavior of FixedHandler could become part of the built-in behavior of proxies. One issue that requires some thought is whether the FixedHandler could ever garbage collect fixed properties. I don't think that is possible, and that would compromise proxy abstrac