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 https://mail

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 Is it

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 vari

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 opera

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 "c

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 intentional

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 inter

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 t

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 original

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 iso

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 l

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 o

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 it

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. Stri

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 2018,

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 between

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: 0}

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 const

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) {     r

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 of

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 objects

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 express

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) {...} else

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 es-discuss

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 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 design itself (as in ES6 spec

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 wh

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 (e.g

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 testi

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, othe

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 e

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 become

Re: Is \u006eew a valid Identifier?

On 11/09/2015 10:10, Isiah Meadows wrote: Is there a reason why escapes like that in the title shouldn't evaluate to keywords? To be honest, it's bad style, but I don't get how it would be breaking the Web. Yes. We did it for the same reason that 0xC1 0xA2 is not a valid UTF-8 encoding of '

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 breaking change, Exact

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: 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] * AssignmentExpres

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: 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/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 .NET-sty

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 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 capture inside a loop (cont

Re: Look-behind proposal in trouble

On 10/09/2015 15:07, Nozomu Katō wrote: Since there was a comment about Perl5 style vs .NET style when I first posted my proposal to es-discuss, I just wanted to explain about the background of my proposal. I proposed Perl5 compatible lookbehinds because I thought it was relatively simple to impl

Re: Additional Math functions

? On Friday, 2 October 2015, Waldemar Horwat 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 all just come to

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, O(n

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 an

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 unmod

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 es-discuss@m

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 https://mail.mozilla.org/listinfo/es-d

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 wh

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 c

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 surp

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/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 LineTer

Re: Exponentiation operator precedence

On 08/24/2015 17:24, Jason Orendorff wrote: On Mon, Aug 24, 2015 at 5:45 PM, Waldemar Horwat 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 confusing and le

Re: Exponentiation operator precedence

On 08/24/2015 10:08, Jason Orendorff wrote: In math, -x² is -(x²), not (-x)². But as proposed for JS, -x**2 is (-x)**2. PHP, Python, Haskell, and D side with the traditional algebraic notation, against JS. Here's PHP: $ php -r 'print(-2 ** 2);' -4 Python: >>> -2 ** 2 -4 H

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 th

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 detai

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 https://m

Re: Generators Grammar and Yield

On 12/02/2013 09:13 AM, Allen Wirfs-Brock wrote: Jason suggests keeping the token stream and backing up. Another alternative is remembering the source position of the start of the parameter list and reparsing when the ambiguity and strictness is resolved. Whether text, token, or AST based re

Re: if-scoped let

On 11/29/2013 08:29 AM, Nick Krempel wrote: Couldn't find anything on this in the archives, but is there a proposal for: if (let var = expr) { // var in scope } else { // var in scope } // var out of scope I frequently use the C++ equivalent of this. Haven't proposed it as part of the

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 obnox

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 para

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 rese

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 go

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 involved.

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 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 using string literals+

Re: Line Terminators (and others) normalization in template strings

On 09/26/2013 11:31 AM, Brendan Eich wrote: Anne van Kesteren September 26, 2013 5:41 AM What Tab meant is that within the platform only CR and CRLF are normalized to LF and no other code points. This is true for HTML as well. This thread is to sort out the LINE and P

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 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 to be normalizing al

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 LF.]

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 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 we believe these ar

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 Eich 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 example requires disam

Re: Pure functions in EcmaScript

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, beca

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 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 provide additional t

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 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 > itself? Mal

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 /-as-regex

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 th

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 ext

March 29 meeting notes

Rough notes from today's meeting. Waldemar --- ES 5.1 quirks in defining globals when the global object's prototype already contains a property with the same name: https://bugs.ecmascript.org/show_bug.cgi?id=78 Waldemar: What if the prototype contains a getter or setter? Doesn't matter fo

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

Re: March 28 meeting notes

On Wed, Mar 28, 2012 at 11:47 PM, Erik Corry wrote: > 2012/3/29 Waldemar Horwat : >> 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 &

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 thou

Re: Nested Quasis

On 02/07/2012 04:40 PM, Brendan Eich wrote: I like Erik's way, but it makes a strange loop from lexical to syntactic grammar. It all works, I believe. The loop is here: QuasiHole :: Identifier { Spacing* Expression Spacing* } Expression is a syntactic grammar non-terminal, yet here we are in

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

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 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 mailto:walde...@google.com> <mailto:walde..

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 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 for the treatment o

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 mailto:walde...@google.com>> wrote: OK. This introduces yet another lexing context, in which all productions *except* QuasiMiddle and QuasiE

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 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 and c

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 11:03 AM, Mark S. Miller wrote: On Thu, Feb 2, 2012 at 5:09 AM, Douglas Crockford 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 express in

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

  1   2   3   >