-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skip mark #53
Comments
I worry that amidst the criticism of the confusing undefined in js, we will consider a additinal void - "empty". I suppose to call this symbol in agreement with the meaning it brings - Symbol.skip |
Good idea @artalar |
I have next sugar proposal for
what about hugeList.forEach(x -> doSome(a.b.c.d, x)) or hugeList.forEach(x ==> doSome(a.b.c.d, x)) or hugeList.forEach(x <=> doSome(a.b.c.d, x)) And as a bonus, we can rearrange Array.prototype.forEach's callback arguments arr.forEach((e, i) -> doSome(e, a.b.c, i)) or even arr.forEach((_, i) -> doSome(i, a.b.c.d)) which is not possible with a |
Also we need something like Symbol.skipAll for rest and Symbol.skipFor(indexOfArgument) Sorry for humour |
But seriously: somePromise.then((cached => r => cb(r, cached))(otherParam))
hugeList.forEach((abcd => e => doSome(abcd, e))(a.b.c.d)) Or just move a computation to a variable above, as you already wrote. Explicit is better
flatMap?
list.reduce((acc, v, i) => i < 5 ? acc + v : acc, 0) Or in last case it's like an imperative break? Symbol.break🤔 |
You need dedicated syntax to do this without cleaving the existing ES value space into two new value spaces, the “ES values that can be used as arguments” value space and the “notional absence of such an argument value” value space. The partial application syntax should be compatible with arbitrary functions, so a first-class value acting as sentinel is the wrong level of abstraction; the functions are callable with any ES values as arguments, but the sentinel value ends up conditionally second-class depending on the application mechanism used. This becomes particularly problematic for anything higher-order that would sometimes need to analyze what would have been “pass-through” arguments to distinguish “real argument values” from the sentinel value. Broadly it would break reflection of function application —
— as the name chosen doesn’t change that it’s effectively moving the “nulls treadmill” further along. The syntactic solution for “skipping” in the current proposal avoids the problems that would arise if a new “not-a-value” runtime value controlled the behavior. |
This is known as the spaceship operator in PHP—so, this could be confusing
This resembles CoffeeScript's (arrow) functions and therefore, might be mistaken therefor.
No usage for this one comes to my mind, however, while it can be seen as a benefit that it looks similar to usual arrow function calls, these two could be confused with each other, which might make it harder for beginners to learn the difference. In #44, @pepkin88 talked about |
Hi! This proposal describes an interesting pattern with a few features and few of them is missed in the readme.
Reference transparency
One of the benefits of this codestyle is referential transparency, which mean that you nave NO unexpected issues with "value" mutation (if it "let" or "var", or some property). "resolve" will be called with exactly the passed "value" data, not with "value" state in the call time.
Unfortunately, almost none other APIs follow this arguments pattern. For example, you couldn't do this:
somePromise.then(cb, otherParam)
. Partial application solves it:somePromise.then(cb~(?, otherParam))
.Reduce of extra computations
Here we have a complex data access (
a.b.c.d
) which could take some performance impact. Inline caches from an engine could solve it, until it comes to some computation, likesome.getFrom('wat', 'wot')
. Commonly, a good practice is moving a computation to a variable above, but this extra work is not cosy and a developer could forget about it.This proposal solve it perfectly and it awesome, as I think.
Syntax
But adding an extra syntax for this feature is not worth it, from my side.
In other side, the main problem for implementing it as a new prototype method is that we need a way to mark empty arguments (
?
). What options do we have?I propose to use special symbol for that (and lets call new method
tie
)Lazy operations
But that's not all!
We could reuse the symbol to perform other lazy operations:
What do you think?
The text was updated successfully, but these errors were encountered: