2024-07-08 [07:37:18.0125] do we have topic today? [08:00:57.0251] Unsure. I've joined [08:02:58.0395] We could talk about discards, if there's interest [08:03:08.0280] i'm here for a half hour 2024-07-10 [08:49:17.0005] there is a discussion about pipeline in a group I'm in [08:51:56.0872] they want the function has the ability to know how they're called, normal function? or pipeline? and they want to have different call other in those two cases: ```js onClick: xxx(prevent(listener)) |> stop |> yyy, ``` I don't know what exact he want, but someone mentioned `new.target`. The function can be aware of that if they're called like `new f()` or `f()` [08:55:14.0660] This reminds me that we can also use Meta property (although I'm not sure if it is a good idea) to behave differently as a custom matcher. for example ```js function f(x) { if (function.matches) return function.matches(x.__val__) // { matches: true, value: x.__val__ } ? return x.__val__ } ``` [08:55:28.0681] * This reminds me that we can also use Meta property (although I'm not sure if it is a good idea) to behave differently as a custom matcher. for example ```js function f(x) { if (function.matches) return function.matches(x.__val__) // { matches: true, value: x.__val__ } ? return x.__val__ } ``` [08:58:55.0381] it seems like a really bad idea to make functions have different behavior based on what syntax constructs are used to invoke them. a function call is a function call [09:19:20.0668] Yes, that is def a bad idea imo. [10:08:56.0461] > <@ljharb:matrix.org> it seems like a really bad idea to make functions have different behavior based on what syntax constructs are used to invoke them. a function call is a function call ok 2024-07-11 [18:07:58.0736] Sounds like what they want is F# pipes or the ability to supply tacit unary functions. I still prefer F#-style, tbh, and I think it would have been easier to advance if we'd pushed back on supporting `await` and `yield` (e.g., `(await (x |> y)) |> z`) and just clarified the precedence of `|>` vs. `=>` [09:12:05.0619] By "pushed back on" do you mean "didn't support" or "required support for"? Because "fixing" the `await` syntax is one of the biggest arguments *for* pipeline, imo. [10:03:54.0111] F# style still wouldn't be a world where it'd make sense for a function to be able to detect whether it was called inside a pipeline or not. [11:09:46.0723] > <@ljharb:matrix.org> F# style still wouldn't be a world where it'd make sense for a function to be able to detect whether it was called inside a pipeline or not. Agreed. Something loosely like that was floated about very early on as a way to deal with a leading or trailing context argument, which is why I proposed partial application as a way to make that part of the syntax instead of some other protocol or `this`-like binding mechanism. [11:21:54.0434] > <@tabatkins:matrix.org> By "pushed back on" do you mean "didn't support" or "required support for"? Because "fixing" the `await` syntax is one of the biggest arguments *for* pipeline, imo. By "pushed back on" I meant that it wasn't necessarily a requirement for an MVP version of the proposal since there was a workaround for it (e.g., using parens), so we could have iterated on it in a follow on. IMO, F# pipelines had a chance for quick advancement as they were a building block with very simple semantics. The current pipeline approach requires more complexity as it also necessitates defining a topic token and managing lexical scope, and the semantics don't align with the predominant use cases of pipelines in the wild. Rather than aligning with the ecosystem, we opted for a syntax that prioritized a niche use case (arbitrary expression evaluation). F#-style had no concerns about scoping or topic style, and could have survived alongside `=>` event without partial application. And partial application solved the leading/trailing context argument concern without needing to complicate lexical scoping as well. 2024-07-21 [08:53:02.0057] I will not be able to attend the meeting tomorrow. 2024-07-22 [08:09:20.0269] I just hopped in late, and I’m the only one here. But since we didn’t get our presentation together in time anyways there’s not much to discuss. Let’s try to be ready for tokyo well in advance. 2024-07-30 [14:36:28.0886] Yeah, apologies for all of this, I've been doing a lot of vacationing the last month so didn't have the ability to push on this on top of the other things I was finishing in q2. Def plan to be ready for Tokyo. [14:36:46.0077] (which is, unfortunately, perfectly overlapped with BlinkOn this year...) [14:36:53.0573] that'd be great. ideally it'll be ready multiple weeks before tokyo so we all have time to review :-)