jan kili (Dec 04 2024 at 08:51): jan kili (Dec 04 2024 at 08:51):Inspired by other language changes that seem to trend toward eliminating trivial lambdas, it'd be nice to be able to write
foo
|> when is
bar -> baz
_ -> qux
instead of
foo
|> \x -> when x is
bar -> baz
_ -> qux
Rip when mixing this with .pass_to(...)
Kilian Vounckx (Dec 04 2024 at 09:59):This (or similar) has been proposed a few times. Iirc it has come up as 'piped when' and other names before. Each time it has been turned down however. I'm not giving any opinions on the feature. Just telling so you know
Maksim Volkau (Dec 04 2024 at 10:28):Definitely, not the first time. Here is mine #ideas > Closure shortcut feature :-)
Anthony Bullard (Dec 04 2024 at 11:32):If we don’t want to do the sugar, maybe we could at least explore eliminating the lambda during either Can or IR phases?
Anton (Dec 04 2024 at 11:44):explore eliminating the lambda during either Can or IR phases?
Can you elaborate? What's the benefit of that?
Anthony Bullard (Dec 04 2024 at 13:57):It would be a pure performance optimization. Maybe LLVM will do it itself. Might not be worth it. No need to pay the cost of a function call (or worse if the lambda is also a closure, which would often be the case here).
Brendan Hansknecht (Dec 04 2024 at 16:34):Llvm will 100% do it for us
Brendan Hansknecht (Dec 04 2024 at 16:34):But yeah, easy optimization to generate less llvm ir which means faster compilation.
Brendan Hansknecht (Dec 04 2024 at 16:35):Generally speaking llvm's inliner policy is yes
Brendan Hansknecht (Dec 04 2024 at 16:43):Oh also, due to lambdasets and closure args not being boxed, llvm will inline lambdas with closures in roc. With boxed closures, that is more likely to fail and require a manual inlining pass before llvm.
Brendan Hansknecht (Dec 04 2024 at 16:47):Anyway, going back to this feature. This is one of those features I have never felt compelled enough to think is worth adding. Feels too specific and not for that much benefit. My gut feeling is that if we go for a feature in this vein, it should be generic in a way that enables a piped placeholder. Then it would enable use with more features in roc along with piping to an arg that is not in order.
Anthony Bullard (Dec 04 2024 at 16:51):Brendan Hansknecht said:
Anyway, going back to this feature. This is one of those features I have never felt compelled enough to think is worth adding. Feels too specific and not for that much benefit. My gut feeling is that if we go for a feature in this vein, it should be generic in a way that enables a piped placeholder. Then it would enable use with more features in roc along with piping to an arg that is not in order.
I hope that conversation goes better than the pipe operator convo in JS. Luckily we don’t have to worry about bw compat
jan kili (Dec 04 2024 at 17:03):Yeah, this feels like a minor ergonomic detail that is at the whims of more major structural features coming and going.
Brendan Hansknecht (Dec 04 2024 at 22:38):Anthony Bullard said:
I hope that conversation goes better than the pipe operator convo in JS. Luckily we don’t have to worry about bw compat
Do you have any context or quick summary of the concern?
Anthony Bullard (Dec 04 2024 at 23:41):They has just been years of back and forth first on does piping supply first element or last. Then once that was considered undecidable, they wanted to introduce a symbol for where it’s inserted. And well, JS doesn’t have a rich space of symbols available that don’t conflict since they allowed both _ and $ as identifiers and most of the rest are either braces or math operators
This is happening at the same time as patterns are being introduced which brings up the need for a symbol or keyword for an ignored part of the pattern
Basically it’s been a slog
Last updated: Jun 16 2026 at 16:19 UTC