| 17:39 | <littledan> | The Jitsi room is open. Let me know if you have trouble joining or any other technical issues |
| 18:00 | <michaelficarra> | were we not continuing the Temporal topic today? |
| 18:01 | <ljharb> | looks like it's on the draft schedule for after lunch |
| 18:01 | <ljharb> | (due to schedule constraints requiring some of these things being in the morning) |
| 18:02 | <robpalme> | correct |
| 18:13 | <TabAtkins> | +1 on being explicit, precedence is the devil when working in new spaces like this |
| 18:18 | <michaelficarra> | I didn't realise this proposal would integrate with sequence properties like this |
| 18:18 | <michaelficarra> | it seems really hazardous |
| 18:19 | <TabAtkins> | Oooh I was hoping that someone would propose "Just add a gd parser proposal", nice |
| 18:20 | <TabAtkins> | i'm behind a built-in parser-combinator library, even if it's just regex equivalent right now |
| 18:23 | <michaelficarra> | TabAtkins: it's not like parser combinator libraries are big, you can just ship one |
| 18:24 | <TabAtkins> | Of course, but regexes are built in. If we want to ensure people have the same power, without forever extending regexes to ever more intricate syntax, we need to match the built-in-ness. |
| 18:25 | <TabAtkins> | I mean, right on this topic - union/intersection/etc is very easy to apply in a parser combinator, but we're adding it to regex bc that's what we have in the language. |
| 18:28 | <rbuckton> | I have a lot more regexp syntax features I plan to propose in the future, all based on prior art in other languages and have been putting together a comprehensive comparison between all major regexp engines. |
| 18:32 | <Bakkot> | someone fill out the header in the notes please? |
| 18:39 | <leobalter> | ljharb Bakkot thanks! Somehow I thought we should be assigning reviewers as well. |
| 18:39 | <mmarchini> | Error causes is speedrunning proposal advancement :D |
| 18:39 | <leobalter> | mmarchini: |
| 18:39 | <leobalter> | oops |
| 18:40 | <ljharb> | leobalter: at this point the only reviewers are test262 maintainers and 262 editors :-) |
| 18:40 | <leobalter> | mmarchini: I saw things going so much faster this seems a okay pacing |
| 18:41 | <mmarchini> | Yeah that's the first proposal I saw reach stage 3 on the third meeting |
| 18:41 | <mmarchini> | But wouldn't be surprised by faster ones |
| 18:41 | <TabAtkins> | omigod this is such a better name |
| 18:43 | <ljharb> | jridgewell: oof, how does amp depend on that? |
| 18:43 | <jridgewell> | Part of amp-script exports blessed functions on a global |
| 18:43 | <jridgewell> | Doing something like `exports[fn.name] = fn` |
| 18:44 | <ljharb> | and amp-script is deployed on user-controlled sites? |
| 18:44 | <jridgewell> | Yes |
| 18:45 | <ljharb> | bummer, ok |
| 18:45 | <jridgewell> | We could update, but it's just the web compat risk is real |
| 18:45 | <ljharb> | right |
| 18:45 | <ljharb> | seems ideal for amp-scripts to update to not rely on function names in general, but doesn't remove the compat risk. |
| 18:53 | <Bakkot> | I definitely read "race" to be "scary" |
| 18:53 | <Bakkot> | I know not everyone does |
| 18:53 | <Bakkot> | but I sure do |
| 18:53 | <rkirsling> | agree |
| 18:54 | <rkirsling> | or if not "scary" it's at least an "eff it, who cares what happens" vibe |
| 18:55 | <ljharb> | to me "any" gives that vibe |
| 18:55 | <Bakkot> | do we have an acronym for this presenter? |
| 18:56 | <Bakkot> | someone has written "WWG" so I assume that's right |
| 18:57 | <michaelficarra> | Bakkot: we don't, so we should ask them to add an entry to delegates.txt at the end of the topic |
| 18:58 | <bterlson> | I have done so |
| 18:58 | <bterlson> | WWG is someone else I think, fwiw :( |
| 18:58 | <haxjs> | should be WWL as his name |
| 18:58 | <bterlson> | https://github.com/tc39/notes/pull/97 |
| 18:59 | <michaelficarra> | remember to assign reviewers! |
| 19:00 | <bterlson> | Bakkot: it's KWL in case you missed this :-D |
| 19:02 | <leobalter> | is Wenlu or Daniel R. in this channel? I tried many times to volunteer as a reviewer, but I was double muted |
| 19:03 | <ljharb> | leobalter: i don't think either is, but i think maybe robpalme could interject briefly to add you as a reviewer after this presentation? |
| 19:03 | <robpalme> | sure |
| 19:04 | <bterlson> | robpalme: leobalter: I've let wenlu know you cna review |
| 19:04 | <ljharb> | (i think it still needs to be in plenary notes tho) |
| 19:05 | <leobalter> | ljharb: I'll reach them through the proposal repo |
| 19:05 | <leobalter> | bterlson: thanks! |
| 19:06 | <leobalter> | ljharb: I can do it informally, unless we need 3 reviewers |
| 19:13 | <michaelficarra> | leobalter: we prefer to have 2 non-editor reviewers, so it is welcome |
| 19:14 | <leobalter> | Jordan and Yulia are already assigned, I'd be the 3rd one. |
| 19:17 | <michaelficarra> | oof, reading the length as a way to explicitly synchronise? |
| 19:19 | <michaelficarra> | there must be a better way to communicate that intent |
| 19:59 | <littledan> | yay pipeline! |
| 20:18 | <Bakkot> | gotta run an errand. I expect to be back in time but if not I've set the bot to start itself up again in 30 minutes |
| 20:54 | <Bakkot> | ok back we're good |
| 21:17 | <jridgewell> | These slides are great |
| 21:20 | <michaelficarra> | well I wish the colours for the different execution orders weren't basically identical |
| 21:24 | <jridgewell> | It's a breadth-first upwards traversal |
| 21:25 | <Bakkot> | what was shu saying? "a serial"? |
| 21:25 | jridgewell | /shrug |
| 21:26 | <shu> | a serial, yes |
| 21:26 | <shu> | like a monotonic increasing number |
| 21:28 | <jridgewell> | Is this any more difficult than changing a depth-first to a breadth-first? |
| 21:33 | <shu> | jridgewell: yes |
| 21:34 | <jridgewell> | How so? |
| 21:35 | <shu> | jridgewell: i might've misread your question, now i no longer know |
| 21:35 | <shu> | maybe after this preso |
| 21:35 | <jridgewell> | 👍 |
| 21:40 | <bterlson> | https://usercontent.irccloud-cdn.com/file/iqZfwHob/queue.png |
| 21:40 | <bterlson> | ^^ saved temporal queue |
| 21:44 | <littledan> | btw the slides were prepared based on the old queue already |
| 21:45 | <bterlson> | littledan: objection to going through the replies to make sure the questions are answered? |
| 21:45 | <littledan> | no, no objection |
| 21:47 | <bterlson> | so noted :-D |
| 21:49 | <Bakkot> | I just realized there's two temporal champions speaking |
| 21:49 | <Bakkot> | I don't know which they are |
| 21:49 | <Bakkot> | I've been attributring everything to PFC in the notes |
| 21:49 | <Bakkot> | if someone knows who the speakers are please help fix up the notes |
| 21:51 | <ljharb> | phillip dunkel and phillip chimento |
| 21:51 | <ljharb> | the one who just talked to mark is dunkel |
| 21:52 | <Bakkot> | oh jeeze there's two phillips |
| 21:52 | <Bakkot> | which one is now? |
| 21:52 | <littledan> | philip chimento is the main speaker |
| 21:52 | <littledan> | within the champion group, they can be differentiated by ptomato vs pdunkel, or alternatively, Philip vs Philipp |
| 22:15 | <Bakkot> | definitely agree with haxjs that the original naming issue should've been bumped |
| 22:15 | <Bakkot> | not the end of the world, it's hard to keep track of these things, just something for people to try to be aware of in the future |
| 22:15 | <ljharb> | that's what i heard as well; not really about twitter, but about notification of changes |
| 22:16 | <haxjs> | Yeah, it make me too late to back to the discussion. |
| 22:16 | <ljharb> | and tbh it's tough to follow the entire repo when the majority of the activity isn't directly related to the spec |
| 22:17 | <haxjs> | Another point is the poll sample is too small, if we want to do poll to get some data, we need a guide to make sure we do the poll in right way. not like that. |
| 22:25 | <rbuckton> | FYI: "Hack" style refers to the Hack programming language: https://docs.hhvm.com/hack/expressions-and-operators/pipe |
| 22:25 | <TabAtkins> | "Tab's Essay" is https://gist.github.com/tabatkins/1261b108b9e6cdab5ad5df4b8021bcb5 |
| 22:26 | <Bakkot> | wish "hack style" were called "topic variable" instead |
| 22:27 | <Bakkot> | too late now ofc |
| 22:27 | <rbuckton> | "topic style" |
| 22:27 | <haxjs> | Most fp guys (i mean who use lodash/fp or ramda or similar libs) i know prefer F# style much than topic style... |
| 22:28 | <TabAtkins> | haxjs: Well obviously ^_^ |
| 22:28 | <haxjs> | But guys who not heavy fp guys sightly prefer topic style --- this is what i found. |
| 22:29 | <TabAtkins> | Bakkot: I pushed for the "Lang-style" naming to avoid the value judgement of "minimal proposal" |
| 22:29 | <ljharb> | i believe most JS users are not "heavy FP users" |
| 22:29 | <TabAtkins> | "version that explicitly privileges higher-order programming over all other syntax" is popular with people who like using higher-order programming heavily, news at 11. ^_^ |
| 22:30 | <rbuckton> | I am still very bullish on partial application and its value with or without pipeline. |
| 22:30 | <rkirsling> | moreover "heavy FP users" is not the same thing as "heavy users of FP within JS" |
| 22:30 | <wsdferdksl> | Would you need to await all the rest of the operands of |>? |
| 22:31 | <TabAtkins> | nope, no more than you'd need to await all following statements in normal code flow |
| 22:31 | <haxjs> | We have another choice, let avg user use extensions like `x :: extMethod()` and let heavy fp users use F# style pipeline op. Both will happy. |
| 22:31 | <TabAtkins> | The :: as this-piping operator is even worse :( |
| 22:31 | <ljharb> | haxjs: average user use is more likely to be in between those - not heavy FP, but also not this-using |
| 22:31 | <wsdferdksl> | What does x |> await do? |
| 22:31 | <rbuckton> | for what its worth, `(await (x |> f)) |> g` is no less complex than `(await x.f()).g()` |
| 22:32 | <rbuckton> | wsdferdksl: it's a special form that awaits the input and passes it to the output |
| 22:32 | <jridgewell> | wsdferdksl: same as `await x`? |
| 22:32 | <haxjs> | ljharb: extensions is designed to make avg user not worry about `this` anymore. |
| 22:32 | <rbuckton> | `x |> f |> await |> g` is equivalent to `(await (x |> f)) |> g` |
| 22:32 | <jridgewell> | With `x |> await |> y` being `y(await x)` |
| 22:33 | <ljharb> | haxjs: right; there's an open issue where we're discussing that, and it is very much not clear that there's consensus on the motivation for that |
| 22:34 | <ljharb> | haxjs: iow, the original bind operator was about being able to easily use this-sensitive functions in a chain without installing properties, which doesn't obviate the need to know how `this` works |
| 22:34 | <rbuckton> | I've always argued F# pipes are fairly simple `x |> F` is essentially `F(x)`, and that partial application dovetails into that well. |
| 22:34 | <rkirsling> | it's not possible to "omit placeholders initially" though...? |
| 22:34 | <ljharb> | rkirsling: in the F# one i think it is |
| 22:34 | <ljharb> | rkirsling: but not in hack, obv |
| 22:35 | <rkirsling> | placeholders are the more basic proposal though I mean |
| 22:35 | <haxjs> | ljharb: yeah, the original bind op still need user know too much about `this`. So I try to find some way to solve that in extensions proposal. |
| 22:35 | <rbuckton> | F# without placeholders would block hack-style. |
| 22:35 | <rbuckton> | s/F#/F#-style |
| 22:35 | <ljharb> | haxjs: right, but that's not something i consider a problem (and thus not something to be solved), but i have a strong need to be able to chain methods on a receiver without having them present on the object :-) |
| 22:36 | <Bakkot> | rbuckton how so? |
| 22:36 | <Bakkot> | rbuckton assuming hack-style has a requirement that `?` appears on the RHS |
| 22:36 | <TabAtkins> | To avoid easily mistakes, Hack-style requires a placeholder, yeah. |
| 22:36 | <rkirsling> | oh no robot |
| 22:36 | <rbuckton> | Bakkot: IIRC, hack-style doesn't support point-free? That's where "smart mix" came from |
| 22:37 | <Bakkot> | rbuckton right |
| 22:37 | <Bakkot> | so it doesn't overlap with F# without placeholders, right? |
| 22:37 | <rbuckton> | If this feature will ever move forward, we need to pick one direction. |
| 22:37 | <Bakkot> | oh, sure |
| 22:38 | <Bakkot> | I thought you meant that it was technically impossible, not that it was a bad idea |
| 22:38 | <rbuckton> | Bakkot: I'm not sure what you mean about it doesn't overlap. |
| 22:38 | <haxjs> | ljharb: yes, extensions also can achieve that. The only point here is extensions is optimized more for oo-style (like lodash) and pipeline op is (i hope) optimized more for fp-style (like lodash/fp). |
| 22:38 | <Bakkot> | rbuckton: like, technically, you can disambiguate them, yes? |
| 22:38 | <Bakkot> | not "is it a good idea to have both", just, technically I don't see a problem disambiguating |
| 22:38 | <ljharb> | haxjs: most of the use cases i have or have seen in codebases for pipeline aren't point-free (ie, the FP unary function style) |
| 22:39 | <michaelficarra> | can you use the placeholder more than once in the RHS? |
| 22:39 | <rbuckton> | F# actually allows multiple arguments in pipes, but we didn't propose that yet. |
| 22:39 | <rbuckton> | (if ever) |
| 22:39 | <rbuckton> | michaelficarra: in Hack or in partial application? |
| 22:39 | <rkirsling> | michaelficarra: sure, 'cause you're never subbing two different things |
| 22:40 | <michaelficarra> | in Hack |
| 22:40 | <haxjs> | ljharb: point-free style guys bascily use a very special libs like ramda so how common u see such code depend on whether u are a ramda or lodash/fp fans :) |
| 22:41 | <ljharb> | haxjs: right - i'm saying i don't find "usage of ramda or lodash/fp" very common |
| 22:41 | <ljharb> | haxjs: obv that's just my personal experience |
| 22:41 | <rkirsling> | I echo the confusion that Tab is expressing |
| 22:42 | <haxjs> | ljharb: But I feel many strong supporters of pipeline op are coming from that world. |
| 22:43 | <rkirsling> | I don't see how it can possibly be argued that F# is simpler |
| 22:43 | <rkirsling> | regardless of which you prefer |
| 22:43 | <rbuckton> | To me, "Hack-style" doesn't add any new capability to the language we don't already have, which decreases its motivation to me. |
| 22:43 | <ljharb> | rbuckton: neither does partial application |
| 22:43 | <TabAtkins> | rbuckton: F#-style doesn't either. They're both identical in terms of expressiveness. |
| 22:43 | <TabAtkins> | literally 100% identical (so long as `await` is handled by F#) |
| 22:44 | <Bakkot> | (and yield) |
| 22:44 | <rbuckton> | I've already shown you can do "Hack-style" in JS today with `,`. I like F# because it adds something new. |
| 22:44 | <rbuckton> | (again, I meant F#-style) |
| 22:44 | <ljharb> | rbuckton: only with intermediate variables |
| 22:44 | <ljharb> | rbuckton: or am i missing something |
| 22:44 | <haxjs> | It's not about expressiveness, it's about developer experiences... |
| 22:44 | <Bakkot> | these are all just sugar |
| 22:44 | <ljharb> | rbuckton: also because of the declaration, it can't be done in one line |
| 22:46 | <rbuckton> | I disagree that partial application doesn't add anything new. We have `.bind` and arrow functions, but `.bind` only supports leading arguments, and arrow functions defer evaluation. |
| 22:46 | <rbuckton> | `add(?, x())` returns a function where the result of `x()` has already been evaluated and bound to an argument. Doing that today requires a lot more boilerplate. |
| 22:47 | <ljharb> | rbuckton: yet it's capable today, thus, it's not a new ability, it's just sugar. |
| 22:47 | <ljharb> | rbuckton: i'm not arguing against partial application, i'm arguing against "not a new capability" as making a syntactic proposal less useful or important. |
| 22:47 | <ljharb> | (inherently) |
| 22:51 | <bterlson> | Seen many LINQ in JS approaches. It's more than just threading fwiw, you often want to assemble some kind of query plan that can be send wholesale to the database to execute. |
| 22:52 | <shu> | bterlson: yeah, i find it compelling, especially the "it's only a burden to have to think about what to name the subparts of the query" |
| 22:52 | <shu> | the query is somehow this indivisible thing mentally |
| 22:52 | <bterlson> | a big part of this story fwiw is how to send simple predicates to the server |
| 22:53 | <bterlson> | that is maybe a key capability we should investigate |
| 22:53 | <shu> | what's meant by "send simple predicates to the server?" |
| 22:53 | <bterlson> | so I see linq-like syntaxes like |
| 22:53 | <bterlson> | query.select("x, y").where("x > 10") |
| 22:54 | <bterlson> | the problem they are trying to solve here is to let the server handle any projection and filtering so you don't send way more data to clients than you need |
| 22:54 | <Bakkot> | that was mark's whole project with the deferred send thing, or whatever it was called |
| 22:55 | <rbuckton> | C#'s LINQ relies on type information, where if you pass an arrow function to an argument expecting a specific type, the compiler returns an "Expression Tree" which is a simplified AST representation of the arrow function that can be converted into, say, a SQL WHERE clause. |
| 22:55 | <TabAtkins> | yeah LINQ is something totally else |
| 22:56 | <shu> | TabAtkins: the implementation certainly is a different beast, but isn't that usage pattern generally what you want to enable? |
| 22:56 | <shu> | bterlson: i see, thanks |
| 22:56 | <TabAtkins> | I don't even know what LINQ's usage pattern really is. |
| 22:56 | <rbuckton> | I'm always concerned that introducing topic variables introduces scoping complexity. |
| 22:56 | <rbuckton> | TabAtkins: essentially generator comprehensions |
| 22:57 | <TabAtkins> | I just want linear code flow, like what method chaining gives me. |
| 22:57 | <shu> | TabAtkins: my very surface understanding is that it's the database query equivalent of parser combinators, kinda |
| 22:57 | <ljharb> | a topic variable does mean that one pipeline nested into another is tricky |
| 22:57 | <rbuckton> | using `FLWOR`-like syntax. |
| 22:57 | <TabAtkins> | Yeah, nesting pipelines is a "don't do that" sort of thing honestly |
| 22:57 | <TabAtkins> | "doctor it hurts when I do this" |
| 22:57 | <shu> | the answer used to be "don't do this" |
| 22:57 | <shu> | the answer now sometimes is "you have gotten older" :(( |
| 22:58 | <ljharb> | shu: too real |
| 22:58 | <rbuckton> | ``` |
| 22:58 | <rbuckton> | let result = |
| 22:58 | <rbuckton> | from x in ar |
| 22:58 | <rbuckton> | where x.foo > 1 |
| 22:58 | <rbuckton> | orderby x.bar ascending |
| 22:58 | <rbuckton> | select x.baz; |
| 22:58 | <rbuckton> | ``` |
| 22:58 | <TabAtkins> | "as a language gets older, it starts getting painpoints in places that used to be fine" |
| 22:58 | <rkirsling> | lol |
| 22:58 | <ljharb> | ohno |
| 22:59 | <rkirsling> | I mean I want to say it's as simple as "if your expression requires parens, you should be breaking it up" but |
| 22:59 | <rkirsling> | I know that it's easy to find counterexamples |
| 22:59 | <jridgewell> | So many Justins now. |
| 22:59 | <wsdferdksl> | rbuckton: Don't forget the `limit 100`. |
| 23:00 | <shu> | wsdferdksl: i once forgot to limit 10000 or on https://httparchive.org/ query, ran up a several hundred dollar gcp bill :( |
| 23:00 | <shu> | luckily it was free as a googler, but still |
| 23:01 | <msaboff> | bterlson: Do you know if the 2021 opt out period has started? |
| 23:01 | <bterlson> | msaboff: it has |
| 23:01 | <ljharb> | msaboff: theoretically it began yesterday |
| 23:01 | <msaboff> | For how long? |
| 23:01 | <shu> | istvan said today or yesterday right |
| 23:01 | <wsdferdksl> | We need published ECMA documents for the opt-out period |
| 23:01 | <ljharb> | right, pending that |
| 23:01 | <ljharb> | msaboff: 2 months i believe |
| 23:02 | <shu> | msaboff: ends May 10 |
| 23:02 | <msaboff> | When do we think the ECMA documents will be published? |
| 23:02 | <rkirsling> | June 22 is the GA date |
| 23:02 | <Bakkot> | they said they were published today |
| 23:02 | <Bakkot> | the opt-out ones, anyway |
| 23:02 | <msaboff> | Thanks |
| 23:02 | <TabAtkins> | I am still always *so curious* what people mean when they say Hack-style looks more implicit. What magic are y'all thinking is happening? |
| 23:03 | <TabAtkins> | I'm fully over in the "too knowledgeable to understand first-learners" camp now unfortunately. |
| 23:03 | <rkirsling> | yeah, "explicit" is the definition of what Hack-style is |
| 23:04 | <rbuckton> | littledan: FYI, I disagree with the con regarding "garden path" to partial application. While it was brought up by Waldemar when I initially proposed the feature, I've presented on how that concern isn't new to the language given destructuring. |
| 23:07 | <bterlson> | msaboff: just making sure, did istvan answer your questions re: opt-out? If it helps the ECMA document number is Ecma/TC39/2021/012. |
| 23:08 | <msaboff> | Yep. Thanks |
| 23:10 | <TabAtkins> | rbuckton: Hm, how is destructuring an example of it already existing? |
| 23:15 | <rbuckton> | The "garden path" concern was that, without some kind of leading syntax a user wouldn't know whether a call expression was an invocation or a partial application until they see the `?`, which could be arbitrarily far down the argument list. The same is true for existing language features such as array destructuring: |
| 23:15 | <rbuckton> | ``` |
| 23:15 | <rbuckton> | [a, b, c, d, e, ...f] = g |
| 23:15 | <rbuckton> | ``` |
| 23:15 | <rbuckton> | The above looks like an array until you reach the `=`. |
| 23:16 | <rbuckton> | As well as arrow functions: `(a, b, c = d) => e` could just be a comma list until you get to the `=>`. |
| 23:16 | <haxjs> | good example, but there is a little difference. destructuring normally start with `const` / `let`. |
| 23:16 | <rbuckton> | Its not a new issue, and wasn't blocking for arrow functions or destructuring. |
| 23:17 | <TabAtkins> | rbuckton: I mean, *technically* yes, but in practice starting a line with an array or object literal is a *very* strange thing to do. |
| 23:17 | <TabAtkins> | So in practice it's not a garden path at all, you just always assume that a line-starting `[` or `{` means destructuring is happening |
| 23:17 | <rbuckton> | Tab, true, but `a = [b, c, d] = e` is also legal javascript. |
| 23:17 | <haxjs> | And arrow function normally in the position of expression, so people can recognize it in the first place. |
| 23:17 | <wsdferdksl> | rbuckton: It's not quite the same thing. |
| 23:17 | <TabAtkins> | Again, legal, but *weird* |
| 23:18 | <TabAtkins> | Like, nobody writes that ^^_ |
| 23:18 | <haxjs> | So they do not have garden path issue in practice, at least in most cases. |
| 23:18 | <wsdferdksl> | If you could write [a + b, f(x)*g(y) + 17, "foo", d+e] = g and have it change the meaning of subexpressions, it would be worse |
| 23:19 | <rbuckton> | wsdferdksl: My point is that `?` doesn't change the fact that `f(?)` still returns a value like a call expression would, while `[a, b, c] = d` completely changes the meaning. Also, `f(?, g())` still eagerly calls `g()`. |
| 23:19 | <wsdferdksl> | And that's my beef with the garden path variants of the proposal. |
| 23:19 | <haxjs> | Note I don't think garden path issue is very serious, just want to clarify. |
| 23:21 | <wsdferdksl> | rbuckton: There would be pressure from folks to write things like f(g(), ? + 3). |
| 23:21 | <wsdferdksl> | What gets evaluated when gets messy really fast |
| 23:21 | <rbuckton> | wsdferdksl: I'm aware, which is why some prefer the "Hack-style" for pipelines |
| 23:21 | <haxjs> | Isn't that a syntax error? |
| 23:22 | <wsdferdksl> | haxjs: Everything we're discussing is currently a syntax error |
| 23:22 | <haxjs> | I mean it 's a syntax in partial app proposal |
| 23:22 | <wsdferdksl> | But I'm extrapolating to what folks would demand |
| 23:22 | <rbuckton> | For partial application, I've kept the proposal's scope intentionally limited. |
| 23:23 | <rbuckton> | I don't want `?` to just mean an arbitrary function is created. Its always an argument placeholder. |
| 23:25 | <haxjs> | My only misuse worry about partial application is someone may write code `f(?, a, b(?))` which expect the semantic like in hack-style. I worry about that much than garden path issue. |
| 23:25 | <rbuckton> | I know there are some that have argued that they would want `f({ x: ? })` because object literals/destructuring is essentially the JS version of "named arguments", but I'm still opposed to that. I'd much rather see us invent an *actual* named arguments capability instead, but I'm not going to push hard for it. |
| 23:28 | <TabAtkins> | Yeah either of those are why I'm against partial-application. :( `foo(?+1)` is invalid, `foo(1, bar(?))` isn't what you expected, `foo({x:?})` is invalid... it's so so limited and/or confusing in practice |
| 23:28 | <rbuckton> | My proposal for partial application was to *just* support partial application. the `?` isn't a value, its an unsatisfied argument position. The "partial application" is actually everything *except* `?` bit. |
| 23:37 | <TabAtkins> | Yeah, I just don't think that pulls its weight given the mines it leaves around itself. I understand that the early-vs-late evaluation differences in `x=>foo(x, expensive())` vs `foo(?, expensive())`, but I feel like that's a footgun all its own honestly. |
| 23:38 | <rbuckton> | Plus, partial application has other capabilities in its problem-space. If you want `f({ x: ?})` you can still do that with an arrow. Partial application covers other use cases: |
| 23:38 | <rbuckton> | ``` |
| 23:38 | <rbuckton> | // getting only the arguments you expect |
| 23:38 | <rbuckton> | [1].forEach(console.log); // oops, logs: 1, 0, 1 (or [1] depending on your runtime...) |
| 23:38 | <rbuckton> | [1].forEach(console.log(?)); // logs: 1 |
| 23:38 | <rbuckton> | // swap argument order |
| 23:38 | <rbuckton> | const f_swapped = f(?1, ?0); |
| 23:38 | <rbuckton> | // simplified references |
| 23:38 | <rbuckton> | element.addEventListener("click", this.onClick(?)); |
| 23:38 | <rbuckton> | // More powerful than .bind |
| 23:38 | <rbuckton> | const g = foo(?, 1, 2, ?); // bind only binds leading arguments, but here you can bind middle arguments |
| 23:38 | <rbuckton> | ``` |
| 23:38 | <rbuckton> | (honestly not sure if that code sample went through, freenode just spat a bunch of errors at me) |
| 23:39 | <ljharb> | i see it |
| 23:39 | <rbuckton> | TabAtkins: its the same mental model as `foo.bind(void 0, expensive())` except you have more control over unbound arguments. |
| 23:48 | <TabAtkins> | Yeah I get that, but I don't think "it's just like `.bind()`" is a very compelling argument for understandability ^_^ |
| 23:48 | <rbuckton> | What I know is that I want pipeline in some form. We would *heavily* use it in the TypeScript codebase at the very least. I also want partial application in some form, because there are so many cases of callback passing that could be simplified using it. I like the F#-style pipeline because (while in some ways limited compared to the Hack-style), it reduces the burden of knowledge for what operator to use where |
| 23:52 | <TabAtkins> | Ah ok, let me pick your brain about that last statement - what's the burden of knowledge you see wrt that in Hack. |
| 23:52 | <rbuckton> | If I know that ` x |> F` is just `F(x)`, and that `F(?)` is basically `_ => F(_)`, using the two together is fairly simple and extremely powerful. I don't have to think about "partial application uses ?" while pipeline uses `#`", or "I can't use partial application in a pipeline because the meaning of `?` changes". If the arrow restriction goes the way littledan proposed, a lot of the Hack-style pipes can be |
| 23:52 | <rbuckton> | done with arrows: |
| 23:52 | <rbuckton> | ``` |
| 23:52 | <rbuckton> | x |> say(?) |
| 23:52 | <rbuckton> | |> _ => _ + _ |
| 23:52 | <rbuckton> | |> _ => ({ x: _ }) |
| 23:52 | <rbuckton> | |> _ => [_] |
| 23:52 | <rbuckton> | |> nameMyTopicWhatIWant => (y |> f(?, nameMyTopicWhatIWant)) |
| 23:52 | <rbuckton> | ``` |
| 23:54 | <rbuckton> | TabAtkins: I'm talking about a scenario where we might have Hack-style pipelines *and* partial application. You either use different symbols for each (the topic or the placeholder), or you have confusing restrictions on where you can use the same symbol. |
| 23:54 | <TabAtkins> | Ohhh okay. |
| 23:54 | <rbuckton> | Plus Hack-style pipes have issues with multiple topics. |
| 23:55 | <TabAtkins> | Are you referring to nested pipelines? |
| 23:55 | <rkirsling> | I think that could be argued as a feature, if it makes something we don't advise doing less easy |
| 23:55 | <rbuckton> | ``` |
| 23:55 | <rbuckton> | # using hack-style |
| 23:55 | <rbuckton> | x |> f(?, y |> g(?, ?)) // but I want the outer `?` in one of these... |
| 23:55 | <rbuckton> | ```\ |
| 23:56 | <rkirsling> | oh in param position, hmm |
| 23:56 | <ljharb> | i think it's probably better if pipeline and partial had different placeholders anyways |
| 23:56 | <TabAtkins> | So yeah, nested pipelines. |
| 23:57 | <rbuckton> | for the above, you would need to have a way to declare the name of your topic, so you end up with: |
| 23:57 | <rbuckton> | ``` |
| 23:57 | <rbuckton> | x |> (_ => f(_, y |> g(?, _))(?) |
| 23:57 | <rbuckton> | ``` |
| 23:57 | <TabAtkins> | At that point you should be breaking the expression apart and using variables. |
| 23:57 | <TabAtkins> | Or use an iife, yeah, but I think that's not worth the syntax cost. |
| 23:57 | <rbuckton> | TabAtkins: Whenever I see `|> ? + 1` in a Hack-style pipe I think the same thing. |
| 23:58 | <TabAtkins> | You think "add 1 to this value" is worth breaking the xpression apart? Or just not worth the syntax? |
| 23:58 | <rbuckton> | Yes, its true that F#+papp doesn't solve this either, but it makes the arrow-function part easier: |
| 23:58 | <rbuckton> | ``` |
| 23:58 | <rbuckton> | // F#+papp |
| 23:58 | <rbuckton> | x |> _ => f(_, y |> g(?, _)) |
| 23:58 | <rbuckton> | ``` |
