Re: Proposal: Property Accessor Function Shorthand
This is a great proposal which I hope can attract the support of the powers
that be. The arrival of optional chaining seems to indicate a renewed
interest in optimizing the way properties are accessed--which after all is
a big part of what JS does for a living.
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
```
const getFirstName = .name.first;
```
With optional chaining syntax, this would presumably also be able to be
written as `.name?.first`.
The earlier proposal also suggested extending this notation to arrays, so
that
```
const head = .[0];
```
In case you are interested, the current version of the proposal for
extended dot notation limits itself to accessing multiple properties with
the syntax `.{a, b}`. It can be found at
https://github.com/rtm/js-pick-notation/.
FWIW, the syntax `.propName` does appear to be syntactically unambiguous.
--
Bob
On Sun, Nov 24, 2019 at 4:51 PM wrote:
> Hi folks! I'd like to hear your feedback on a proposal idea I have and
> that I couldn't find anything on. Here is what I have so far.
>
> With the rising popularity of functional programming patterns in
> JavaScript, functions that take an object and return the value of a
> property are ubiquitous. These are some popular examples:
>
> ```js
> // filtering by a boolean property
> const activeProducts = products.filter(product => product.active);
>
> // mapping
> const productNames = products.map(product => product.name);
>
> // sorting, grouping, etc
> const sortedProducts = _.sortBy(products, product => product.name);
> const { true: activeProducts, false: inactiveProducts } = _.groupBy(
> products,
> product => product.active
> );
> ```
>
> This pattern is so common in fact that libraries like `lodash` (and
> frameworks) often also accept passing the name of the property as a string:
>
> ```js
> const sortedProducts = _.sortBy(products, "name");
> ```
>
> However, this technique has various problems:
>
> 1. It requires extra code from the library authors. With its typical
> disadvantages.
> 2. It has a potential negative impact on performance.
> 3. It is not easily statically analyzable, which makes it hard to
> type-check, infer, and for tooling to catch typos.
>
> Several languages have solved these problems by introducing some syntactic
> sugar that simplifies the definition of these functions. My favorite
> example is Elm's: `.property` shorthand [1]. If JavaScript supported this
> syntax, we could write the previous examples as:
>
> ```js
> const activeProducts = products.filter(.active);
> const productNames = products.map(.name);
> const sortedProducts = _.sortBy(products, .name);
> const { true: activeProducts, false: inactiveProducts } =
> _.groupBy(products, .active);
> ```
>
> This is, in my opinion, nice to read and write. Besides, since this
> expression simply yields a function, it would not have any of the problems
> the string approach has.
>
> Combined with the pipeline operator proposal, it would allow code like the
> following:
>
> ```js
> orders
> |> filter(.active)
> |> flatMap(.products)
> |> .length
> ```
>
> Lastly, engines might be able to optimize this further (or more easily)
> than normal functions since functions defined this way would be restricted
> to returning a constant property of the object that is passed to them. They
> would not be able to have any other expressions or statements in them.
> Unfortunately, they would not be considered automatically pure because
> users can implement side effects in property getters or Proxies.
>
> I could not think of any syntax ambiguity this could cause, but I would
> appreciate your thoughts in this regard. It does look similar to the RHS of
> a Member Expression, but it would not be ambiguous because the two would
> not be allowed under the same contexts. The F# community has had an
> interesting ongoing conversation [2] about the topic, but it is my
> understanding we would not have these problems in JavaScript since Call
> Expressions require parenthesis.
>
> [1] https://elm-lang.org/docs/syntax#records
> [2] https://github.com/fsharp/fslang-suggestions/issues/506
>
> I am looking forward to hearing your feedback!
>
> Agustín Zubiaga
> Head of Engineering @ PINATA
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Proposal: Property Accessor Function Shorthand
Hi folks! I'd like to hear your feedback on a proposal idea I have and that I
couldn't find anything on. Here is what I have so far.
With the rising popularity of functional programming patterns in JavaScript,
functions that take an object and return the value of a property are
ubiquitous. These are some popular examples:
```js
// filtering by a boolean property
const activeProducts = products.filter(product => product.active);
// mapping
const productNames = products.map(product => product.name);
// sorting, grouping, etc
const sortedProducts = _.sortBy(products, product => product.name);
const { true: activeProducts, false: inactiveProducts } = _.groupBy(
products,
product => product.active
);
```
This pattern is so common in fact that libraries like `lodash` (and frameworks)
often also accept passing the name of the property as a string:
```js
const sortedProducts = _.sortBy(products, "name");
```
However, this technique has various problems:
1. It requires extra code from the library authors. With its typical
disadvantages.
2. It has a potential negative impact on performance.
3. It is not easily statically analyzable, which makes it hard to type-check,
infer, and for tooling to catch typos.
Several languages have solved these problems by introducing some syntactic
sugar that simplifies the definition of these functions. My favorite example is
Elm's: `.property` shorthand [1]. If JavaScript supported this syntax, we could
write the previous examples as:
```js
const activeProducts = products.filter(.active);
const productNames = products.map(.name);
const sortedProducts = _.sortBy(products, .name);
const { true: activeProducts, false: inactiveProducts } = _.groupBy(products,
.active);
```
This is, in my opinion, nice to read and write. Besides, since this expression
simply yields a function, it would not have any of the problems the string
approach has.
Combined with the pipeline operator proposal, it would allow code like the
following:
```js
orders
|> filter(.active)
|> flatMap(.products)
|> .length
```
Lastly, engines might be able to optimize this further (or more easily) than
normal functions since functions defined this way would be restricted to
returning a constant property of the object that is passed to them. They would
not be able to have any other expressions or statements in them. Unfortunately,
they would not be considered automatically pure because users can implement
side effects in property getters or Proxies.
I could not think of any syntax ambiguity this could cause, but I would
appreciate your thoughts in this regard. It does look similar to the RHS of a
Member Expression, but it would not be ambiguous because the two would not be
allowed under the same contexts. The F# community has had an interesting
ongoing conversation [2] about the topic, but it is my understanding we would
not have these problems in JavaScript since Call Expressions require
parenthesis.
[1] https://elm-lang.org/docs/syntax#records
[2] https://github.com/fsharp/fslang-suggestions/issues/506
I am looking forward to hearing your feedback!
Agustín Zubiaga
Head of Engineering @ PINATA
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: `await.all {...}` for parallelism
Hi! It does not change the meaning of the ";" at all. As you may already
know, omitting `await` already invokes multiple async function calls in
parallel, in current JavaScript, so absolutely no change in that respect.
The only thing this `await.all` suggestion does, is ensure that all
non-awaited async function calls are completed before proceeding beyond the
end of the block.
i.e. it adds fairly straightforward and terse deterministic control to
otherwise non-deterministic code, without requiring knowledge of
destructuring or `Promise.all`.
On Sat, 23 Nov 2019 at 13:25, Tom Boutell wrote:
> This is very interesting, but this code:
>
> await.all {
>x = getXAsync();
>y = getYAsync();
> }
>
> processXAndY(x, y);
>
> Still carries within it the problem that if I'm looking at just the middle
> of the { ... } block — if "await.all" has scrolled offscreen — I'll be
> completely wrong about what ";" means. I think that's too much magic.
>
> Also, in the case of the "for" loop, this doesn't address managing the
> level of concurrency. Although it could in theory with a syntax like
> await.all({ concurrency: 5 }), I'm not sure if it's practical to implement
> that for your general case.
>
> Actually I'm curious about what the implementation would look like in
> general. If it were babel compiling this, I guess it would have to wrap
> every statement not preceded by "await" with a check for whether it returns
> a thenable and add it to an array if it does. But with the concurrency
> feature it would also have to defer executing the code at all until the
> right time as otherwise we're still starting zillions of "processes" at
> once.
>
>
> On Sat, Nov 23, 2019 at 5:08 AM Naveen Chawla
> wrote:
>
>> However, if `await.all { ... }` were to mean "wait for all non-awaited
>> async function calls made within this block to complete before proceeding",
>> as I suggested earlier, I think that could satisfy determinism for "await"
>> wherever it is used, and satisfy the original motivation:
>>
>> ```
>> await.all {
>> for (const item of items) {
>> doTheThingAsync(item);
>> }
>> }
>> ```
>>
>> Notice I have omitted `await` inside the loop. Like current JavaScript,
>> that causes parallel execution, so no change on that front, from a
>> determinism perspective. So determinism is not hurt by `await.all`. Rather,
>> it guarantees completion before going further.
>>
>> In an earlier example (paraphrase-coded as I forgot the names):
>>
>> ```
>> let x, y;
>>
>> await.all {
>>x = getXAsync();
>>y = getYAsync();
>> }
>>
>> processXAndY(x, y);
>> ```
>>
>> I think the benefit of this syntax appears more stark with the looped
>> (first) example, as current JavaScript requires building an array in the
>> loop to subsequently pass to `Promise.all`, which I think is a little more
>> difficult to conceptualize than the `await.all { ... }` way of doing it.
>> The 2nd example is arguably better than current JavaScript too,
>> particularly because the coder doesn't have to be very smart with
>> destructuring in light of understanding the "Promise.all" return type, etc.
>> In other words, less cognitive overhead, which I think is a net positive.
>>
>> On Fri, 22 Nov 2019 at 13:44, Tom Boutell wrote:
>>
>>> I am very sympathetic to pitches to allow more common cases for promise
>>> libraries to be written in an "awaitful" syntax without thinking explicitly
>>> about promises.
>>>
>>> Howeever I think that changing the meaning of the semicolon in a
>>> particular context has too much potential for confusion. As others have
>>> said, parallel execution is different, and it should look and feel
>>> different. The most basic assumption a developer makes (consecutive lines
>>> of code run consecutively) is difficult to get away from; that's why we
>>> introduced "await" in the first place, to bring back the ability to write
>>> deterministic code with consecutive statements. Which sounds like a
>>> reasonable ask, when it's put that way. (:
>>>
>>> I did propose this recently:
>>>
>>> for (const item of items concurrency 5) {
>>> await doTheThing(item);
>>> }
>>>
>>> However in this case I'm not talking about consecutive statements, I'm
>>> only talking about rules for simultaneously (in the sense of async, not
>>> threads) running more than one instance of the block. So I'm not proposing
>>> that we change the meaning of the semicolon(s) *within* the block in a way
>>> that could mean that if you're looking at half the code in the middle you
>>> would be likely to fundamentally misunderstand its operation.
>>>
>>> I think that risk - that you can't tell what a semicolon means without
>>> reference to the outer context - is what makes your proposal a bridge too
>>> far for me.
>>>
>>>
>>> --
>>>
>>> THOMAS BOUTELL | CHIEF TECHNOLOGY OFFICER
>>> APOSTROPHECMS | apostrophecms.com | he/him/his
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> http
