Pipeline Champions on 2022-03-25

00:19	<jschoi>	https://i.imgur.com/qV5ClVf.png
00:19	<jschoi>	https://i.imgur.com/ff9aniE.png
00:19	<jschoi>	I have here two versions of the updated dataflow-proposal diagram. The second version gets rid of the overlap between pipe operator and call-this, which I believe is appropriate…but I worry that getting rid of that overlap will get pushback at plenary for being too subjective.
00:22	<jschoi>	What I’m wondering is if I can get away with claiming that call-this does not overlap with the pipe operator, since trying to use `.call` with the pipe operator solves the word order alone…but it doesn’t make the clunkiness better—it makes it worse. `fn.call(rec, arg) // Unnatural word order rec \|> fn.call(@, arg) // Natural word order but worsened readability rec :> f(arg)`
00:26	<jschoi>	Richard Gibson gave me this idea at the Research Call today. Since we must have both pipe operator and call-this, it’s going to be important to convey the idea that pipe operator does not solve `.call`’s clunkiness problem, and that another operator is necessary. (Slide 6 in the call-this presentation talks about this too.)
00:26	<jschoi>	But will I be able to put this idea without pushback in the dataflow diagram too? Or is it too subjective?
02:19	<Richard Gibson>	I think there is overlap in the sense that a pipe operator allows for expression an invocation in SVO order like `receiver \|> method.call(@̂%̂, ...args)`, but I also like the idea of strikethrough on the pipe examples under call-this to indicate that they don't really address the clunkiness motivation for it. So basically, a combination of the two diagrams—graphical layout of the first, textual formatting of the second.
02:26	<jschoi>	Whoa, somehow Matrix turned those carets into circumflex accents: @̂%̂.
02:26	<Richard Gibson>	but also, in the wake of today's meeting and to further separate call-this from pipelines, I think it would make sense to update both the diagram and the slides to replace the `:>` example punctuator for call-this with something more suggestive of tight binding, e.g. `~>` (I understand it could change, but this seems like a "best foot forward" approach)
02:26	<Richard Gibson>	Whoa, somehow Matrix turned those carets into circumflex accents: @̂%̂. that was me trying to be maximally token-agnostic 😉
02:30	<jschoi>	I think there is overlap in the sense that a pipe operator allows for expression an invocation in SVO order like `receiver \|> method.call(@̂%̂, ...args)`, but I also like the idea of strikethrough on the pipe examples under call-this to indicate that they don't really address the clunkiness motivation for it. So basically, a combination of the two diagrams—graphical layout of the first, textual formatting of the second. https://imgur.com/S0QLrhn
02:32	<Richard Gibson>	nice!
02:33	<jschoi>	By the way, I’m a bit surprised you think `~>` may suggest a tight `.`-like precedence rather than loose `\|>`-like precedence. I do recall you saying that you didn’t much like `:>` (whether tight or loose?).
02:35	<Richard Gibson>	correct, I think it has too much visual similarity with `\|>`. `~>` suggests tight binding to me because it is arrow-like (as does `->`, for the same reason)
02:36	<Richard Gibson>	I would have also suggested `::`, but I think it's more important for the content to differentiate proposals and that is already being homesteaded by extensions
02:37	<jschoi>	I would have also suggested `::`, but I think it's more important for the content to differentiate proposals and that is already being homesteaded by extensions Ah, okay, so this isn’t necessarily about call-this in of itself but just for the dataflow-proposal diagram.
02:38	<jschoi>	This applies only for tight unbracketed receiver-first style, right? Since if precedence is loose, like with `\|>`, then you see similarity to `\|>` as an advantage, right?
02:39	<Richard Gibson>	right. I think the example call-this punctuator should suggest tight binding to put some distance between that proposal and pipeline, but if the proposal evolves towards loose binding then the punctuator should follow suit and `:>` becomes more illustrative
02:41	<jschoi>	I know that some representatives are concerned about too much visual similarity between whatever bind-this looks like and `.` or `\|>`, even if they are functionally similar or have similar precedence.
02:41	<jschoi>	Ditto for confusion with other programming languages’ `->`, `::`, etc.
02:42	<jschoi>	It’ll be hard to balance all of these criteria. Maybe thirty plenary minutes won’t be enough and I should steal some from pipe’s sixty plenary minutes.
02:43	<Richard Gibson>	I hope it doesn't go down that road next week. The ideal example punctuator would suggest tight binding (or at least not suggest loose binding) and avoid those concerns, because they're not appropriate at this early stage anyway
02:45	<Richard Gibson>	I suggested `~>` rather than `->` because I'm aware of some languages that already use the latter, but if there are also some that use the former then varying even further afield might be prudent
02:48	<jschoi>	I would be quite interested to poll which operators visually/psychologically suggest tighter `.`-like precedences versus looser `\|>`-like precedences…
02:48	<jschoi>	Obviously there’s a spectrum, but it’d be fun (albeit probably difficult) to empirically study this.
02:49	<Richard Gibson>	I agree. I just don't want to get the plenary bogged down in it 😅
02:49	<jschoi>	Yeah, probably should focus most on which of the four syntax styles we want to pursue (or exclude).
03:33	<rkirsling>	I don't see how precedence could be more important than "what it does" though
03:33	<rkirsling>	`:>` was suggested because it behaves as a pipeline operator for `this`, i.e. for the invisible zeroth argument
03:44	<rkirsling>	but if that's problematic then I would support the `f(this: x, y)` approach since it's unmistakable. I've never understood the claim of "natural word order" here (again, I think it's wildly unnatural unless analogized with pipeline), so I definitely don't think any solution is better than nothing
04:46	<jschoi>	`:>` was suggested because it behaves as a pipeline operator for `this`, i.e. for the invisible zeroth argument `:>` is not problematic in of itself. It’s just that we need to decide what we want it to be most conceptually analogous to. Richard’s primary concern about `:>` is that he would want `:>` to have loose `\|>`-like precedence, not tight `.`-like precedence.
04:47	<jschoi>	Precedence is an important part of “what it does” because it’s a core part of what we think it is. Should it behave like a pipe operator? Then it arguably should look similar to `\|>` and have a similar loose precedence to `\|>`. Should it behave like `.` dot calls? Then it should arguably look similar to `.` and have a similar tight precedence to `.`.
04:49	<jschoi>	At least that’s the core of Richard’s argument, which I think is reasonable.
04:50	<jschoi>	“Natural word order” can be analogized with the pipe operator. But it can also be analogized with `.` dot calls. And there’s the choice we have to make, and precedence (loose like pipe or tight like `.`) is a key part of our choice: like pipe or like dot.
04:58	<rkirsling>	yeah. I do think that's kind of an unpostponable conversation though
04:58	<rkirsling>	I didn't really understand the comment about certain concerns occurring at too early a stage
04:58	<jschoi>	What comment was that?
04:59	<rkirsling>	ah, Richard's comment that The ideal example punctuator would suggest tight binding (or at least not suggest loose binding) and avoid those concerns, because they're not appropriate at this early stage anyway
04:59	<jschoi>	Ah, I believe he was referring there specifically to my updated diagram of dataflow proposals.
04:59	<jschoi>	Since I have to use one of the syntaxes just for illustrative purposes in that diagram.
05:15	<Justin Ridgewell>	https://imgur.com/S0QLrhn The SQ example for the PFA code on the bottom left is itself using PFA syntax
05:33	<jschoi>	The SQ example for the PFA code on the bottom left is itself using PFA syntax Thanks! Will fix.