Re: operator overloading proposal

Two primary concerns: 1. JS uses proxies for a few similar hooks (like `foo["prop"]` and `foo()`) now. Python uses `__getattr__` and `__call__` for those, but JS doesn't use magic methods for those. 2. Performance is going to be much harder to ensure, especially if you can mutate the operator

Re: setTimeoutAt(cb, date)

I may have linked the wrong thread by accident. I was trying to link a thread I started a few months ago about moving it from the DOM into ES. On Tue, Jul 11, 2017, 14:40 Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Sat, Jul 8, 2017 at 12:58 PM, Isiah Meadows <isiahmead.

Re: Functional Operators

+1 on the idea, -1 on the execution. Here's a few things to be aware of: - A single unary or binary operator without parentheses is unambiguous where only expressions are allowed. - If the operators directly desugar to lambdas, you'll have functions that look `===`, but aren't. - The operator `-`

Re: setTimeoutAt(cb, date)

Previous discussion: https://esdiscuss.org/topic/standardize-global-settimeout-etc On Sat, Jul 8, 2017, 15:53 Cyril Auburtin wrote: > What would you think of this function allowing to run a callback at a > given date? > ___ >

Re: InterleavedTypedArray type

(which is better addressed by separate `foo_create` and `foo_destroy` exports with raw pointers and creating a JS wrapper to manage them more idiomatically). [1]: https://www.npmjs.com/package/ref-struct - Isiah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me

Re: Re: Math.minmax

this. var min = foo, max = bar; if (min > max) { var tmp = max; max = min; min = tmp } // This should also compile similarly, provided `foo` and `bar` // are both integers and constant reference reads. var min = Math.min(foo, bar) var max = Math.max(foo, bar) ``` - Isiah Meadow

Re: Spaceship Operator

Inline On Tue, Jun 27, 2017, 16:19 Mike Samuel <mikesam...@gmail.com> wrote: > On Tue, Jun 27, 2017 at 4:13 PM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > > For what it's worth, for most practical purposes, `arr.sort((a, b) => b - > > a))` works well e

Re: Microtask scheduling

>> immediately after the current code is finished and before the next, >>>> scheduled code (this can cause issues with processing I/O if you're doing >>>> it too frequently). >>>> >>>> In a browser you can sorta emulate similar behavior throu

Re: Spaceship Operator

For what it's worth, for most practical purposes, `arr.sort((a, b) => b - a))` works well enough. (The only thing it doesn't work well with are NaNs, but in practice, those almost never occur.) On Tue, Jun 27, 2017, 16:11 森建 wrote: > PHP, Ruby, Groovy have spaceship

Microtask scheduling

to implement their own wrappers to gain similar functionality without assuming another dependency. Any chance something like Node's `process.nextTick` could be added, maybe something like `Promise.schedule(func, thisArg, ...args)`? - Isiah Meadows m...@isiahmeadows.com Looking for web

Re: Deterministic Proposal

type ICs), and it's often faster in practice to recalculate than memoize based on argument. The only time I have found memoization to be very useful is in one specific case: lazy evaluation (run once). But that is constrained to just evaluating a thunk and storing the result. - Isiah Meadows m

Re: Re: String#trim(chars)

oint where that becomes your bottleneck, you should really reconsider what you're actually doing. ----- Isiah Meadows m...@isiahmeadows.com On Mon, Jun 19, 2017 at 8:51 AM, Michael DeByl <michael.de...@gmail.com> wrote: > Generally `trim()` will only operate on the start and end of the

Re: Feature request: Array.prototype.random

this: `array[Math.randomInt(array.length)]`. I feel in this particular case, a more general solution is much more useful than just a "pick some random item in an array". (Number guessing games, anyone?) ----- Isiah Meadows m...@isiahmeadows.com On Thu, Jun 15, 2017 at 6:20 PM, William Wh

Re: flatMap or flatten

Eh, not exactly. Scala uses a more general version that works with any monadic type (`flatMap` is technically a monadic bind, and `flatten` a monadic join), while this is roughly equivalent to `[].concat(...array.map(func))` or `_.flatten(_.map(array, func))`. On Tue, Jun 6, 2017, 07:02 Igor

Re: It would be good to have error.prettyStack to capture same nice stack trace as console.error(..) does

You may be interested in this: https://github.com/tc39/proposal-error-stacks/ On Tue, Jun 6, 2017, 06:09 Igor Baklan wrote: > It would be nice to have `error.prettyStack` and > `Execution.getPrettyStack()` / `Error.capturePrettyStackTrace(..)` to > capture same nice stack

Re: p-norms, Vector

This *really* seems like a good use case for WASM + SIMD (and a small static heap), given the number-heavy nature of it. On Mon, Jun 5, 2017, 10:47 kdex wrote: > Thanks for the pointers! > > > `array.reduce( (a,b)=>a+b )` (Although I wouldn't object to `Math.sum()`) > Yes; no

Re: Interfaces

do otherwise, since they can just lower the optimizations into the bytecode they generate rather than relying on inline caching. - Isiah Meadows m...@isiahmeadows.com On Fri, Apr 28, 2017 at 7:03 AM, doodad-js Admin <dooda...@gmail.com> wrote: > I was more thinking of somet

Re: Interfaces

They could be. I didn't initially include it, but that does logically follow from it. - Isiah Meadows m...@isiahmeadows.com On Thu, Apr 27, 2017 at 7:05 AM, doodad-js Admin <dooda...@gmail.com> wrote: > I like it. Are interfaces extendable? I mean something like... >

Re: FW: Re: Strict Relational Operators

or already: `in` >> >> ```js >> if ("foo" in obj) >> ``` >> >> So the concept of non-symbolic binary operators isn't entirely new to the >> parsing/grammar infrastructure. >> >> -- T.J. Crowder >> >> On Sat, Apr 15, 2017 at 4:42 A

Re: FW: Re: Strict Relational Operators

potentially steep slope to acceptance. Just a bit of pessimistic pragmatism here. ----- Isiah Meadows m...@isiahmeadows.com On Fri, Apr 14, 2017 at 5:33 PM, doodad-js Admin <dooda...@gmail.com> wrote: > I prefer the idea of keyword operators, like : > > > > a lt 1 // stri

Re: Async functions not friendly to promise extensions

would link my source here. - Isiah Meadows m...@isiahmeadows.com On Fri, Apr 14, 2017 at 7:17 AM, T.J. Crowder <tj.crow...@farsightsoftware.com> wrote: >> ...that'd break when using multiple returns with different types. > > Well, not necessarily. It may have bee

Re: Re: Strict (non-coercing) expressions

Just a quick FYI, *nobody* on TC39 likes adding directives known to the core language - they aren't too keen on Perl's tendency towards them. - Isiah Meadows m...@isiahmeadows.com On Fri, Apr 14, 2017 at 2:42 AM, Bruno Jouhier <bjouh...@gmail.com> wrote: > The "use ...

Re: Re: throwif operator

uch nicer: foo(...args, () => throw new Error()) ``` - Isiah Meadows m...@isiahmeadows.com On Wed, Apr 12, 2017 at 3:11 AM, Нурбек <nurbek...@gmail.com> wrote: > Yes, throw expressions would be helpful to shorten if statements to > one-liner ternary operators

Re: Strict Relational Operators

I'm not sure there has been prior discussion. A lot of stuff has already been discussed in depth, but that I don't think is one of them. - Isiah Meadows m...@isiahmeadows.com On Mon, Apr 10, 2017 at 3:47 AM, T.J. Crowder <tj.crow...@farsightsoftware.com> wrote: > I'm sure there

Re: MultiLineCommentChars and PostAsteriskCommentChars productions

It's a single-character lookahead, which is sufficient for an LR(1) language. All it does is validate that `/* * */` is a complete block comment, but not `/* *` or `/* * /`. On Sun, Apr 9, 2017, 17:13 Darien Valentine wrote: > I am curious about this lexical production,

Re: Strawman: Complete array and object destructuring

Very little runtime branching (as in, not known from counting during parsing). So it's doable. It's just not trivial, considering this may likely require adapting the calling convention in most engines. - Isiah Meadows m...@isiahmeadows.com On Wed, Mar 29, 2017 at 4:15 PM, Paul Whipp <paul

Re: Map/Set.prototype.size is O(n)

to both do that and remaining conformant. - Isiah Meadows m...@isiahmeadows.com On Wed, Mar 29, 2017 at 11:31 AM, Oriol _ <oriol-bugzi...@hotmail.com> wrote: > Not only `size`. All `get`, `set`, `has`, etc. algorithms in the spec are > O(n). > > But as explained in

Re: Standardizing conditional try/catch

ething specific to error > >>> handling. > >>> > >>> On Thu, Mar 23, 2017, 06:01 Alexander Jones <a...@weej.com> wrote: > >>>> > >>>> To be clear I was talking about advanced pattern matching for > exception > >>

Re: Standardizing conditional try/catch

ugger to handle. > > > Thank you, > -Zach Lym > > > On Sat, Mar 25, 2017 at 6:29 PM, Isiah Meadows <isiahmead...@gmail.com> wrote: >> I want advanced pattern matching, but not something specific to error >> handling. >> >> On Thu, Mar 23, 2017,

Re: Standardizing conditional try/catch

I want advanced pattern matching, but not something specific to error handling. On Thu, Mar 23, 2017, 06:01 Alexander Jones <a...@weej.com> wrote: To be clear I was talking about advanced pattern matching for exception handling. Y(probably)AGNI? On Tue, 21 Mar 2017 at 05:08, Isiah M

Re: Strawman: partial application operator

I'll invite you to check out this particular Google search, as function binding has been discussed many different times on this list. https://www.google.com/#safe=active=site:esdiscuss.org+partial+application&* ----- Isiah Meadows m...@isiahmeadows.com On Wed, Mar 22, 2017 at 5:15 AM,

Re: Standardizing conditional try/catch

and Swift), that YAGNI argument is starting to seem harder to accept. Pattern matching is to conditionals as async/await is to async tasks - it lifts the logic from fairly imperative, low level form to a high level, declarative form, with only a small loss of low-level control. ----- Isiah

Re: Do we really need async generators?

Missed the list... -- Forwarded message -- From: Isiah Meadows <isiahmead...@gmail.com> Date: Mon, Mar 13, 2017 at 12:14 AM Subject: Re: Do we really need async generators? To: Axel Rauschmayer <rausc...@icloud.com> From my basic reading, this is not that fa

Re: Proposal of Multithread JavaScript

For prior discussion on a fairly similar concept, see my proposal [1] and related thread [2]. [1]: https://gist.github.com/isiahmeadows/a01799b4dc9019c55dfcd809450afd24 [2]: https://esdiscuss.org/topic/module-based-parallel-js-strawman - Isiah Meadows m...@isiahmeadows.com On Sun, Mar 12

Re: Observable/Promise parallel control flow proposal

raction of what most libraries provided. The > Observable proposal is turning out to be similar in this respect. > - > > Isiah Meadows > m...@isiahmeadows.com > > > On Tue, Mar 7, 2017 at 6:23 AM, Matthew Robb <matthewwr...@gmail.com> > wrote: > > Isiah I think

Re: Observable/Promise parallel control flow proposal

I'll note that async functions had a similar thing going on, too. Most third-party libraries had most issues taken care of, but what landed in the spec was only a fraction of what most libraries provided. The Observable proposal is turning out to be similar in this respect. - Isiah Meadows m

Observable/Promise parallel control flow proposal

, but not quite to this scale. [1]: https://github.com/tc39/proposal-observable [2]: https://github.com/tc39/proposal-observable/issues/141 - Isiah Meadows m...@isiahmeadows.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org

Re: How about awaiting Arrays ?

failure: `Promise.any` I know it'll be difficult, but I'd like to come up with something that will be fast, usable, and highly intuitive. - Isiah Meadows m...@isiahmeadows.com On Sat, Mar 4, 2017 at 12:15 PM, Andrea Giammarchi <andrea.giammar...@gmail.com> wrote: > glad this to

Re: How about awaiting Arrays ?

to less state needed, so I didn't see the need to add support for that. - Isiah Meadows m...@isiahmeadows.com On Fri, Mar 3, 2017 at 11:59 AM, Michał Wadas <michalwa...@gmail.com> wrote: > My mistake Array.from is not necessary because Promise.all accepts any > iterable. > &

Re: How come resolving a settled Promise doesn't throw?

BTW, there's still usefulness of making resolution/rejection idempotent and never throwing. IMHO, I'd just like to see this die. - Isiah Meadows m...@isiahmeadows.com On Tue, Feb 28, 2017 at 4:36 PM, Jordan Harband <ljh...@gmail.com> wrote: > Although now that I think about it, it

Re: How come resolving a settled Promise doesn't throw?

Also, making promise resolution idempotent makes dealing with things way easier. Similarly, most deferred libraries ensure their resolution is idempotent. On Tue, Feb 28, 2017, 13:20 Tab Atkins Jr. wrote: > On Tue, Feb 28, 2017 at 10:12 AM, /#!/JoePea

Re: Enable async/await to work on functions that don't just return promises.

May I add one more thing: the main topic this was about is adapting non-standard async APIs (like Node's error-first callback idiom) to the land of promises. Async functions and iterators are incredibly useful when you're dealing with just promises, especially consuming them, but this is about

Re: Standardize global `setTimeout`/etc.?

Okay. Never mind, then. On Sun, Feb 26, 2017, 08:42 Andrea Giammarchi wrote: > What I meant, is that I don't think it'd be wise to duplicate DOM > standards on the ES side or, even worse, create specification > incompatibilities. > > Timers are just the top of the

Re: Enable async/await to work on functions that don't just return promises.

n here, in that it allows explicitly non-local jumps, provided they're correctly typed. - Isiah Meadows m...@isiahmeadows.com On Sat, Feb 25, 2017 at 5:55 PM, Codefined <codefi...@debenclipper.com> wrote: > It strikes me as an interesting development to see that the current > definit

Standardize global `setTimeout`/etc.?

to standardize these methods in the language proper instead of just within the browser. - Isiah Meadows m...@isiahmeadows.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: a more consistent and stricter number converting function - Number.of()

Most likely lack of interest and nobody trying to push it through the process. It's come up repeatedly, but no one has actually tried to write up a formal proposal and get someone on TC39 to champion it. - Isiah Meadows m...@isiahmeadows.com On Fri, Feb 24, 2017 at 8:28 AM, 段垚 <d

Re: Written Proposal for "package" Keyword for ES20XX Imports

I'll point out that Babel doesn't follow spec perfectly because it can't transpile the bindings correctly in the case of synchronously executed code with circular dependencies. That's a CommonJS limitation that Babel can't work around any more than it already does. On Tue, Feb 21, 2017, 17:54

Re: Module singletons

I'm going purely based on memory, but if I recall correctly, the module name resolution is left entirely to the implementation. That decides whether two specifiers from two different modules point to the same module. (Technically, two modules could even share a file path without being in

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

with how to handle these cases. - Isiah Meadows m...@isiahmeadows.com On Tue, Feb 7, 2017 at 9:39 AM, Michael Dyck <jmd...@ibiblio.org> wrote: > On 17-02-06 07:32 PM, Waldemar Horwat wrote: >> >> On 02/04/2017 07:20, Michael Dyck wrote: >>> >>> On 1

Re: Proposal for a static constructor and static member variables

functions would be created once per class + subclass, so it'd waste a *lot* of time for no otherwise good reason.) So given it's best to only run it once ever, and parameters don't make sense, might as well just make it a declarative block. ----- Isiah Meadows m...@isiahmeadows.com On Thu, Ja

Re: Determining if an object can be constructed

Yeah, I'm aware. I'm keeping my previous "prototype with a specific method" this time around. Much easier IMHO. On Tue, Jan 24, 2017, 13:47 Claude Pache <claude.pa...@gmail.com> wrote: > > > Le 24 janv. 2017 à 19:12, Isiah Meadows <isiahmead...@gmail.com> a &g

Re: NodeJS's __filename/__dirname in ES6 Modules

()` is at stage 3 already IIRC. (FWIW ES6 modules are sufficiently different enough that I feel it'd be okay to keep a different syntax for it, and to make it a syntactic form, to fit with the syntactic nature of ES modules.) - Isiah Meadows m...@isiahmeadows.com On Sat, Jan 21, 2017 at 1:22 PM, Andrea

Re: Determining if an object can be constructed

I'll point out that all I need is some way to detect anything that is callable except for classes. Basically, anything that has a `[[Call]]` that doesn't throw unconditionally without entering a different scope (like classes, but not %ThrowTypeError%). And to clarify, these would both be included

Re: getOwnPropertyDescriptor side effects

Thanks! I see now. On Thu, Jan 19, 2017, 12:30 Boris Zbarsky <bzbar...@mit.edu> wrote: > On 1/19/17 12:24 PM, Isiah Meadows wrote: > > 1. What does Firefox do with the getter on non-errors? > > Oh, I didn't make that clear, did I? On a non-error in the getter, we &

Re: getOwnPropertyDescriptor side effects

I agree that no setter (I didn't see one in the spec) is not Web compatible. In fact, I recall Bluebird running into serious issues with erroneous warnings over read-only stacks in PhantomJS, and had to disable them in my tests as a result. (I eventually dropped the dependency in favor of native

Re: Determining if an object can be constructed

Inline. On Thu, Jan 19, 2017, 03:26 Claude Pache <claude.pa...@gmail.com> wrote: > Le 17 janv. 2017 à 23:48, Isiah Meadows <isiahmead...@gmail.com> a écrit : > > Out of curiosity, why are classes specified to have a [[Call]] internal > method instead of special-cas

Re: getOwnPropertyDescriptor side effects

t; > On Thu, Jan 12, 2017 at 1:04 PM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > > Okay, so it's a V8 bug. Filed it here: > https://bugs.chromium.org/p/v8/issues/detail?id=5834 > > On Thu, Jan 12, 2017, 03:03 T.J. Crowder <tj.crow...@farsightsoftware.com>

Re: Determining if an object can be constructed

Out of curiosity, why are classes specified to have a [[Call]] internal method instead of special-casing `typeof` and friends to work with them? Somewhat of a tangent, but just a curious question on the design decision. On Tue, Jan 17, 2017, 08:31 Claude Pache wrote: > >

Re: Cancel Promise pattern (no cancellable promises)

And that's why we're waiting on the next meeting to happen with notes posted, so we can figure out what to do next. It's likely to get discussed, especially considering the current situation and pressing need for it. On Thu, Jan 12, 2017, 13:27 Jordan Harband wrote: > The

Re: Introduction of promise.return() and promise.throw() similar to generator.return() and generator.throw()

Look up the "revealing constructor pattern". There's a reason why only the creator can resolve a promise imperatively. On Thu, Jan 12, 2017, 09:22 Igor Baklan wrote: > Introduction of promise.return() and promise.throw() similar to > generator.return() and generator.throw()

Re: getOwnPropertyDescriptor side effects

Okay, so it's a V8 bug. Filed it here: https://bugs.chromium.org/p/v8/issues/detail?id=5834 On Thu, Jan 12, 2017, 03:03 T.J. Crowder wrote: > So to sum up, then, and circle back to Francisco Tolmasky's original > question: > > * For ordinary objects,

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

ression', > left: $1, > right: $3, > }; > } > ``` > > Similarly other "early errors". > > BTW, here is the example I mentioned above of how Flow has to do > backtracking in parsing in some edge cases, making the grammar completely >

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

eral. It won't be doable > if lookaheafs won't be enough, and only a backtracking can recover (like > the cases with Flow parser). > > Dmitry > > > On Wed, Jan 11, 2017 at 6:09 PM Isiah Meadows <isiahmead...@gmail.com> > wrote: > > Heuristically, I doubt it'

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

Heuristically, I doubt it's even context-free at this point, considering the concept and widespread prevalence of early errors now. I suspect it's mildly context-sensitive (maybe tree-adjoining?), but I'm no formal language expert here. On Wed, Jan 11, 2017, 14:23 Dmitry Soshnikov

Re: getOwnPropertyDescriptor side effects

I was expecting the error to throw on invoking the getter. Calling `Object.getOwnPropertyDescriptor` should *never* do that (spec invariant). On Wed, Jan 11, 2017, 15:30 Boris Zbarsky <bzbar...@mit.edu> wrote: > On 1/11/17 3:12 PM, Isiah Meadows wrote: > > Okay. The error stack be

Re: getOwnPropertyDescriptor side effects

Okay. The error stack being constructed that early is odd, though. On Wed, Jan 11, 2017, 10:39 Boris Zbarsky <bzbar...@mit.edu> wrote: > On 1/11/17 6:43 AM, Isiah Meadows wrote: > > Not if it's (likely) throwing from the `new Error`. > > It's not. The "stack" pro

Re: getOwnPropertyDescriptor side effects

Really, the only thing that matters is in fact *observable* behavior, so I'd concur. I just get the feeling several people in this thread don't quite understand that part of the spec, or in a few cases, the spec itself and its invariants. On Wed, Jan 11, 2017, 04:17 Raul-Sebastian Mihăilă

Re: getOwnPropertyDescriptor side effects

throws 123 > > It should be probably filled on V8 bug tracker. > > > On 10/01/17 21:14, Isiah Meadows wrote: > > To clarify, what engine has the bug here? I've lost that context. > > On Tue, Jan 10, 2017, 14:54 Michał Wadas < <michalwa...@gmail.com> > michalwa...@

Re: getOwnPropertyDescriptor side effects

To clarify, what engine has the bug here? I've lost that context. On Tue, Jan 10, 2017, 14:54 Michał Wadas wrote: > Actually here spec repeats itself because... > > *A conforming implementation of ECMAScript may provide additional* types, > values, objects, *properties*,

Re: Cancel Promise pattern (no cancellable promises)

Um... This isn't much different than Bluebird's `Promise.prototype.cancel`, admittedly the least optimal of all these so far. On Sat, Jan 7, 2017, 08:02 Igor Baklan wrote: > In general I thing it would be good to have something like > [``java``(``Thread.interrupt()``)]( >

Re: getOwnPropertyDescriptor side effects

First, the `stack` property is non-standard. Second, proxies don't have to be stateful, and many of them aren't. On Fri, Jan 6, 2017, 14:58 Raul-Sebastian Mihăilă wrote: > That sounds like a bug because error objects are ordinary objects and the > [[GetOwnProperty]]

Re: Resource management

t; reason we introduced `using` rather than let people just use the disposer > pattern is because it is very tricky to get right in userland - so the > library provided it. > > On Fri, Jan 6, 2017 at 2:51 AM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > > It'd be n

Re: Cancel Token proposal withdrawl

I do suspect most of these will end up answered in the next meeting's notes, though. Hopefully, they do. So on that note, I'll let this sit for a bit longer (and probably re-ask then if it ends up not addressed). - Isiah Meadows m...@isiahmeadows.com On Thu, Jan 5, 2017 at 8:53 PM, Isiah

Re: Cancel Token proposal withdrawl

Okay...I may have misremembered the general reason (I thought I saw perf concerns stated somewhere, but I can't remember precisely where), but I've yet to see anything significant in the open about why they were so against it. That's why I'm asking what drove them against it. - Isiah Meadows

Cancel Token proposal withdrawl

/proposal-cancelable-promises/issues/70#issuecomment-267414933 - Isiah Meadows m...@isiahmeadows.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Resource management

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> wrote: > And, on a similar note - a pattern has emerged in userland libraries all >

Re: weak reference proposal

. Therein lies the problem. - Isiah Meadows m...@isiahmeadows.com On Sat, Dec 31, 2016 at 12:31 PM, Uther Pendragon <uther...@gmail.com> wrote: > > ...additionally, I think the term "weak reference" is inaccurate for ipc > referencing... I would describe that more as sup

Re: Weak Reference proposal

the individual process. - Isiah Meadows m...@isiahmeadows.com On Sat, Dec 31, 2016 at 9:23 AM, Alexander Jones <a...@weej.com> wrote: > Please correct me Isiah/Steve - but I think the problem Steve is talking > about is *cross-process* cycles. Without an inter-process protocol

Re: Resource management

). - Isiah Meadows m...@isiahmeadows.com On Fri, Dec 30, 2016 at 2:03 AM, J Decker <d3c...@gmail.com> wrote: > Just a shot; but something ilke deasync ? > https://www.npmjs.com/package/deasync > > it's not so much about ordering wait in the current code, but the current > code wit

Re: Resource management

` for Promise-resolving equivalents. - Isiah Meadows m...@isiahmeadows.com On Thu, Dec 29, 2016 at 11:05 PM, Jamesernator <thejameserna...@gmail.com> wrote: > The `for` loop approach works for synchronous resources as well actually, > there's nothing special about those `await`e

Re: Weak Reference proposal

. And reference cycles within the process are mitigated by the existing mark-and-sweep derivatives engines already use. - Isiah Meadows m...@isiahmeadows.com On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sph...@gmail.com> wrote: > On 12/27/2016 04:45 AM, Isiah Meadows wrote: > > The

Re: Resource management

without the use of exceptions. - Isiah Meadows m...@isiahmeadows.com On Thu, Dec 29, 2016 at 9:05 AM, Raul-Sebastian Mihăilă <raul.miha...@gmail.com> wrote: > I agree, but note that a resolved promise is not the same as a fulfilled > promise (https://tc39.github.io/ecma262/#sec-pro

Resource management

.. } ``` (I'm not totally sure about what methods the closeable/etc. API or protocol should use.) [1]: https://github.com/tc39/proposal-async-iteration/issues/68 - Isiah Meadows m...@isiahmeadows.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Weak Reference proposal

nd it eliminates the possibility of porting to browsers. So I really badly need language-level weak references. - Isiah Meadows m...@isiahmeadows.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proxy

> > es-discuss mailing list > > > es-discuss@mozilla.org > > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > > ___ > > > es-discuss mailing list > > > es-discuss@mozilla.org

Re: Iterator combinator methods

Shouldn't those be implemented in `%IteratorPrototype%` instead, so they can be used across all iterator types (including array entries, set entries, generator instances, etc.)? On Fri, Dec 9, 2016, 15:53 Dmitry Soshnikov wrote: > There are some good examples with

Re: Scheduling of async functions

You can already mitigate it with `await undefined` or similar. On Wed, Nov 30, 2016, 12:16 Jeremy Martin wrote: > When mixing callback logic with async functions, it's up to the programmer > to choose the callback semantics that they want. > > Forcing execution of the async

Re: Object.equals() and Object.clone()

I agree. Also, consider iterables. Should their `Symbol.iterator` method be called? There's no obvious behavior for the details, and people's opinions differ on what should be correct. On Mon, Nov 14, 2016, 20:58 Frankie Bagnardi wrote: It's pretty hard to decide how these

Re: Destructuring object outside of var declaration

Okay. Is it a spec bug then? Throwing a ReferenceError is surprising and odd IMHO. On Sun, Nov 13, 2016, 14:45 Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > On Nov 13, 2016, at 10:49 AM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > > Firefox likely has a par

Re: Destructuring object outside of var declaration

Firefox likely has a parser bug (it should never throw a ReferenceError in that situation). As for the assignment, I wish that `{foo, bar} = extract()` was accepted as a statement in more places. On Sun, Nov 13, 2016, 13:28 Thaddee Tyl wrote: > On Tue, Sep 17, 2013 at

Re: Wrapping regex's with proxies isn't working

Le 10 nov. 2016 à 15:50, Isiah Meadows <isiahmead...@gmail.com> a écrit : > > This could be resolved by checking the underlying non-proxy object and > using that one's internal slots instead, in each language-level method that > checks that. > > > Such semantics could

Re: Wrapping regex's with proxies isn't working

This could be resolved by checking the underlying non-proxy object and using that one's internal slots instead, in each language-level method that checks that. On Thu, Nov 10, 2016, 09:20 Claude Pache wrote: > > > Le 10 nov. 2016 à 14:59, Angel Scull

Re: Immutable const?

bjects has no effect on (it only has an effect with the internal `object.[[Get]]` and `object.[[Set]]` methods). ----- Isiah Meadows m...@isiahmeadows.com On Tue, Nov 8, 2016 at 8:57 AM, Reinis Ivanovs <da...@untu.ms> wrote: > This idea sounds like having a version of the `const` keyword

Re: Module-based parallel JS strawman

Ok. I'll admit my terminology is mostly incorrect (this isn't technically *cooperative*). I also have a few clarifications inline. On Sun, Nov 6, 2016, 06:03 Florian Bösch <pya...@gmail.com> wrote: > On Sun, Nov 6, 2016 at 6:57 AM, Isiah Meadows <isiahmead...@gmail.com> > wro

Module-based parallel JS strawman

TL;DR: I'm proposing a completely different threading model, supporting lightweight and cooperative multitasking while allowing synchronous, thread-safe communication and inspection. Apologies for the length. --- Admittedly, this is a significant departure from the original

Re: Proposal of Multithread JavaScript

Inline - Isiah Meadows m...@isiahmeadows.com On Thu, Nov 3, 2016 at 10:08 PM, Leo Dutra <leodutra...@gmail.com> wrote: > Why would UI/DOM access need to be serialized? It already kind of does when working in single-threaded code. How often do you need to do things like `element.ap

Re: Proposal of Multithread JavaScript

Inline. - Isiah Meadows m...@isiahmeadows.com On Thu, Nov 3, 2016 at 6:41 PM, Michael J. Ryan <track...@gmail.com> wrote: > Workers define a clear boundary... In Windows, only the main thread can > touch the ui.. and in Linux, threads are almost as expensive as > proce

Re: Ranges

a','b','c',...,'z','AA','AB',...]` > > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>: > > > > > If there's a Number.range, if suggest a corresponding String.range for > > > character ranges... Agreed on it being a utility function over me > synta

Re: Ranges

ssarily transpile > to be a generator that yields "A", "B" and "C". > > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote: > > I'll note, just for clarity, that Scala's `1 to 10` is technically just a > > normal method call equivalent

Re: Ranges

I'll note, just for clarity, that Scala's `1 to 10` is technically just a normal method call equivalent to `(1).to(10)`, with optional parentheses removed. Also, I'd prefer this to be a generator instead, so infinite ranges are also possible, and so it doesn't have to be eager. On Thu, Nov 3,

<    1   2   3   4   5   6   7   8   9   10   >