| 14:14 | <jschoi> | If anyone has any grammar suggestions with regards to https://github.com/js-choi/proposal-bind-this/issues/14#issuecomment-944697033, please let me know on the issue. That is, I’m stumped on how we could loosen the bind- this operator such thata.b::c.d() would unambiguously parse as((a.b)::(c.d))() (that issue’s goal) and not(a.b)::((c.d)()) (useless) or((a.b)::c).d)() (the current behavior).For any recursive production I can think of that would cover c.d, that production would also cover c and/or c.d()… |
| 14:49 | <TabAtkins> | I can see why the third parse isn't useful (tho I think it's what I would naively expect, treating :: as an alternative dot), but I'm not sure why you'd want the first parse over the second. |
| 14:49 | <TabAtkins> | It doesn't seem like it's what rbuckton is asking for in that issue, either |
| 15:33 | <jschoi> | TabAtkins: Yeah, sorry, I meant to make the goal grouping ((a.b)::(c.d))() and not (a.b)::((c.d)()); I’ve edited my message.The problem is that I can’t figure out how I’d make a grammar that makes …::… looser than ….… while making …::… still as tight as …(…). |
| 15:35 | <ljharb> | fwiw while i think a::Array.prototype.map is nice, 100% of the actual use cases i have all involve caching the method beforehand, so a::(Array.prototype.map) doesn’t seem that bad, if you can’t figure out a solution. |
| 15:52 | <jschoi> | If we do end up figuring out how to make a.b::c.d() unambiguously group as ((a.b)::(c.d))(), then I think that RHS chain-of-property-identifiers expression is similar enough to decorators’ syntax that they should share a production, named something like SimpleMemberExpression. |
| 16:42 | <jmdyck> | Maybe change CoverCallExpressionAndAsyncArrowHead to be SomethingExpression Arguments, then define SomethingExpression to be MemberExpression or MemberExpression :: MemberExpression |
| 16:47 | <TabAtkins> | I think I'm with ljharb on this: if you're not caching the functions into an ident, you're really losing the semantic connection with foo.bar() syntax, and might as well just be writing the function to take the value as a first arg instead |
| 16:51 | <TabAtkins> | (I'm still not quite convinced :: pulls its weight, with `foo.bar~()` solving the auto-bind case and pipeline making it easy to linearize. All that's left is this "rip off methods and call them on something else" case, and honestly `const map = Array.prototype.map.call~(...)` solves that well enough imo.) |
| 16:55 | <ljharb> | That presumes PFA pulls its weight tho for non-bind use cases, which I’m not convinced on. |
| 17:46 | <TabAtkins> | Sure. But between the two, they cover a total of four major use-case categories (implicit binding, fluent importable methods, partial application, tear-off methods). PFA covers 1, 3, and can pretty easily convert 4 into 2 (with pipeline covering 2 and the rest of 4), while bind-op covers 1, 2 (if you import them as plain names, or we solve the parsing issues), and 4, with nothing else covering 3. |
| 17:47 | <TabAtkins> | Plus bind-op, by covering 2, overlaps with pipeline (and somewhat also in 4). |
| 17:48 | <TabAtkins> | So, looking at these just as lego blocks we want to jam together, I'm finding PFA+pipeline a wider, more efficient cover for the use-cases than bind-op. |
| 17:51 | <TabAtkins> | I also think PFA has a nicer "single story to tell" - it does one thing and does it well; all the use-cases it covers are obvious realizations of that one thing (binding arguments to a call ahead of time). Bind-op can be seen as doing one thing (binding the receiver for a function, which may or may not be immediately called), but in practice its uses are thematically linked but practically distinct - implicit binding and fluent/tear-off invocations are completely different usage patterns. |
| 20:11 | <jschoi> | Looking at the results of https://github.com/js-choi/proposal-bind-this/issues/12, I don’t think most current uses of .call (which is extremely common) would be improved with PFA syntax. |
| 20:12 | <jschoi> | I will try to make this clear in the slides, although I don’t think that this concern should block Stage 1 anyway. |
| 23:00 | <devsnek> | i think trying to figure out the right syntax is kind of a red herring here |
| 23:00 | <devsnek> | because you should definitely 100% use parens when writing that code |