Re: ECMA-262: ElementList : ... AssignmentExpression? Wtf?

Expression is .comma expression so can't be used without fatal ambiguity: is [a,,b] [(a,b)] or [(a), (b)]? It's the latter by using AssignmentExpression. If it were PrimaryExpression, ever expression using a binary operator would need to be parenthesized. Is the "Dragon Book" still in print? Recom

Re: Re: FW: Removal of language features

On Wed, Jul 26, 2017 at 11:59 AM Michał Wadas wrote: > I know that's hard to remove features from the web. That's why I propose > *clear > and well defined *route to clean up language. > Instead of asserting in bold, why not answer the questions I posed in reply to your clear but incomplete pro

Re: FW: Removal of language features

ity-ridden living language. /be On Wed, Jul 26, 2017 at 3:06 PM Florian Bösch wrote: > On Wed, Jul 26, 2017 at 11:41 PM, Brendan Eich > wrote: >> >> Those languages forked and some modernized (I remember Fortran 77). Those >> are all quite a bit older than JS. I wou

Re: FW: Removal of language features

On Wed, Jul 26, 2017 at 12:14 PM Florian Bösch wrote: > On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder < > tj.crow...@farsightsoftware.com> wrote: >> >> keeping it alive and healthy beyond its browser-limited existence. >> > > Many languages (including Python and Perl) concluded that at some poin

Re: FW: Removal of language features

ntinue. It shall continue. /be On Wed, Jul 26, 2017 at 11:37 AM Florian Bösch wrote: > On Tue, Jul 25, 2017 at 11:50 PM, Brendan Eich > wrote: >> >> Core language changes are different in kind from sync touch events. It's >> very hard to plan to remove anything on a

Re: Re: FW: Removal of language features

Strict mode also made runtime-incompatible changes, e.g. arguments[i] not aliasing i'th formal parameter, which required two-way testing while strict mode adoption was nascent or partial (which of course many devs skipped). On Wed, Jul 26, 2017 at 9:53 AM Andreas Rossberg wrote: > The "ability t

Re: Re: FW: Removal of language features

One thing that may not be obvious: On Wed, Jul 26, 2017 at 8:52 AM Brendan Eich wrote: > I created JS in 1995. In 1996 I made a few incompatible changes to JS and > got away with it, but not in 1997. ES3 was done in 1999 based on de-facto > work in Netscape and IE that converged (most

Re: Re: FW: Removal of language features

On Wed, Jul 26, 2017 at 4:44 AM Michał Wadas wrote: > Simple idea: > >- Add new Annex to language. >- Define operation EmitDeprecationWarning(code) - implementations MAY >show deprecation warning in implementation dependent way (it can depend on >runtime flag, dev tools, not minif

Re: Re: FW: Removal of language features

Hi Andreas, is this the best link to the Strong Mode post-mortem? https://groups.google.com/d/msg/strengthen-js/ojj3TDxbHpQ/5ENNAiUzEgAJ /be On Wed, Jul 26, 2017 at 2:56 AM Andreas Rossberg wrote: > As for the reoccurring assumption that deprecation would help simplifying > JavaScript implemen

Re: FW: Removal of language features

This thread makes me want to unsubscribe from es-discuss. I think I recreated the list. :-( Please read https://esdiscuss.org/topic/no-more-modes and https://esdiscuss.org/topic/use-es6-any-plans-for-such-a-mode#content-2. "Don't break the web" is not some vague high-minded notion of TC39's. It's

Re: Existential Operator / Null Propagation Operator

You need to be very careful hacking around in an ad-hoc parser. It's easy to diverge from the formal (and verified) grammar by accident. Ambiguous grammars with ad-hoc disambiguation rules codified only by your parser's source code are bad business. Voice of experience here. /be On Sat, May 21, 2

Re: monadic extension to do-notation

We'll get it on the next TC39 meeting's agenda. /be On Mon, Feb 22, 2016 at 5:28 PM Alan Johnson wrote: > If this is done, please go with `async do { … await … }`. May as well > reuse existing syntax as much as possible. As mentioned, `<-` is > problematic both from the standpoint of conflict w

Re: monadic extension to do-notation

And draft ES6 tried for monadic, but compatibility with Promises libraries (more than "convenience") prevailed. /be On Sun, Feb 7, 2016 at 11:35 AM Raphael Mu wrote: > In theory it's possible, but Promise.resolve automatically joins Promises > for the sake of ergonomics. > > On Sun, Feb 7, 2016

Re: monadic extension to do-notation

+1 to experience report from nodent, and +many to futures or eventual values. We've discussed before in terms of value types, value proxies, "become". See, e.g. https://twitter.com/brendaneich/status/585858406742786048 Also: Monadic for sure. Too late for promises. Sometimes you end up taking two

Re: Paren-free heads strawman

ing hazard is intimately tied to the infinite look-ahead > problem. Teaching a parser to handle the latter case or examples like `if > (x) (y) -z {}` correctly is gonna be all but easy. Either backtracking or > terrifying grammar refactorings would be needed. > > On 1 February 2016 at 18:46,

Re: Paren-free heads strawman

On Mon, Feb 1, 2016 at 8:02 AM kdex wrote: > [Douglas Crockford](https://www.youtube.com/watch?v=Nlqv6NtBXcA) and > [Brendan Eich](https://brendaneich.com/2010/11/paren-free/) seem > > to be in favor of making them optional; that's why the strawman exists. > > The strawman

Re: Paren-free heads strawman

C derived from B, virtually any language that derived from it >> adapted to this redundant syntax; nowadays, the parens exist solely for >> decoration. >> >> >> >> [Douglas Crockford](https://www.youtube.com/watch?v=Nlqv6NtBXcA) and >> [Brendan Eich](https

Re: Class member encapsulation

C++ has static inheritance and typing. this->A::x is 1 after B's constructor delegates to A's constructor, and this->B::x (a different field) is 2 once that field has been set in B::B. JS has (not yet, anyway) no field declarations, no namespacing akin to A::x and B::x, and so only one this.x to m

Re: HTML-like comment behavior inconsistent

Apologies for formatting problems -- I blame the Google Inbox web app. One typo fix, hope it's obvious already: On Sat, Jan 2, 2016 at 2:28 PM Brendan Eich wrote: > Thanks, Claude. > > It may be tempting to assume the standard specified something dumb, or due > to "leg

Re: HTML-like comment behavior inconsistent

Thanks, Claude. It may be tempting to assume the standard specified something dumb, or due to "legacy" mysteries. Not so. HTML5 fully specifies , which I created in 1995 at Netscape. I had no time for the src= attribute, and even if I had (I implemented that in 1996 for Netscape 3), but basis case

Re: [ small request - Javascript for javaing]

Thanks, Bob. Always good advice. Turns out I'm a list admin still. I will set mod bits if necessary. This has been necessary only a few times over the past ten years. Let's leave this thread to die, please. Happy New Year! /be On Fri, Jan 1, 2016 at 10:06 AM Bob Myers wrote: > Please don't fe

Re: Legitimate uses of IIFEs?

Definitely could have `async` block that's allowed to contain `await`. IIRC we have mooted that at TC39. /be On Mon, Dec 21, 2015 at 9:48 AM wrote: > Ok, I'm convinced :) > > Whether the solution is to invent new syntax or not is moot. It occurred > to me that 'async' could be used as a modifie

Re: Propose simpler string constant

Hi Rick, thanks to you and Mike for drafting. I will read and comment more when I have time, but I wanted to channel the Twitter-ghost of Dave Herman: "we should start from pattern matching and work our way from there into the kinds of datatypes we want to match on" I hear wycats and bterlson are

Re: Re: Propose simpler string constant

On Wed, Dec 16, 2015 at 9:41 AM Alican Çubukçuoğlu < alicancubukcuo...@gmail.com> wrote: > How are enums declared? > ```javascript > let myVar = 13; > enum myEnum = {Red, Green, Blue}; > No `=` between name and `{`. Enumerator scope is a good question. Clearly we do not want global scope. Rather

Re: es-discuss Digest, Vol 106, Issue 46

5:44 AM, Brendan Eich > wrote: > > `enum` has precedent -- C-like languages indeed use integers by default, > but > > see Rust for a generalized form: > https://doc.rust-lang.org/book/enums.html > > -- for a category-theory "sum" type and IMHO handily beats

Re: es-discuss Digest, Vol 106, Issue 46

`enum` has precedent -- C-like languages indeed use integers by default, but see Rust for a generalized form: https://doc.rust-lang.org/book/enums.html -- for a category-theory "sum" type and IMHO handily beats `sym` or `sum`. /be On Wed, Dec 16, 2015 at 8:13 AM Coroutines wrote: > On Wed, Dec

Re: Propose simpler string constant

What's wanted is `enum { APPLE, ORANGE, GRAPE }` instead. Turns out `enum` was one of four Java-ish future reserved words that IE actually reserved from the ancient days. So we could use it. Some half-formed talk of using it to define categorical sum types, and even value types -- i.e., allowing c

Re: Concise Method Binding

Your Person::greet example is canonically used to demonstrate dynamic |this|. How does it motivate the instance-bound method in class use-case? Perhaps show some example that justifies the method-per-instance overhead. /be On Wed, Nov 11, 2015 at 10:25 AM Bergi wrote: > Gilbert B Garza schrieb:

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

I did watchpoints in SpiderMonkey in 1997 IIRC, implemented as replacement accessors under the hood. ES5 and unfrozen ordinary objects allow self-hosting of watchpoints (ES6 weakmaps and symbols help but are not required). We can't standardize watchpoints for all objects, of course. /be On Thu,

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

You wrote 1. "pretend all object's are really just proxies to whatever their internal backing might be." 2. "without a baked in ability to intercede." 3. "What this does is give you something VERY close to a built in observable Model type on top of plain objects." These are not consistent state

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

On Thu, Nov 5, 2015 at 12:30 AM Romuald Quantin wrote: > What is the problem in accessing the keys with any code, which is the same > behaviour for any other object in javascript: String, Array, Object and so > on. The point is being able to do on a weak key so code can be processed > without bei

Re: Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

Read esdiscuss.org, use Google site: search, before complaining that you don't understand why something is not "enabled". Here's a link: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=site%3Aesdiscuss.org%20weak%20reference It's not hard to find the full history of t

Re: An update on Object.observe

> a lot of noise on this list Agreed (re: no one in particular). :-( Best to step back and study all of the stuff already in JS, before doubling down on reviving another withdrawn proposal. /be ___ es-discuss mailing list es-discuss@mozilla.org https:/

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

Ah yes, the Smalltalk "become:" message, something that inspired SpiderMonkey's "Brain Transplants" -- see the [1] footnote at https://brendaneich.com/2010/11/proxy-inception/, and of course the bugzilla link, which leads to this: <https://bugzilla.mozilla.org/user_p

Re: Exponentiation operator precedence

Because C (B, BCPL, Algol). Too late to change JS where people do tricks such as !-x. No win in risking compat break. /be On Fri, Sep 25, 2015 at 4:18 AM Herby Vojčík wrote: > > > Herby Vojčík wrote: > > > > > > Claude Pache wrote: > >> > >> I just wonder why it is important that unary binds tig

Re: Exponentiation operator precedence

way and getting it to stage 3 :-P.) /be On Thu, Sep 24, 2015 at 2:05 PM, Claude Pache wrote: > > Le 24 sept. 2015 à 22:20, Brendan Eich a écrit : > > Sez you! :-P > > Seriously, the problem you are dismissing implicitly (bad form :-/) is the > one we discussed yesterday, wh

Re: Exponentiation operator precedence

to parenthesize. That's the price of the typographic > shift and the precedence inversion that it suggests to many people. > > /be > > On Thu, Sep 24, 2015 at 11:16 AM, Mark S. Miller > wrote: > >> >> >> On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache

Re: Exponentiation operator precedence

ey'll have to parenthesize. That's the price of the typographic shift and the precedence inversion that it suggests to many people. /be On Thu, Sep 24, 2015 at 11:16 AM, Mark S. Miller wrote: > > > On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache > wrote: > >> >

Re: Exponentiation operator precedence

Even nicer: http://jsbin.com/baquqokujo I hate email. /be Brendan Eich wrote: Here's a nicely formatted jsbin version of my message: http://jsbin.com/bihilaveda Sorry about the mess, mail user agents (at least Postbox) and archive software do not like explicit indentation.

Re: Exponentiation operator precedence

Here's a nicely formatted jsbin version of my message: http://jsbin.com/bihilaveda Sorry about the mess, mail user agents (at least Postbox) and archive software do not like explicit indentation. /be ___ es-discuss mailing list es-discuss@mozilla

Re: Exponentiation operator precedence

[Apologies for resending, trying to fix formatting of grammar excerpts. /be] Quick update from TC39 yesterday where Rick and I presented the Stage 3 Exponentiation Operator proposal: http://rwaldron.github.io/exponentiation-operator/ The current spec, revised to match precedent from all known

Re: Exponentiation operator precedence

Quick update from TC39 yesterday where Rick and I presented the Stage 3 Exponentiation Operator proposal: http://rwaldron.github.io/exponentiation-operator/ The current spec, revised to match precedent from all known programming languages that have exponentiation operators, binds -x^y = -(x^

Re: Object id, hash, etc?

Tab Atkins Jr. wrote: Using a primitive string as a key can inadvertently leak the value for a long time, as the key might be interned and long-lived, far past the point when your code has dropped the intended references to it. Indeed. Strings do not have observable reference semantics at all

Re: Object id, hash, etc?

Michael McGlothlin wrote: I'm only seeing a couple comments there - was that all or am I missing something? Did you read the note about security? I think hashes as an overwritable method that returns a number is pretty standard and let's you combine member hashes with simple Bitwise ops. Co

Re: Object id, hash, etc?

For posterity: http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes http://wiki.ecmascript.org/doku.php?id=discussion:hashcodes (from ES4 daze, a long time ago.) /be Michael McGlothlin wrote: Is there a reason not to provide an object id and hash value as other languages often do? I fi

Re: Global lexical tier

Andreas Rossberg wrote: What I mean is that in a model with mutable scope (or worse, the global object) _declarations_ themselves become global effects. Later conflicts can affect all code that has been loaded _before_, e.g. by smashing over an existing binding. I get it, but this is just "th

Re: Global lexical tier

Allen Wirfs-Brock wrote: On Sep 2, 2015, at 4:58 PM, Brendan Eich wrote: > saam barati wrote: >> Thanks. Reading now. >> >> I'm clearly bad at email :/ > > Naw, this stuff is always harder to find than it should be. > > I was there, I just re-

Re: Global lexical tier

Andreas Rossberg wrote: On 3 September 2015 at 03:50, Brendan Eich <mailto:bren...@mozilla.org>> wrote: I don't remember you overcoming the counterarguments about async scripts and event handlers in async-generated/written markup twisting the nested scopes unexpected

Re: Global lexical tier

As you probably read (agreed, notes are strung out and not well-indexed), we considered that too. It fell to the objection that users certainly want const and class declarations from one script to be usable in subsequent scripts. For let, we didn't want to break symmetry with const and class at

Re: Global lexical tier

saam barati wrote: I think we've also hurt ourselves here with regards to considering alternate implementations by having some form of "const" being visible across multiple JS programs for a while now. This property of top-level const being visible across mutliple programs (script elements) h

Re: Global lexical tier

Andreas Rossberg wrote: On 3 September 2015 at 01:58, Brendan Eich <mailto:bren...@mozilla.org>> wrote: I was there, I just re-read and re-remembered. I do not agree with Allen that some tiny needle was uniquely threaded. Rather, an aesthetic preference for the new ES6 bind

Re: Global lexical tier

saam barati wrote: Thanks. Reading now. I'm clearly bad at email :/ Naw, this stuff is always harder to find than it should be. I was there, I just re-read and re-remembered. I do not agree with Allen that some tiny needle was uniquely threaded. Rather, an aesthetic preference for the new E

Re: Global lexical tier

We are in rapid-release hell/heaven. This means errata can be issued, and engines can implement the better resolution for those errata, compared to what the last major-version _de jure_ spec mandated. Why not? /be Adam Klein wrote: Note that this behavior in v8/Chrome is only about sloppy m

Re: Exponentiation operator precedence

Not to worry, the significant whitespace prospect was (I trust) a warding-off spell. Good of Waldemar to mention Fortress, too. JS, which as source is and will always be minified, indeed requires full-parsing minifiers, so one might naively still entertain the stated prospect. But it's a bad i

Re: Exponentiation operator precedence

Mark S. Miller wrote: but "yield" is an identifier not an operator symbol, and so does not as clearly fall within or shape operator expectations. delete typeof These are high-precedence, same level as unary +/- etc. Unlike yield, which is at assignment operator level. I'm simply questioning

Re: Exponentiation operator precedence

Yehuda Katz cited an acronym taught when he was a wee lad learning algebra: PEMDAS (Parentheses, Exponentiation, Multiplication/Dviistion, Addition/Subtraction). Who else learned this? There's nothing sacrosanct about binary precedence being generally lower than unary. Consider the property ac

Re: `null` and default arguments

See https://esdiscuss.org/topic/default-operator-strawman-rather-than#content-13 and surrounding thread. /be Isiah Meadows wrote: I know it's a little late for this, but what was the rationale of using only `undefined` instead of both that and `null` to denote omitted values for optional a

Re: UInt8ClampedArray Bitwise operators?

Caitlin Potter wrote: ES2015 already has element accessor overloading with proxies, right? > It's everything else that's missing. Proxies enforce invariants, which is problematic for this use case because it’s A) expensive, and B) also restricts you from “lying” about the actual properties w

Re: UInt8ClampedArray Bitwise operators?

Daniel Ehrenberg wrote: Uint8ClampedArray is more of a historical artifact than something you should actually aim to use. Uint8Array is probably what you'd want to get at as a basis for a user-level library. Thanks for posting this, Daniel. Just to be super-clear (and I was around when it was

Re: please add orEqual operator

Oops, sorry. You were punning with pattern-matching there ;-). Can this thread die? /be Tab Atkins Jr. wrote: On Mon, Aug 10, 2015 at 1:53 PM, Brendan Eich wrote: Please search for older proposals on ecmascript.org. You'd find http://wiki.ecmascript.org/doku.p

Re: please add orEqual operator

Please search for older proposals on ecmascript.org. You'd find http://wiki.ecmascript.org/doku.php?id=strawman:default_operator ES6 parameter default values took a look of wind out of this one's sails. /be myemailu...@gmail.com wrote: it could be used like this: if ( a == 1 ||= 2 ||=3 ||=5)

Re: please add x .= f()

Do not send "Please add" messages with two-line, half-baked sketches of extensions to the language. That's just injecting noise with very little signal. The "-1" you received will be the answer if pressed from everyone on TC39, I would bet real money. Syntax is expensive, adding it for little

Re: Please help with writing spec for async JSON APIs

Exactly! Incremental and async, i.e., streaming. XML quickly needed such APIs (https://en.wikipedia.org/wiki/Simple_API_for_XML, https://en.wikipedia.org/wiki/StAX). JSON's in the same boat. /be Bruno Jouhier wrote: A common use case is large JSON feeds: header + lots of entries + trailer

Re: Syntax shortcut for accessing properties on the current context ("this")

Matthew Robb wrote: does it seem reasonable though that if properties get initializers in the class body that they could be considered "in scope" to everything else defined in the class body? That's a big "if", but with the right *declarative*, binding-like syntax, that's plausibly valid infe

Re: Syntax shortcut for accessing properties on the current context ("this")

Michael McGlothlin wrote: I'd rather that prop just match the object the method is actually attached to, regardless of the context of 'this', before continuing searching the tree. Familiar as its done that way in many languages, You mean static (applied to types, including fields in objects) la

Re: Instance bound class methods

You're counting on the property assignment being moved into the constructor, where `this` is bound. In a class body in ES6 (without property assignment extension), especially in the top level where method defintiions go, `this` isn't obviously bound to the newly constructed instance. Ok, that

Re: Performance of iterator .next() as specified

Generators (in similar manner and for similar reasons as in PEP-380) can return a value via a `return` statement. This requires a pair {value, done}, you cannot do it with a sentinel such as your item (3). BTW at ECOOP in Prague this past week, I heard from folks (I forget whether it was Till

Re: Cross language discussion

Benjamin Gruenbaum wrote: An annual conference sounds like a great opportunity to discuss design goals of languages and long term goals - I am a much less ambitious man than you. I'm just thinking of small scope examples, to name 3 on top of my head: - The iteration protocol (PHP had a simil

Re: May 2015 Meeting Notes

Andreas Rossberg wrote: A seemingly predictable name is a rather bad idea, because it would be very brittle, e.g., depend on other libraries loaded, or even loading order. It's better to have clearly non-deterministic (e.g. gensym) than something that pretends to be deterministic but isn't in p

Re: function.sent beta equivalence?

Andreas Rossberg wrote: But it's a good question. Maybe it's an indication that we should not add function.sent? We talked about this at the last meeting, though maybe you weren't there (meeting notes header with people present and their 2 or 3LAs gets copied forward a lot!). It doesn't seem

Re: revive let blocks

Matthew Robb wrote: I feel like this would just get confused with object destructuring. Not just confused -- it is fatally ambiguous. I think do expressions are "go" for ES7 but they need re-championing, and implementation. I'll stir the pot. /be __

Re: function.sent beta equivalence?

Jason Orendorff wrote: My sense is that function.next s/.next/.sent/ is outside this relationship, and it shows as a bit of a wart every time you write abstract code about generators. Yes, agree there's a smell. We did not automate delegating function.sent for good reason, though. Is the

Re: function.sent beta equivalence?

Jason Orendorff wrote: What does "wrap" look like? It seems like it would be pretty involved. It might be the full, hideous, but write-once complexity of the desugaring of yield*, but now I'm seeing fragments and missing-uncited-text messages from Mark, and wondering whether I'm missing a re

Re: function.sent beta equivalence?

Hrm, the meeting notes don't quite capture it (https://github.com/tc39/tc39-notes/blob/bf5190257d22d1c700e203b28edc8d85ee3aadcc/es6/2015-05/may-27.md is one view; my fault for not editing after), but we have discussed passing function.sent into the sub-generator in the past. Ben Newman first ra

Re: Move es-discuss to discuss.webplatform.org?

Allen Wirfs-Brock wrote: Or perhaps ecaa could host. Ecma? HAHAHAHA! Ahem. Sorry. Judging from the IT outsourcing our people in Geneva do, I can only say: nope! Am I being unfair? Their Francs are as gold/green/orange/etc. (https://en.wikipedia.org/wiki/Banknotes_of_the_Swiss_franc) as any

Re: Move es-discuss to discuss.webplatform.org?

Axel Rauschmayer wrote: My biggest concern is that you can’t be selective in your consumption of es-discuss: It’s all or nothing (even if you only want to participate occasionally). The volume is daunting, esp. with a mobile device. Long ago we had USENET and NNTP to help avoid having to read

Re: Move es-discuss to discuss.webplatform.org?

Jonathan Kingston wrote: > (I don't think any such es-discuss replacement should be on webplatform.org , FWIW -- that crosses the W3C and Ecma streams.) Is that such an issue? I was thinking the larger exposure and closer working would be a bigger benefit than the mai

Re: Move es-discuss to discuss.webplatform.org?

Let's talk about this at July's TC39 meeting. Maybe we can have best of both worlds, thanks to Discourse. (I don't think any such es-discuss replacement should be on webplatform.org, FWIW -- that crosses the W3C and Ecma streams.) Having two es-dis{cuss,course} list-like things is not great. I

Re: Move es-discuss to discuss.webplatform.org?

Allen Wirfs-Brock wrote: On Jun 22, 2015, at 12:51 PM, C. Scott Ananian > wrote: It's not too surprising: it's the same reason why the ES6 spec was just published *on paper*, with the html version being explicitly flagged as non-normative. Actually the abov

Re: When macros will get in, will the core get slimmed in favour of macro-definitions?

Sure, we'd want that. And sweet.js can handle a lot (it handled classes, destructuring, and other ES6 features before they were implemented in popular engines). This may take a while. Best way to ensure this outcome: more people learning, using, and helping improve sweet.js. /be __

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

Good points, Mark. There are two better ways forward that I see: 1. Separate forms and make them compose well. Instead of let (x=y){z} and the grammatically unsound let (x=y)x*x from ES4, given let in ES6, and do expressions in ES7, declare victory and use `do { let x = y; z }`. 2. Sweet.js

Re: @@isConcatSpreadable

Herby Vojčík wrote: So when one actually _wants_ to concat (as, add elements of the iterable), it should stop using concat for that and must do something like var concatenated = first.slice(); concatenated.push(...second, ...third, ...fourth); Or use concat but wrap the parameter with [].

Re: {Spam?} Re: Language design

I think we can stick a fork in this thread, it's done. Let it memorialize some knowledge that seems in danger of being lost over time. Thanks, /be Wes Garland wrote: That root post ignored compatibility constraints that have been discussed to death over the years, and just glibly asserted th

Re: Language design

Edwin Reynoso wrote: Yes please edit it, you don't have to repost. BTW the only thing I can agree with is the `Object.is()` which to me seems like the only problem it solves is `Object.is(NaN, NaN)` now returns true You didn't agree with the root post (whose sender has had the "mod" flag set

Re: Look-behind proposal

I will do it if no one else steps up by 10pm tonight PDT. Thank you to Nozomu Katō for writing it up! /be Sebastian Zartner wrote: So the question is, how to recruit a TC39 member? Through this list? Is it possible to become a member as a private person? __

Re: Promise sub-class: super((resolve, reject) => this) ?

With best intentions I must say that you are overreacting. The subject-line code (h/t Mark Miller for pointing me at it!) in context of the superclass constructor uses `this` before `super` has returned. That's a no-no for pretty-good reason. If you have a better alternative design, we needed

Re: Existential Operator / Null Propagation Operator

Sam Ruby wrote: I think that the problem here isn't that it is ambiguous, it is that it isn't obvious. Fair point! Something that might be more obvious but requires an additional character: `orders.?[client.key].price`. That's not bad. The whole proposal may founder, though, on "grawlix" o

Re: Existential Operator / Null Propagation Operator

Sander Deryckere wrote: 2015-06-02 17:49 GMT+02:00 Brendan Eich <mailto:bren...@mozilla.org>>: Sander Deryckere wrote: For the prefix operator, it's unclear to me how you would do the following: Say you know `obj` is non-null, you want to test if it

Re: Existential Operator / Null Propagation Operator

Sander Deryckere wrote: For the prefix operator, it's unclear to me how you would do the following: Say you know `obj` is non-null, you want to test if it has a key `k1`, but if `k1` exists, you know it will also have a key `k2` a level deeper. With the suffix operator, this would be `obj[k1]?

Re: Maybe we need a reflect API to iterate over instance members

Alexander Jones wrote: Or since Proxy traps correspond 1-to-1 to the "internal methods" in the spec, the primary goal of the Reflect API was to expose the essential methods that make up Javascript's object model as defined by the spec. I like this definition. Is it written dow

Re: Maybe we need a reflect API to iterate over instance members

Domenic Denicola wrote: However, in the end, what you need to do to get something into the language is to prove that it's a common enough need that it's worth adding complexity to the spec and implementations. This thread is very far from doing that. A better start would be surveying open-sour

Re: import ModuleSpecifier

specify this aspect of the language makes no sense to this developer at least. On Sun, May 31, 2015 at 7:30 PM, Brendan Eich <mailto:bren...@mozilla.org>> wrote: Browsers in any semi-competitive market will agree on a standard. I don't see why that needs to be called into doubt

Re: import ModuleSpecifier

Browsers in any semi-competitive market will agree on a standard. I don't see why that needs to be called into doubt, even as part of a "hypothetical future" :-|. (Is there another kind? :-P) /be Domenic Denicola wrote: Yes, in theory. However, browsers are more likely to wait until there’s a

Re: 2 questions about ES6 module loaders

Glen wrote: PS. "from X import Y" syntax would have been useful in cases where IDEs provide auto-completion. I know it's too late for changes now. It has other advantages: Python-like for those who care; Y can be a long braced list or pattern, which goes better at the end. But too late, and

Re: Class decorators and async process

Alexandre Louis Marc Morgaut wrote: Sync is out of bounds in browsers, and for Node.js apart from require -- a rift indeed between the two embeddings. Just to be fair, Sync is still appreciated in some situations in JS like - in Dedicated Workers, Good point. Still not in specs but proposed

Re: why not just import new language into browser?

I would like to suggest that everyone let this thread die. It's way out of scope for es-discuss, and three kinds of bogus just considering the Subject: line. If anyone wants to chat about it, HN has regular recurring "why not blub?" and "why not bytecode" threads. /be (co-moderator with @awbjs

Re: Label statement moveable

Claude Pache wrote: Anyway, for rare cases not covered by `break label`, as you noted, proper tail call is a satisfactory way to spell `goto`: ``` ;(function foo() { // ... if (bar) return foo() // ... })() ``` +∞ /be ___ es

Re: Label statement moveable

I'm not sure what you mean by limited goto, but your example works since ES3 in JS. Underused part of the design: break from labeled block or if, no need for do-while(0) nonsense. /be Michał Wadas wrote: I'm not sure if limited "goto" should be really considered harmful. Dijkstra has written

Re: Class decorators and async process

Gray Zhang wrote: It’s OK, I just wait for |this.weapon| to resolve, but then my |hit| method becomes async, and everything based on |@inject| property should be async, which is not actually what I want. Async can be contaminating, yes. Sync is out of bounds in browsers, and for Node.js a

Re: Class decorators and async process

Gray Zhang wrote: Hi all: I’m wondering if there is any way to combine a class decorator and an async process together? A common case would be a generic IoC implementation: First, too many undefined terms and made-up syntax extensions just makes for confusion. Can you define "async proce

  1   2   3   4   5   6   7   8   9   10   >