To be clear, the `. * 2` example is an exaggeration. It’d be logical to
restrict it to (Optional)MemberExpressions but my point is that I think what
you’re allowed to do with it is not obvious. I think this is why Elm doesn’t
support it.
--
Agustín Zubiaga
On Nov 25, 2019, 12:54 PM -0500,
Hi Bob! I’m glad you like the proposal!
> Using `.a` to denote a function to retrieve the value of the property named
> `a` was actually part of an earlier proposal for a number of ways to extend
> dot notation. I won't link to that proposal since it's obsolete now, but it
> also allowed
>
>
>
> I don't think I like "await ||" as a syntax, because it doesn't have
> anything to do with the "OR" operator.
>
it is just a quick proposal to symbolise parallelism easily (||), but just
that, of course it could be any other more convenient symbol
> Manuel, I am not sure I understand your
I don't think I like "await ||" as a syntax, because it doesn't have
anything to do with the "OR" operator.
It does avoid adding a bunch of potentially optimization-breaking if
statements to the transpiled output for synchronous code like in my
example, though, because you only get the behavior
yet smaller, as Promise.resolve() was totally redundant here...
// NOTE async {} = asynchronous scope (it groups parallel awaits => `await||`)
// NOTE p? = function call that returns a promise (? = just and index)
async {
const x1 = await || p1()
const x2 = await p2(x1)
const x3 =
a few little corrections...
// NOTE async {} = asynchronous scope (it groups parallel awaits => `await||`)
// NOTE p? = function call that returns a promise (? = just and index)
async {
const x1 = await || p1()
const x2 = await p2(x1)
const x3 = await || p3()
const x10 = await
>
> Hi Manuel! Would you mind explaining the added value of your proposal? I
> am only seeing it being more verbose, but I've not found any added
> functionality or benefit from it
>
the proposal combines parallel and series async / await and could resolve
complex trees, like the following
Hi Tom! Would you mind clarifying the performance hit you are referring to?
I'm seeing that the "synchronous" calls wouldn't be added to the array you
used in your example, so it's not clear to me to which performance hit you
are referring.
Hi Manuel! Would you mind explaining the added value of
another example, that may "normalize" it a bit more:
```
async { // ... = returns a promise
const x1 = await|| ...
const x2 = await ... (x1)
const x3 = await|| ...
const x10 = await ... (x2, x3)
let x4, x5, x6
async {
x4 = await|| ... (x1, x2)
x5 =
why not making it work with the addition of a new keyword suffix for
parallel awaits (for example, `||`), grouping the mid blocks that require
parallelism. playing with your example and going a bit further:
```
async {
const v0 = await|| returnsAPromise(); // to be grouped in parallel
for
There is however a performance concern with your code that we should talk
about.
If I write this:
await.all {
returnsAPromise();
for (let i = 0; (i < 10); i++) {
doesSimpleFastSynchronousMath();
}
returnsAnotherPromise();
}
Then Babel will have no choice but to compile this to:
Hey, you're absolutely right! It's OK because it just means things are more
deterministic before the block exits. It doesn't impact any reasonable
expectations *during* the block.
I am convinced that your syntax is useful and does not introduce any new
confusion.
I wonder, then, if it is also
12 matches
Mail list logo
