Well, you can do that pretty easily with generators/yield instead of
async/await. So, not sure it's worth it.
On 06/05/2020 08:37, medikoo wrote:
> Jordan Harband wrote
>> Anything "more efficient" would likely not be spec compliant
>
> Promises (also those specified in ES) are quite
In theory, it should be possible to have both modes, if the parser is
designed for it. Unfortunately, that's not the case at the moment.
Mozilla has recently started working on a new parser which could be used
both by VMs and by JS/wasm devs. It might help towards this issue, but
it's still early
Before you can have a standard parser, you need a standard AST. There is
no such thing as the moment, so the v8 parser, the SpiderMonkey parser
and the JSCore parser, etc. all use distinct internal ASTs, each of
which changes every so often, either because the language changes or
because the VM
There's a tradeoff here.
If it's an extension of `for...of`, it's much clearer for users. If it's
a method of `Promise`, it's much more extensible.
Perhaps it could be a little bit of both?
Maybe something like:
```
for(item of items : Scheduler.limit(5)) {
// ...
}
```
where
Out of curiosity, what is the expected benefit wrt Esprima, Babel or
Shift? In particular since there is no standard AST for ECMAScript yet [1]?
Cheers,
David
[1] Ok, that's a subset of https://github.com/tc39/proposal-binary-ast,
which is in the pipes.
On 14/09/2019 07:46, Jack Works wrote:
>
According to the specs, DOMMatrix is limited to 4d matrices. They can be
used to emulate 1d-3d matrices trivially. However, many applications
(e.g. in graph theory) require arbitrary numbers of dimensions.
I'm not really familiar with Tensorflow, but if I read the API
correctly, it seems to be
Unfortunately, turning async code (which often has components that
execute in a different thread or process) back into in sync code is
really, really hard.
What semantics would you give to this `Promise.sync()`? Can other code
be executed by the main thread while you're waiting for your promise
Fwiw, generators can already be used as syntactic sugar for monads.
Cheers,
David
THIS MESSAGE AND ITS IP ADDRESS HAVE BEEN LOGGED. PLEASE DO NOT MOVE
FROM YOUR COMPUTER. YOU WILL SHORTLY RECEIVE A VISIT FROM THE IMPERATIVE
BRIGADE.
On 18/01/2019 06:32, Michael Luder-Rosefield wrote:
> It's
Yeah, `String.expand` is the nicest one I've seen so far.
On 12/12/2018 10:05, T.J. Crowder wrote:
> On Wed, Dec 12, 2018 at 6:59 AM Isiah Meadows
> wrote:
>>
>> Those names a little too generic for my liking here. What about
>> `String.expand(template, ...params)`?
>
> I like it.
>
>> And
Doing this sounds pretty fragile. Do you have any guarantee that the
order of fields is the same as the order of the array? Even if that's
the case in your scenario, it's pretty uncommon.
On 24/04/2018 16:41, somonek wrote:
> The use case is:
> (long story short)
>
> I have an array of items
That proposal is quite interesting, but I'm a bit scared about potential
for breakage. Maybe Integer/Float values should be introduced only in
your "use math" mode? Would that be sufficient?
___
es-discuss mailing list
es-discuss@mozilla.org
11 matches
Mail list logo
