Re: Array.prototype.values is not web compat (even with unscopables)

Just as a note - I think that if we learned anything in this regard it's that standards should guide and not dictate. It׳s rather impossible to break reasonable user level code and I don't think it's reasonable to expect developers to be fortune tellers :) (I like the idea though) On Oct

Re: async/await improvements

In my year long experience with large code bases using Bluebird promises which do unhandled rejection tracking - I haven't had a single false positive or false negative. Adding error handlers asynchronously is in practice extremely rare. On Nov 12, 2014, at 19:15, James Long

Re: Value Types shims/transpiler?

Correct, I mean value types (or objects) that have value semantics and support operator overloading. On Nov 19, 2014, at 06:31, Katelyn Gadd k...@luminance.org wrote: You don't mean typed objects, right? You mean value types, pass-by-value? -kg On 18 November 2014 02:36, Benjamin

Re: Removal of WeakMap/WeakSet clear

Never been a need? Why if you want to use objects as keys and not use reference equality? We've been over this. Here's a ref https://mail.mozilla.org/pipermail/es-discuss/2014-February/036389.html On Dec 8, 2014, at 23:46, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Dec 4, 2014 at

Re: about lightweight traits

Why does ES even need traits? The only aspect they can help with here is the type system we don't have yet. We have `Object.assign` that works fantastically for most classic trait use cases. On Feb 12, 2015, at 18:35, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Without going down

Fwd: about lightweight traits

Sorry, forgot to CC the list From: Benjamin Gruenbaum ing...@gmail.com Date: February 12, 2015 at 22:19:14 GMT+2 To: Domenic Denicola d...@domenic.me Subject: Re: about lightweight traits Those points are good, let me try to address them State - In other languages like C# and swift

Re: How to tell function and generator function apart?

Yes, don't make the distinction and instead run only promises - provide a function that takes a sequence and returns a promise over it. Not every iterable sequence is a sequence of async values. On Mar 3, 2015, at 22:54, Dean Landolt d...@deanlandolt.com wrote: One use case is for coroutine

RE: revive let blocks

From: Kyle Simpson get...@gmail.com To: es-discuss@mozilla.org es-discuss@mozilla.org Cc: Date: Thu, 18 Jun 2015 07:34:28 -0500 Subject: Re: revive let blocks (function (a, b, c) { }(2)) The main disadvantage of that style over the one I'm advocating for is that it visually separates the

Re: revive let blocks

Apart from complicating the engine and the grammar - what advantage does the second version have over the first one? Why do you prefer it to the first one? (Genuinely asking) I'm also not aware of any other languages that provide this (although that's not a huge issue). On Jun 18, 2015, at

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

I agree completely, and I fully apologize. Starting the thread this way was inappropriate, at least without some mitigating text which I did not think to add. I like the fact that we are all civil to each other here and try to keep the environment welcoming and friendly. Please no one take my

Re: RegExp.escape()

As a cross-cutting concern I'd like the feedback of more people on https://github.com/benjamingr/RegExp.escape/issues/29 Basically we've got to make a design choice of readable output vs. potentially safer output. ___ es-discuss mailing list

Re: Pick operator

Some comments: { p1 as x, p2 } # o // { x: o.p1, p2: o.p2 } Not sure why the `as` syntax since we already have `x : p1 ` syntax from destructuring. p # if o This is really complicated syntax, especially given `if` is not an expression. { a, b } @ [ 1, 2 ] // { a: 1, b: 2 } A second

Re: RegExp.escape()

Why is this a comment on the RegExp.escape discussion? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

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

First of all, brilliant post Mark. As a community, we need more of a shared sense of panic about the size that ES6 has already grown to. Ideally, that panic should increase, not decrease, with further growth from here as our size approaches the point of no return. As a community, we do - if you

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

and look up details. You know nothing Allen Wirfs-Brock (cit) On Thu, Jun 18, 2015 at 8:55 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote: On 18 June 2015 at 19:26, Benjamin Gruenbaum benjami...@gmail.com wrote: This is a mailing

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

discussion of new ideas that might help us write better programs. Just my 2p. On Thursday, June 18, 2015, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote: On 18 June 2015 at 19:26, Benjamin Gruenbaum benjami...@gmail.com wrote

Why are implementations allowed to extend the regular expressions syntax?

Quoting the specification at http://www.ecma-international.org/ecma-262/6.0/index.html#sec-literals-regular-expression-literals : An implementation may extend the ECMAScript Regular Expression grammar defined in 21.2.1, but it must not extend the RegularExpressionBody and RegularExpressionFlags

Re: RegExp.escape()

(yes/no)? And so on. On Sat, Jun 20, 2015 at 2:07 PM, Benjamin Gruenbaum benjami...@gmail.com wrote: As a cross-cutting concern I'd like the feedback of more people on https://github.com/benjamingr/RegExp.escape/issues/29 Basically we've got to make a design choice of readable output vs

Re: `new Object` vs `Object` difference

Pointing out that I'm replying to a message with an empty subject - using the correct original title here -- Forwarded message -- From: Rock zloir...@zloirock.ru Benjamin Gruenaum, Andrea Giammarchi, you are wrong about RegExp: ```js var re = /./; new RegExp(re) === re; // false

Re: Template site objects and WeakMap

` key? That would return a realm-specific object, of course. On Wed, Jun 17, 2015 at 10:19 AM, Benjamin Gruenbaum ing...@gmail.com wrote: congratulations and THANK YOU! I learned something important reading your messages. The notion that we can preserve non-observability when making one

Re: Re: Template site objects and WeakMap

AM, Benjamin Gruenbaum ing...@gmail.com wrote: congratulations and THANK YOU! I learned something important reading your messages. The notion that we can preserve non-observability when making one thing a WeakMap iff we make all other WeakMaps be strong for those same objects is true, novel

Re: Re: Template site objects and WeakMap

congratulations and THANK YOU! I learned something important reading your messages. The notion that we can preserve non-observability when making one thing a WeakMap iff we make all other WeakMaps be strong for those same objects is true, novel, and very surprising. I have been working on

Re: ECMAScript 2015 is now an Ecma Standard

This is awesome news - now to get someone to make something similar to es5.github.io in terms of readability and ease of use :) On Jun 17, 2015, at 19:46, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Ecma international has announced that its General Assembly has approved ECMA-262-6 The

Re: Template site objects and WeakMap

Aren't WeakMap keys only objects? On Jun 17, 2015, at 19:18, Mark S. Miller erig...@google.com wrote: [+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix in the spec asap!

Re: RegExp.escape()

Ok, with a ton of help from Domenic I've put up http://benjamingr.github.io/RexExp.escape/ Less cool coloring but more links and motivating examples and so on at https://github.com/benjamingr/RexExp.escape As this is my first attempt at this sort of thing - any non-bikeshed feedback would be

Re: Language design

I'm going to address your questions. `Object.is` - have you checked and read the actual thread in the list explaining the motivation behind that? Operator [] casts its argument to string ... but not when used with Symbol - that's the poit of symbols - to have non string keys that are unique.

Re: RegExp.escape()

. Miller *Sent:* Saturday, June 13, 2015 02:39 *To:* C. Scott Ananian *Cc:* Benjamin Gruenbaum; es-discuss *Subject:* Re: RegExp.escape() The point of this last variant is that data gets escaped but RegExp objects do not -- allowing you to compose RegExps: re`${re1}|${re2}*|${data

Re: RegExp.escape()

of `as if` to allow implementations to, for example, not escape some characters inside `[...]` as long as the end result is the same. On Sat, Jun 13, 2015 at 9:57 PM, Mark S. Miller erig...@google.com wrote: On Sat, Jun 13, 2015 at 11:39 AM, Benjamin Gruenbaum benjami...@gmail.com wrote

Re: Cross language discussion

mailing list or discourse board. On Wed, Jul 1, 2015 at 9:35 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jul 1, 2015, at 5:37 AM, Benjamin Gruenbaum wrote: So, this is something that has been bothering me for a while now. The TC, and the mailing list is full of some really

Re: Cross language discussion

rossb...@google.com wrote: On 1 July 2015 at 14:37, Benjamin Gruenbaum benjami...@gmail.com wrote: So, this is something that has been bothering me for a while now. The TC, and the mailing list is full of some really smart people. However, smart people can overlook things too and smart people can

Cross language discussion

So, this is something that has been bothering me for a while now. The TC, and the mailing list is full of some really smart people. However, smart people can overlook things too and smart people can spend months in a debate that other people already thought about. Other languages have open

Re: RegExp.escape()

I'm still not sure if it's worth it, after all it's just sugar for `RegExp.escape(str).replace(/[a-z]/gu, m = `\\${m}`)` On Tue, Jun 30, 2015 at 10:35 AM, Mathias Bynens mathi...@opera.com wrote: On Mon, Jun 29, 2015 at 9:04 PM, Benjamin Gruenbaum benjami...@gmail.com wrote: Why? What

Re: RegExp.escape()

Why? What advantage would it offer? On Mon, Jun 29, 2015 at 9:49 PM, C. Scott Ananian ecmascr...@cscott.net wrote: And I'm suggesting that `RegExp.escape(str, /[image: ☺]/ug)` is a much better idea.​ --scott ___ es-discuss mailing list

Re: RegExp.escape()

This is currently discussed at https://github.com/benjamingr/RegExp.escape/issues/29#issuecomment-116789780 . Adding my comment from there to here too: Some languages (PHP for example) do this (optional parameter with additional parameters) so it's not unprecedented. The question we should ask

Re: RegExp.escape()

I meant something like `RegExp.escape(str, ☺)` (also escapes `☺`). Since strings are iterable by code points via the new iteration protocol this sounds like the natural choice. I'm not sure such a second argument would be a good idea. On Mon, Jun 29, 2015 at 9:42 PM, C. Scott Ananian

Forbid implementations from extending the RegExp grammar.

So, following work on RegExp.escape [1] I found out that implementations may extend the regular expression grammar in JavaScript [2]. However, when asking esdiscuss and Stack Overflow about it [2][3] it doesn't look like any implementations currently do so (*). Can we please forbid

Re: Why the ECMAScript 2015 Promises don't have finally methods?

The reason ECMAScript 2015 promises do not have `finally` is because it wasn't necessary for the initial proposal and things were 'running late' already and it was possible to ship without it. Shipping fast enabled us to include promises in ECMAScript 2015. It is entirely possible (and dare I say

Re: Forbid implementations from extending the RegExp grammar.

point, can we protect that more narrowly? --scott On Jul 6, 2015 1:56 AM, Benjamin Gruenbaum benjami...@gmail.com wrote: So, following work on RegExp.escape [1] I found out that implementations may extend the regular expression grammar in JavaScript [2]. However, when asking esdiscuss

Re: [Meta] Proposal: Switch es-discuss from a mailing list to using the TC39 GitHub issue tracker for discussion.

I just want to point out you can use esdiscuss.org today for that form of viewing. No need to switch platforms for it. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: name anonymous functions on property assignments

In theory this sounds like a cool idea, I didn't even know variable assignments named functions. The only issue I see here is how we're now differentiating assignment by where it happens - what if the property is computed? As far as I know function names are more constrained (like variable names)

Re: await on synchronous functions

Out of curiosity, can you give an example of the Not Good parts? ISTM the await prefix is more of an explicit cast than an implicit conversation, and other than the very small timing gap in how throws are handled I pointed out a few days ago, I can't think of any situations where a throw would

Re: name anonymous functions on property assignments

, at 5:11 AM, Benjamin Gruenbaum wrote: In theory this sounds like a cool idea, I didn't even know variable assignments named functions. The only issue I see here is how we're now differentiating assignment by where it happens - what if the property is computed? As far as I know function

Re: name anonymous functions on property assignments

an empty string for this case. If the current spec handles symbols just fine in this way, why would the possibility that the property key is a symbol be a reason for an expression form not to set the name property? On Sun, Jul 26, 2015 at 1:12 PM, Benjamin Gruenbaum benjami...@gmail.com wrote: I

Re: Named Paramters

If we _wanted_ to add named parameters, we would _probably_ have a _different_ name for the named parameter inside the function and outside the function. ```js function foo(x as y){ } foo(y = 5); ``` Or something like that. That said, I'm not convinced we _need_ named parameters, that they

Re: Named Paramters

I think my original post might have been confusing so allow me to clarify. I'm not suggesting to add named parameters to the language, I did not intend to start a discussion about named parameters' merits vs passing an object literal (I thing Axel had a blog about that a while ago). What I'm

Named Paramters

Hey, I wasn't able to find information about the current status of a named parameters propsosal: // as in: foo(bar = 5); // logs 5 function foo(baz, bak, bar){ console.log(bar); } Is this being considered? Was it decided for/against? Anyone working on it?

Re: Named Paramters

}) function foo ({ baz, bak, bar }) { console.log(bar) } Or is there anything else you are considering or something I am missing. Regards On Jul 12, 2015, at 6:47 AM, Benjamin Gruenbaum benjami...@gmail.com wrote: Hey, I wasn't able to find information about

Re: Named Paramters

Thanks for the clarification. On Sun, Jul 12, 2015 at 5:05 PM, Luke Scott l...@webconnex.com wrote: On Jul 12, 2015, at 2:48 AM, Benjamin Gruenbaum benjami...@gmail.com wrote: I think my original post might have been confusing so allow me to clarify. I'm not suggesting to add named

Re: Alternative to Promise

race condition? > > Thanks again for giving me lots of detail about the history, now i need > more : ) > > On Oct 1, 2015, at 4:42 PM, Benjamin Gruenbaum <benjami...@gmail.com> > wrote: > > > > Where do you get the courage to challenge every inventor that they

Re: Alternative to Promise

On Sat, Oct 3, 2015 at 5:37 PM, 韩冬 wrote: > > This is exactly where i’m getting puzzled, suppose we have thread in > javascript(or whatever to run different things on different cores), > consider following code: > > We don't have threads in JavaScript, and there is no

Re: Alternative to Promise

On Sat, Oct 3, 2015 at 6:00 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > well > > > In fact, oftentimes the way people code uses closures which tend to be > more expensive than creating promises anyway. > > you pass "closures" to create a promise, a then and a catch, not sure >

Re: Alternative to Promise

> Where do you get the courage to challenge every inventor that they have to learn everything you've learned before they making decisions? Can we please keep it civil? > the question is why not check other languages first, when there’re nice solutions already there. Promises are rooted in the

Reflect.getDefaultParameterValues

Hey, other languages with default parameter values like Python, C#, Ruby and PHP have a means to retrieve the default parameter values of a function. >From what I understand (correct me if I'm wrong) - there is no way to get the default values of a parameter of a function in JavaScript. For

Re: Reflect.getDefaultParameterValues

t; refactoring more brittle. > > —Claude > > > Le 5 oct. 2015 à 16:04, Benjamin Gruenbaum <benjami...@gmail.com> a > écrit : > > > > Hey, other languages with default parameter values like Python, C#, Ruby > and PHP have a means to retrieve the default paramete

Re: Promises as Cancelation Tokens

We have pretty sound cancellation semantics in bluebird 3. http://bluebirdjs.com/docs/api/cancellation.html Handles multiple subscribers soundly. Solves the common use cases pretty well - has absolutely zero magic and pretty simple semantics. They work with .all and .race too. We have had a

Re: Promises as Cancelation Tokens

> Cool, I'm aware that cancellable promises have been explored in depth. I'd prefer to keep this thread focused on cancellation tokens though, and avoid comparisons. Cool, re-reading the discussion you asked for this in the first message - I apologize for missing it. I think using promises as

Re: Promises as Cancelation Tokens

> We could use a promise subclass as the cancellation token, but then tokens (and their constructor) would inherit things that really don't make sense, like "CancelToken.resolve" and "CancelToken.prototype.catch". Generally I dislike inheritance. I was merely saying it's an option. I favor

Re: Promises as Cancelation Tokens

*F# cancellation* - on second thought implicit cancellation through cancellation like in F# is impractical because of the eagerness of promises. I don't think it's a valid alternative here. I've discussed this with Reed Copsey (an F# expert) and he explained the philosophy behind it to me - it

Re: Promises as Cancelation Tokens

> Another cancellation scenario is when the consumer of an asynchronous task no longer > needs the result of an operation. In this case, they will only have access to the Promise > unless the cancellation token is routed to them through some other path. For what it's worth - this is exactly how

RE: operator overloading proposal

I see some discussion is happening - that's good. As I don't want to see the tremendous amount of work people put into value types and operator overloading go to waste - let's bring Brendan and Christian into this discussion and start with a link to Brendan's 2013 slides:

Re: Process of proposing targeted deconstruction

First of all - when you engage the list in that manner do not expect super constructive responses. Be concise and direct about what you want to get at and you'll get a response. Disrespect members - and people will not be so willing to engage. As for language feature proposal - the process is

Re: Try/catch conditional exceptions in light of generators

Hey, I just wanted to point out that this is now discussed in https://github.com/groundwater/nodejs-symposiums/pull/5 It appears that there are no proposals on the way to deal with it and it is a very real problem. What would be the correct process to bring more attention to it? On Fri, Nov 22,

Re: non-self referencial cyclical promises?

For what it's worth, bluebird promises detect the error and reject with: ``` TypeError: Chaining cycle detected for promise # ``` So it's both possible and not a performance issue. For this case, a WeakMap is not needed for this case. https://jsfiddle.net/41ez2b6d/ . > We ran into code "in the

Re: non-self referencial cyclical promises?

, Benjamin Gruenbaum <benjami...@gmail.com> wrote: > For what it's worth, bluebird promises detect the error and reject with: > > ``` > TypeError: Chaining cycle detected for promise # > ``` > > So it's both possible and not a performance issue. For this case, a > WeakMap is n

Re: non-self referencial cyclical promises?

Thanks​ Raul, I understand this case better now - fixed in master https://github.com/petkaantonov/bluebird/commit/7094e1677d79de99ba5f268785f49e9d99508e2f - wasn't particularly hard to fix this case, no one ever complained about it or mentioned it before so it wasn't considered. Bluebird will now

Re: How to modify the scope chain without `with` ?

For what it's worth very popular templating libraries like KnockoutJS use `woth` heavily. I think the consensus is that writing DSLs should be done as a transformation into JavaScript (like JSX) and not inside JavaScript (like Knockout and your library) The dynamic nature of `with` is why it

Garbage collection in generators

In the following example: ```js function* foo() { try { yield 1; } finally { cleanup(); } } (function() { var f = foo(); f.next(); // never reference f again })() ``` - Is the iterator created by the function `foo` ever eligible for garbage collection? - If

Re: Garbage collection in generators

On Wed, Feb 17, 2016 at 10:28 AM, Andreas Rossberg wrote: > > The spec does not talk about GC, but in typical implementations you should > expect yes. > Yes, important point since some ECMAScript implementations don't even have GC and are just run to completion. The spec

Re: Garbage collection in generators

On Wed, Feb 17, 2016 at 10:51 AM, Andreas Rossberg <rossb...@google.com> wrote: > On 17 February 2016 at 09:40, Benjamin Gruenbaum <benjami...@gmail.com> > wrote: > >> If you starve a generator it's not going to get completed, just like >>> other contro

Re: Garbage collection in generators

gt; > C++ RAII and Python refcounting are completely different: they are > precise, prompt, predictable, and deterministic. > > > > On Wed, Feb 17, 2016 at 12:59 AM, Benjamin Gruenbaum <benjami...@gmail.com > > wrote: > >> >> >> On Wed, Feb 17, 20

Re: Async iteration

I would be super surprised if I could use `var` everywhere _except_ async iteration. So I'd say consistency triumphs. Same reason all the ES2015 features exist in non-strict mode. Also, you might want to look at the async/await pep for why Python has added async iteration in 3.5 > On 14 Mar

Re: Async iteration

s://github.com/zenparsing/es-observable > > On Mon, Mar 14, 2016, 16:01 Benjamin Gruenbaum <ing...@gmail.com> wrote: > >> I would be super surprised if I could use `var` everywhere _except_ async >> iteration. >> >> So I'd say consistency triumphs. Same rea

RE: One-shot Delimited Continuations with Effect Handlers

> async functions only address the async use case and they're all scheduled on a simple micro-task queue. We need fine grained control over scheduling. Perhaps Zones can help a bit with that but that's just one of severals concepts that need this. Isn't the problem we actually need to solve here

Re: Promises, async functions, and requestAnimationFrame

Note that there is no guarantee that the `then` handlers (after the await) will fire in the same loop since they defer execution on their own and might defer it further. In practice I assume they'll probe to see if they need to actually schedule asynchronously or the constructed promise is

Iterator combinator methods

Hey, I remember a lot of talk about adding `.map/.filter` etc to iterators. The benefits of doing this are pretty big and I think fairly well understood and several other proposals (like observables and async iterators) would benefit from it. (I expand on the big advantages this has over

Re: Resource management

not sure what would be better. > > On Fri, Jan 6, 2017, 04:38 Benjamin Gruenbaum <benjami...@gmail.com> > wrote: > >> Oh, Bluebird's `Promise.using` does that with very high certainly. The >> reason we introduced `using` rather than let people just use the dispos

Re: Resource management

m fail, the > rest should be closed either immediately or as soon as they are > available, to avoid resource leaks.) > - > > Isiah Meadows > m...@isiahmeadows.com > > > On Mon, Jan 2, 2017 at 10:04 AM, Benjamin Gruenbaum > <benjami...@gmail.com> wro

Re: Resource management

Hey, We've actually worked on this extensively in bluebird with http://bluebirdjs.com/docs/api/promise.using.html and disposers which give something similar to the `with` syntax you describe. There has also been work on a `defer` like abstraction. The tricky parts were mostly getting it to work

Re: Resource management

And, on a similar note - a pattern has emerged in userland libraries all over: http://stackoverflow.com/questions/28915677/what-is-the-promise-disposer-pattern ___ es-discuss mailing list es-discuss@mozilla.org

Re: Microtask scheduling

Addressing the original request: > Any chance something like Node's process.nextTick could be added, maybe something like Promise.schedule(func, thisArg, ...args)? That's basically `Promise.resolve().then(func.bind(thisArg, ...args))` Although promise schedulers are huge - and I think could

Re: Re: Actual WeakSet Use Cases

Funny to see the issue is still discussed, I've actually used WeakSets a bunch in the last few years. Here's code from last weak that detects with a mutation observer when a new iframe is attached to the DOM (simplified): https://gist.github.com/benjamingr/9afb875d1d87377e7e66b166cf1905b5