Re: Proposal: Property Accessor Function Shorthand

On 11/24/19 9:17 PM, Bob Myers wrote: FWIW, the syntax `.propName` does appear to be syntactically unambiguous. It conflicts with contextual keywords such as `new . target`. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org

Re: Modulo Operator %%

On 8/13/19 8:32 PM, Michael Haufe wrote: On 8/13/19 7:27 AM, Michael Haufe wrote: I would prefer the syntax be ‘a mod b’ consistent with my wishlist item: On 8/13/19 9:12 PM, Waldemar Horwat wrote: This can bring up various syntactic troubles. What does the following do? let mod +3

Re: Modulo Operator %%

On 8/13/19 7:27 AM, Michael Haufe wrote: I would prefer the syntax be ‘a mod b’ consistent with my wishlist item: This can bring up various syntactic troubles. What does the following do? let mod +3 Is it calling the mod operator on the variable named "let" and +3? Or is it defining a

Re: Removing the space in `a+ +b`?

On 6/28/19 8:41 AM, Isiah Meadows wrote: Currently, the production `a+ +b` requires a space to disambiguate it from the increment operator. However, `a++b` is not itself valid, as the postfix increment cannot be immediately followed by a bare identifier on the same line, nor can a prefix

Re: Proposal: Static Typing

On 3/23/19 1:34 PM, IdkGoodName Vilius wrote: This is a proposal for static typing. Here is the github repository link: https://github.com/CreatorVilius/Proposal-Static-Typing I think it would be great thing in JS. We intentionally reserved syntax so that something like that would be possible

Re: Proposal: switch statement multiple

On 02/15/2019 08:02 PM, Juan Pablo Garcia wrote: I think it would be great if the switch statement allows multiple argument Example Switch(a,b) Case: 1,true Case: 1,false Case: 2,true You need braces for the switch statement, and the colon goes after the expression; I assume you meant

Re: NumberFormat maxSignificantDigits Limit

There is precedence for using numbers around 20 for significant digit cutoffs in the spec. For example, if you look at how number tokens are parsed in the spec (§11.8.3.1), the implementation has the option to ignore significant digits after the 20th. That's not a bug; we did that

Re: New Proposal: Placeholder syntax

On 11/28/2018 10:17 AM, Andrew Kaiser wrote: Hi all, I have created a short proposal to introduce syntactic sugar for anonymous functions in a 'scala-like' manner, linked here https://github.com/andykais/proposal-placeholder-syntax. I am hoping to hear feedback on whether or not this is

Re: arrow function syntax simplified

On 10/25/2018 04:04 PM, manuelbarzi wrote: The committee has been swamped with numerous such syntax proposals.  While any single one may be reasonable in isolation, each one adds significant complexity to the language, and the sum of them is too great (plus multiple proposals try to grab

Re: Expectations around line ending behavior for U+2028 and U+2029

On 10/25/2018 09:24 AM, Logan Smyth wrote: Yeah, /LineTerminatorSequence/ is definitely the canonical definition of line numbers in JS at the moment. As we explore https://github.com/tc39/proposal-error-stacks, it would be good to clearly specify how a line number is computed from the

Re: arrow function syntax simplified

On 10/25/2018 07:55 AM, manuelbarzi wrote: not focussing on aesthetics, but on reduce of bureaucracy, which not by coincidence it's something fat-arrow functions already provide. The committee has been swamped with numerous such syntax proposals. While any single one may be reasonable in

Re: return =

On 09/03/2018 11:32 AM, Isiah Meadows wrote: There is literally only one language I've seen that has anything like this, and it's Verilog, a hardware description language. (It's also of questionable utility, and it's restricted to just simulator-only constructs.) That's not an endorsement, more

Re: Class data member declarations proposal idea

See this proposal, currently at stage 3: https://github.com/tc39/proposal-class-fields Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: !Re: proposal: Object Members

On 08/03/2018 08:30 PM, Bob Myers wrote: > `private`, `protected`, `class`, and a few other such keywords have all been part of ES since long be for the TC39 board got their hands on it. They hadn't been implemented, but they were all a very real part of ES. Whoa. Is that just misinformed or

Re: !Re: proposal: Object Members

On 08/03/2018 02:37 PM, Tab Atkins Jr. wrote: Yes, they were reserved because they were the Java reserved keywords, with the intention that we might add more Java features later in the langauge's evolution. That has no bearing on their use today. That's exactly what we did. In the early days

Re: !Re: proposal: Object Members

On 07/29/2018 04:37 PM, Isiah Meadows wrote: BTW, I came up with an alternate proposal for privacy altogether: https://github.com/tc39/proposal-class-fields/issues/115 TL;DR: private symbols that proxies can't see and that can't be enumerated. Aside from syntax, the main semantic difference I

Re: proposal: Object Members

On 07/26/2018 01:55 PM, Ranando King wrote: I've just finished updating my proposal with an [Existing proposals](https://github.com/rdking/proposal-object-members/blob/master/README.md#existing-proposals) section that lists the major differences. Reading the proposal, I'm not yet sure what

Re: JSON support for BigInt in Chrome/V8

On 07/17/2018 04:27 AM, Andrea Giammarchi wrote: actually, never mind ... but I find it hilarious that  BigInt('55501') works but  BigInt('55501n') doesn't ^_^;; That's no different from how other built-in types work.

Re: Proposal: Pilot-Wave -based execution flow

Looks like the process of picking random keywords from one of the interpretations of quantum mechanics and stringing them into nonsensical phrases. See also Cuil Theory. Waldemar On 05/12/2018 10:52 AM, Michael Luder-Rosefield wrote: can I be the first to say: what On Sat, 12 May

Re: EcmaScript Proposal – Private methods and fields proposals.

On 04/17/2018 05:31 PM, Sultan wrote: Do you limit classes to creating only the private fields declared in the class, or can they create arbitrarily named ones? Yes, just as you could write arbitrary named fields with the mentioned WeakMap approach, for example – [...] private[key] = value

Re: EcmaScript Proposal – Private methods and fields proposals.

On 04/17/2018 02:26 PM, Sultan wrote: In the transpilation you created the field using "registry.set(this, {id: 0})" in the constructor.  If you then claim that any write to the field can also create it, then you get the hijacking behavior which you wrote doesn't happen. The difference

Re: EcmaScript Proposal – Private methods and fields proposals.

On 04/17/2018 01:50 PM, Sultan wrote: >That would contradict your previous answer to the hijacking question. Can you point out the contradiction? The private field is still being written to by the providing class. In the transpilation you created the field using registry.set(this, {id:

Re: EcmaScript Proposal – Private methods and fields proposals.

On 04/16/2018 05:47 PM, Sultan wrote: >An instance has a fixed set of private fields which get created at object creation time. The implications of this alternative does not necessarily limit the creation of private fields to creation time, for example writing to a private field in the

Re: EcmaScript Proposal – Private methods and fields proposals.

On 04/13/2018 09:41 PM, Sultan wrote: >Writing your private field to an object that's not an instance of your class. >and then invoking the above write method with a this value that's not an instance of A, such as a proxy. Given: class A {   private id = 0;   private method(value) {    

Re: EcmaScript Proposal – Private methods and fields proposals.

On 04/13/2018 01:38 AM, Sultan wrote: The proposal is an explainer with regards to an alternative sigil-less syntax to back private fields/methods. What does private(this)[property] do? "private(this)[property]" and alternatively "private[property]" or "private.property" all invoke access

Re: EcmaScript Proposal – Private methods and fields proposals.

I read that proposal but don't understand what the proposal actually is. At this point it's a bit of syntax with no semantics behind it. What does private(this)[property] do? How do private fields come into existence? How do you prevent them from being forged or stuck onto unrelated

Re: Proposal: if variable initialization

On 03/22/2018 11:21 PM, Naveen Chawla wrote: I'm still not seeing a compelling case for not allowing `const` / `let` declarations to be evaluated as expressions. Or I've missed it. Yes, I think there is a compelling case for not allowing `const` / `let` declarations to be evaluated as

Re: try/catch/else

On 02/08/2018 06:50, Alan Plum wrote: I realise there is some ambiguity in using the else keyword for this (though I can't think of a meaningful opposite of "catch" either). Indeed. You can't use 'else' without breaking existing behavior. For example: if (foo) try {...} catch (e) {...}

Re: Arrow function followed by divide or syntax error?

x=x=>{}/alert(1)/+alert(2)// is a syntax error. We deliberately specified it that way in the standard for the precedence reasons stated earlier in the thread. Brian Terlson is filing a bug as we speak. Waldemar ___ es-discuss mailing list

Re: LR(1) grammar/parser and lookahead-restrictions

On 02/07/2017 06:39, Michael Dyck wrote: On 17-02-06 07:32 PM, Waldemar Horwat wrote: On 02/04/2017 07:20, Michael Dyck wrote: On 17-02-03 05:32 PM, Waldemar Horwat wrote: On 02/03/2017 08:17, Michael Dyck wrote: On 17-02-02 06:23 PM, Waldemar Horwat wrote: Lookahead restrictions fit very

Re: LR(1) grammar/parser and lookahead-restrictions

On 02/04/2017 07:20, Michael Dyck wrote: On 17-02-03 05:32 PM, Waldemar Horwat wrote: On 02/03/2017 08:17, Michael Dyck wrote: On 17-02-02 06:23 PM, Waldemar Horwat wrote: Lookahead restrictions fit very well into an LR(1) engine Again: Great, but how? E.g., do you pre-process the grammar

Re: LR(1) grammar/parser and lookahead-restrictions

On 02/03/2017 08:17, Michael Dyck wrote: On 17-02-02 06:23 PM, Waldemar Horwat wrote: Lookahead restrictions fit very well into an LR(1) engine Again: Great, but how? E.g., do you pre-process the grammar, modify the construction of the automaton, and/or modify the operation of the parser

Re: LR(1) grammar/parser and lookahead-restrictions

On 02/02/2017 15:56, Dmitry Soshnikov wrote: On Thu, Feb 2, 2017 at 3:23 PM, Waldemar Horwat <walde...@google.com <mailto:walde...@google.com>> wrote: On 02/01/2017 10:25, Dmitry Soshnikov wrote: As mentioned, Cover grammar is usually the process of the grammar d

Re: LR(1) grammar/parser and lookahead-restrictions

On 02/01/2017 10:25, Dmitry Soshnikov wrote: As mentioned, Cover grammar is usually the process of the grammar design itself (as in ES6 spec itself). I'm not aware of automatic transformations for this (if you find any please let me know). Cover grammars are an ugly hack that we had to add

Re: LR(1) grammar/parser and lookahead-restrictions

On 01/11/2017 10:28, Michael Dyck wrote: In the past, it has been said (usually by Brendan Eich) that TC39 intends that the ECMAScript grammar be LR(1). Is that still the case? (I'm not so much asking about the "1", but more about the "LR".) If so, I'm wondering how lookahead-restrictions

Re: stable sort proposal

On 03/18/2016 11:10, Tab Atkins Jr. wrote: If you're planning on pessimistically assuming that legacy implementations use an unstable sort for Array#sort(), then testing for the presence of Array#fastSort() (and assuming that when it appears the Array#sort is stable) is exactly as useful as

Re: Optional Chaining (aka Existential Operator, Null Propagation)

On 02/03/2016 11:56, John Lenz wrote: Can you reference something as to why the more obvious operators are problematic? ?. ?[] ?() ?: Some of these have problems. For example, a?[]:b is already valid ECMAScript syntax and does something else. There is an analogous but subtler problem for

Re: JavaScript Language feature Idea

On 01/25/2016 12:00, Andrea Giammarchi wrote: `Array.prototype.nth(n=0)` looks great indeed, +1 here About the Symbol ... ugly as hell also we need to write even more and it doesn't scale as utility compared to .nth ```js a[Symbol.last] a[a.length-1] ``` I fail to see the point of this,

Re: Backward running version look-behinds

On 12/11/2015 13:16, Nozomu Katō wrote: I wonder if the person who wrote the spec for RegExp is on this list. I would like to ask one question: Was there any reason why the following steps were defined in the present order: 21.2.2.4 Alternative The production Alternative :: Alternative Term

Re: Are there any 64-bit number proposals under consideration?

There have been proposals for 64-bit integers in TC39 for the last 15 years. All of them so far have gotten bogged down by one of: - extending the scope of the proposal to include value types, general operator overloading, etc., after which someone eventually objects to something or it

Re: Existential Operator / Null Propagation Operator

On 10/29/2015 12:19, Laurentiu Macovei wrote: `foo?.bar` and `foo?['bar']` syntax would work too. No. It would break existing code: x = foo?.3:.5; x = foo?[a]:[b]; On the other hand, turning .. into a token should be fine. Waldemar

Re: Existential Operator / Null Propagation Operator

On 10/29/2015 14:20, Claude Pache wrote: Le 29 oct. 2015 à 19:32, Eli Perelman a écrit : 2 dots may be problematic when parsing numbers (yeah, I know it's probably not common, but it's still valid): 3..toString() Eli Perelman Treating `..` as one token would be a

Re: Why is no line break is needed in ArrowFunction?

On 10/21/2015 00:27, Eric Suen wrote: Try to write a parser for es6, is this the right place for question about syntax? There is no expression or statement start with =>, same goes to yield [no LineTerminator here] * AssignmentExpression ? yield [no LineTerminator here] *

Re: Curried functions

On 10/15/2015 12:58, Yongxu Ren wrote: Sorry I actually didn’t mean to use this for currying ``` const add = a => b => a + b; ``` This was directly copied from Mark's example, I was thinking about making the non-nested arrow functional. My idea is if you define ``` const add = (a,b) => a + b;

Re: Look-behind proposal in trouble

On 10/13/2015 02:18, Erik Corry wrote: Yes, that makes sense. This could be fixed by removing {n} loops from positive lookbehinds. Or by doing the .NET-style back-references immediately. I think it would be cleanest to do the full reverse-order matching (what I think you're calling

Re: Swift style syntax

On 10/13/2015 10:27, Isiah Meadows wrote: Steve, I have little problem with whatever ends up the case, as long as it's shorter than `(x, y) => x + y`. The current idea was inspired by Swift's `list.sort(>)` and `list.reduce(0, +)`. I second the concern with this being far too full of hazards

Re: Look-behind proposal in trouble

On 10/10/2015 03:48, Erik Corry wrote: On Sat, Oct 10, 2015 at 12:47 AM, Waldemar Horwat <walde...@google.com <mailto:walde...@google.com>> wrote: It's not a superset. Captures would match differently. Can you elaborate? How would they be different? If you have a ca

Re: Additional Math functions

On 10/01/2015 23:10, Sebastian Zartner wrote: While Math.sum() and Math.mean() currently don't exist, they can easily be polyfilled: See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce#Sum_all_the_values_of_an_array for summarizing the values of

Re: Additional Math functions

On 10/02/2015 13:30, Alexander Jones wrote: I really don't think I'd want a basic `Math.sum(a, b, c)` meaning anything other than `a + b + c`, i.e. `(a + b) + c`. We should all just come to terms with the fact that floating point addition is not associative. Or is there really some simple,

Re: Additional Math functions

? On Friday, 2 October 2015, Waldemar Horwat <walde...@google.com <mailto:walde...@google.com>> wrote: On 10/02/2015 13:30, Alexander Jones wrote: I really don't think I'd want a basic `Math.sum(a, b, c)` meaning anything other than `a + b + c`, i.e. `(a + b) + c`. We should a

Danger of cache timing attacks

I was asked to share my concerns about how bad this can be. Here's a paper demonstrating how one AWS virtual machine has been able to practically break 2048-bit RSA by snooping into a different virtual machine using the same kind of shared cache timing attack. These were both running on

Re: Exponentiation operator precedence

My preference is for 2, but I don't have objections to 4. Either works. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Will not make it to this week's meeting

I had a medical emergency (broken bones) soon after arriving in Portland and am flying back to the bay area today for surgery and treatment. I will unfortunately have to miss this week's TC39 meeting. Waldemar ___ es-discuss mailing list

Re: What do you think about a C# 6 like nameof() expression for JavaScript.

This would have interesting consequences if you run your code via a minifier. Should the minifier return a string with the old name or the new name? Waldemar ___ es-discuss mailing list es-discuss@mozilla.org

Re: Exponentiation operator precedence

On 08/27/2015 11:58, Alexander Jones wrote: Ethan is making my point far better than I did, and I agree completely about the issue of unary operators visually appearing more tightly bound than binary operators. At this point it seems fair to at least acknowledge the prospect of significant

Re: Directed rounding

On 08/26/2015 13:12, C. Scott Ananian wrote: I think the better idea would be related to value types (http://www.slideshare.net/BrendanEich/value-objects2) which brendan is working on for ES7. I fuzzily recall rounding modes being used as an example in one of these slide decks, perhaps I am

Re: Exponentiation operator precedence

On 08/26/2015 09:09, Mark S. Miller wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either answer will

Re: Exponentiation operator precedence

On 08/26/2015 15:08, Mark S. Miller wrote: The force of that precedent is indeed what my objection is. The yield counter-example is interesting, but yield is an identifier not an operator symbol, and so does not as clearly fall within or shape operator expectations. If someone explains a

Re: Exponentiation operator precedence

On 08/25/2015 09:38, Claude Pache wrote: I think the following grammar could work. Replace the current (ES2015) PostfixExpression production with: ``` IncrementExpression: LeftHandSideExpression LeftHandSideExpression [no LineTerminator here] ++ LeftHandSideExpression [no

Re: Exponentiation operator precedence

On 08/24/2015 17:24, Jason Orendorff wrote: On Mon, Aug 24, 2015 at 5:45 PM, Waldemar Horwat walde...@google.com wrote: Let's not. As I said at the last meeting, making ** bind tighter than unary operators would break x**-2. And making it sometimes tighter and sometimes looser would be too

Re: Generalize do-expressions to statements in general?

On 07/16/2015 13:35, Herby Vojčík wrote: Mark S. Miller wrote: I echo this. E is a dynamic language with many similarities with JS, including a similarly C-like syntax. In E I use everything-is-a-pattern-or-expression all the time. When I first moved to JS I missed it. Now that I am used to

Re: typed objects and value types

On 04/02/2014 07:32 AM, Niko Matsakis wrote: I just wanted to let people on es-discuss know about two of my recent blog posts concerning typed objects. The first is a kind of status report: http://smallcultfollowing.com/babysteps/blog/2014/04/01/typed-objects-status-report/ and the second

Re: if-scoped let

On 12/03/2013 05:30 PM, Mark S. Miller wrote: What's ^^ ? a^^b would essentially be the same as !a!=!b except that it would return the actual truthy value if it returns true. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org

Re: Generators Grammar and Yield

On 11/25/2013 04:48 PM, Brendan Eich wrote: Brendan Eich wrote: Kevin Smith wrote: This makes for wtfjs additions, but they all seem non-wtf on reflection (or did to us when Waldemar threw them up on a whiteboard last week). By non-wtf, I mean anyone who groks that yield is

Re: Generator Arrow Functions

On 11/26/2013 02:28 PM, Claude Pache wrote: From the thread [1], I guess that parsing correctly the following thing would be obnoxious (at best)? (a = yield/b/g) =* {} —Claude Indeed. And you can make even more obnoxious parses of the hypothetical combination of =*, default

Re: Generator Arrow Functions

On 11/26/2013 03:00 PM, André Bargull wrote: On 11/26/2013 02:28 PM, Claude Pache wrote: / From the thread [1], I guess that parsing correctly the following thing would be obnoxious (at best)? // // (a = yield/b/g) =* {} // // —Claude / Indeed. And you can make even more obnoxious

Re: Generators Grammar and Yield

On 11/25/2013 02:03 PM, Kevin Smith wrote: Apologies for this remedial question, but I find the new grammar parameterized around [Yield] to be confusing. If I understand correctly, this is to allow yield within non-strict generators. If that's correct, then why are non-strict generators a

Re: Add regular expressions lookbehind

No one has yet submitted a well-defined proposal for lookbehinds on the table. Lookbehinds are difficult to translate into the language used by the spec and get quite fuzzy when the order of evaluation of parts of the regexp matters, which is what happens if capturing parentheses are

Re: Comments on Sept Meeting Notes

On 09/26/2013 04:22 PM, Yehuda Katz wrote: On Thu, Sep 26, 2013 at 4:20 PM, Allen Wirfs-Brock al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote: On Sep 26, 2013, at 4:12 PM, Brandon Benvie wrote: On 9/26/2013 4:09 PM, Allen Wirfs-Brock wrote: The newness was using

Re: Sept 17, 2013 TC39 Meeting Notes

On 09/24/2013 06:41 PM, Rick Waldron wrote: On Tue, Sep 24, 2013 at 7:12 PM, Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com wrote: Rick Waldron wrote: - Normalize CR, LF, and CRLF to LF [WH: Is this consensus recorded correctly? I understood the consensus

Re: Sept 17, 2013 TC39 Meeting Notes

On 09/24/2013 05:32 PM, Allen Wirfs-Brock wrote: On Sep 24, 2013, at 4:12 PM, Brendan Eich wrote: Rick Waldron wrote: - Normalize CR, LF, and CRLF to LF [WH: Is this consensus recorded correctly? I understood the consensus to be normalizing all lexical grammar LineTerminatorSequences to

Re: [[Invoke]] and implicit method calls

On 09/11/2013 03:38 PM, Jason Orendorff wrote: On Wed, Sep 11, 2013 at 9:08 AM, Tom Van Cutsem tomvc...@gmail.com wrote: Currently the pattern for this is [[Get]]+[[Call]]. We cannot refactor to [[Has]] + [[Invoke]] in general, because [[Has]] will return true also for non-callable values. If

Re: Questions/issues regarding generators

On 03/14/2013 04:14 PM, Brendan Eich wrote: Andreas Rossberg wrote: On 14 March 2013 23:38, Brendan Eichbren...@mozilla.com wrote: Andreas Rossberg wrote: That leaves my original proposal not to have generator application return an iterator, but only an iterable. Under that proposal, your

Re: Pure functions in EcmaScript

On Wed, Nov 28, 2012 at 5:39 AM, Marius Gundersen gunder...@gmail.comwrote: On Wed, Nov 28, 2012 at 1:20 PM, Andreas Rossberg rossb...@google.comwrote: Second, due to the extremely impure nature of JavaScript, there aren't many useful pure functions you could even write. For example, your

Re: new function syntax and poison pill methods

On 10/26/2012 03:23 PM, Kevin Reid wrote: On Fri, Oct 26, 2012 at 3:13 PM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: I think the oddity I note is a consequence of the too loose paragraph in section 2: A conforming implementation of ECMAScript is permitted to

Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)

On 09/18/2012 09:47 AM, Brendan Eich wrote: 2. Tim Disney with help from Paul Stansifer (Mozilla grad student interns) have figured out how to implement a Reader (Scheme sense) for JS, which does not fully parse JS but nevertheless correctly disambiguates /-as-division-operator from

Whitelist WeakSet

On 09/24/2012 01:24 AM, David Bruant wrote: Le 24/09/2012 10:04, Tom Van Cutsem a écrit : 2012/9/24 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com Le 23/09/2012 22:04, Herby Vojčík a écrit : Hello, maybe I missed something, but how will you secure the whitelist

The joys of United flight 242

I went to SFO today to fly to Boston for tomorrow's ECMA TC39 meeting. The flight was listed as about a half hour late — no big deal. Got on the plane uneventfully. Noticed that one of the passengers had a service dog. Crew goes on the intercom and states that the flight will be delayed because

Re: minutes, TC39 meeting Tues 5/22/2012

Since you're speculating on my position, here it is: - Classes don't hang together unless we have agreement on some declarative way to specify properties, referred to as const classes in the meeting notes. - It's fine for that to not be the default, but we must have agreement on how to do it.

Re: March 29 meeting notes

On 03/29/2012 08:30 PM, Allen Wirfs-Brock wrote: I don't think the report on maximally minimal classes fully reflections the discussion: Maximally minimal classes: Alex and Allen initiated the discussion as a status up-date to TC-39.. We pointed out that this proposal had recently been

Re: March 28 meeting notes

On Wed, Mar 28, 2012 at 11:47 PM, Erik Corry erik.co...@gmail.com wrote: 2012/3/29 Waldemar Horwat walde...@google.com: Wild debate. Poll of who objects to which problem in the proposal: 1.  AWB, MM, AR, AR, LH, DC, WH, DH 2.  AWB, MM, AR, AR, LH, BE, DC, WH, DH 3.  AR, AR, LH, DC, BE 5

Re: March 28 meeting notes

For me it was a tradeoff. I prefer consistency. The treatment of 'this' was done TCP-style, so I'd have preferred for the other language constructs to also behave TCP-style. However, practical gotchas begin to form: - yield cannot be done TCP-style within the framework of what we're doing. - what

March 28 meeting notes

Here are my rough notes from today's meeting.     Waldemar - IPR discussion Intel changed their ECMAScript patent declaration to RANDZ. Now they wonder why no one else made a RANDZ declaration. Istvan described the history. Mozilla is also unhappy with the current state of affairs.  Even

Re: Nested Quasis

On 02/06/2012 06:49 PM, Mark S. Miller wrote: On Mon, Feb 6, 2012 at 3:26 PM, Waldemar Horwat walde...@google.com mailto:walde...@google.com wrote: On 02/03/2012 08:07 PM, Mark S. Miller wrote: On Fri, Feb 3, 2012 at 12:58 PM, Waldemar Horwat walde...@google.com mailto:walde

Re: Nested Quasis

On 02/07/2012 02:51 PM, Mark S. Miller wrote: On Tue, Feb 7, 2012 at 1:52 PM, Waldemar Horwat walde...@google.com mailto:walde...@google.com wrote: [...] That's going back to the previous approach of treating the whole quasi as a single token. This doesn't work because it's not possible

Re: Nested Quasis

On 02/03/2012 08:07 PM, Mark S. Miller wrote: On Fri, Feb 3, 2012 at 12:58 PM, Waldemar Horwat walde...@google.com mailto:walde...@google.com wrote: On 02/02/2012 06:27 PM, Waldemar Horwat wrote: [...] Note that this is more complex than just having the parser switch modes

Re: Nested Quasis

On 02/02/2012 06:27 PM, Waldemar Horwat wrote: On 02/02/2012 04:15 PM, Mark S. Miller wrote: On Thu, Feb 2, 2012 at 2:00 PM, Waldemar Horwat walde...@google.com mailto:walde...@google.com wrote: OK. This introduces yet another lexing context, in which all productions *except* QuasiMiddle

Re: Nested Quasis

On 02/02/2012 11:03 AM, Mark S. Miller wrote: On Thu, Feb 2, 2012 at 5:09 AM, Douglas Crockford doug...@crockford.com mailto:doug...@crockford.com wrote: On 11:59 AM, Waldemar Horwat wrote: On 02/01/2012 11:35 AM, Allen Wirfs-Brock wrote: Here's one which I couldn't

Re: Nested Quasis

OK. This introduces yet another lexing context, in which all productions *except* QuasiMiddle and QuasiEnd are disallowed, and white space and comment handling is funny. That works if the expressions must be one of the two forms: $id ${expr} Is that the exhaustive list, or are we looking at

Re: Nested Quasis

On 02/02/2012 04:15 PM, Mark S. Miller wrote: On Thu, Feb 2, 2012 at 2:00 PM, Waldemar Horwat walde...@google.com mailto:walde...@google.com wrote: OK. This introduces yet another lexing context, in which all productions *except* QuasiMiddle and QuasiEnd are disallowed, and white space

Re: Nested Quasis

On 01/31/2012 03:04 PM, Allen Wirfs-Brock wrote: On Jan 31, 2012, at 2:36 PM, Waldemar Horwat wrote: On 01/28/2012 02:54 PM, Erik Arvidsson wrote: Under the open issues for Quasi Literals, http://wiki.ecmascript.org/doku.php?id=harmony:quasis#nesting , the topic of nesting is brought up

Re: Nested Quasis

On 02/01/2012 11:35 AM, Allen Wirfs-Brock wrote: On Feb 1, 2012, at 11:28 AM, Waldemar Horwat wrote: On 01/31/2012 03:04 PM, Allen Wirfs-Brock wrote: On Jan 31, 2012, at 2:36 PM, Waldemar Horwat wrote: On 01/28/2012 02:54 PM, Erik Arvidsson wrote: Under the open issues for Quasi Literals

Re: Nested Quasis

On 01/28/2012 02:54 PM, Erik Arvidsson wrote: Under the open issues for Quasi Literals, http://wiki.ecmascript.org/doku.php?id=harmony:quasis#nesting , the topic of nesting is brought up. After implementing Quasi Literals in Traceur it is clear that supporting nested quasi literals is easier

Re: January 19 meeting notes

On 01/19/2012 10:51 PM, Jon Zeppieri wrote: On Thu, Jan 19, 2012 at 11:02 PM, Brendan Eichbren...@mozilla.org wrote: Yes kids, this means we are going with MarkM's lambda desugaring from: https://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html Is there a version of this

Jan 18 meeting notes

My rough notes from today's meeting. Waldemar -- DaveH: One JavaScript (Versioning debate) It's inevitable (and necessary) that ES6 will have some breaking changes around the edges. How to opt-in? DaveH's versioning proposal: A module block or file include is the only

Re: Nov 17 meeting notes

On 11/17/2011 10:03 PM, Dominic Cooney wrote: On Fri, Nov 18, 2011 at 9:40 AM, Waldemar Horwat walde...@google.com mailto:walde...@google.com wrote: Array destructuring and length: let [a, b, c, d, ... r] = {2: 3} | [1, 2] Obvious: a is 1; b is 2. What are c, d, and r? c

Re: Nov 16 meeting notes

On Thu, Nov 17, 2011 at 3:49 AM, Axel Rauschmayer a...@rauschma.de wrote: Given that Array already uses `length`, it seems like the obvious choice. length is my choice as well, for the same reason. It's not writable in Maps and Sets, so the concerns about the semantics of writing it don't

Re: Nov 16 meeting notes

On Thu, Nov 17, 2011 at 12:12 AM, Gavin Barraclough barraclo...@apple.com wrote: On Nov 16, 2011, at 5:19 PM, Waldemar Horwat wrote: Map/Set: Size property should be a getter property with no matching setter.  It's defined on the property. What is its name?  size, count, or length?  Decide

Nov 17 meeting notes

Array destructuring and length: let [a, b, c, d, ... r] = {2: 3} | [1, 2] Obvious: a is 1; b is 2. What are c, d, and r? c = 2. d = undefined. r = empty. Fixed property destructuring doesn't rely on length. Vararg r destructuring uses length. The semantics of length will match that of slice.

Re: The class operator: a bridge between object and function exemplers

On 11/14/2011 12:16 PM, Allen Wirfs-Brock wrote: /UnaryExpression/ : *class* /UnaryExpression/ ... The semantics are: 1. if /UnaryExpression/ is undefined or null, return the value of /UnaryExpression/. 2. Let /obj/ be ToObject(/UnaryExpression/) 3. Return the result of calling the [[Get]]

  1   2   3   >