Third time’s (hopefully) the charm :wink: Okay so in contrast with my last two proposals ( 1 , 2 ) this proposal is less preachy, and more “hey check out this crazy cool thing I did and please offer feedback.” Hopefully it’s good enough to be incorporated into the language. But play with it and let me…

let-end is a bit shorter than begin (: DataPipes supports both (begin and let) for pipes, with corresponding differences in variable scopes. The let-end semantics is arguably much more common and natural in this context, begin-end is only for cases when multiple variables are defined in the pipe a…

so proposal 4 I am seeing scattered over a few comments: do all of the following merge #24990 to get underscore partial application merge Chain.jl into Base with three changes a. make @chain no longer thread automatically into first argument b. change @chain x begin ... end semantics to simply x…

FWIW, getting just 1 & 2 even without change would be already great (I find the syntax proposed by Chain.jl it already useful) :slight_smile: Also,with 2.b) I realise the way to capture the output is not obvious. So at least, this aspect should be carefully thought through.

[image] Barget: I realise the way to capture the output is not obvious maybe x |> chain ... end is better

@jar1 : We already have a shorter alternative to begin a; b end for blocks: (a; b) :wink: @jules : Appreciated. Considering that {...} parses differently than blocks anyway, that was a good move imo. I do like the idea of having a more-verbose block syntax for multi-line {...}. Is there any analogy …

[image] uniment: @jar1 : We already have a shorter alternative to begin a; b end for blocks: (a; b) :wink: Yes, but (a; b) is horrible. That should be syntax for FrankenTuples .

Syntax appears to be free for FrankenTuple definition :wink: I think the first step would be getting the type into Base. julia> :( (a,; b=1) ).args 2-element Vector{Any}: :($(Expr(:parameters, :($(Expr(:kw, :b, 1)))))) :a

[image] uniment: The thing you must understand, is that the behavior of underscores in PR#24990 is incompatible with their behavior in Chain.jl. For example, PR#24990 would propose that map(_^2, _) should create a function that behaves like x->map(y->y^2, x), whereas Chain.jl treats it as if it’…

No, that example is not a problem for #24990; it’s a problem for Chain.jl.

I have learned two things from this long saga of threads on chaining: Generic partial application is really hard to be consistent and correct in all cases, and will almost certainly not be coming to Julia anytime soon. Chain.jl is pretty darn good and does indeed cover the majority of use-cases S…

Fixing the Piping/Chaining Issue (Rev 3)

Internals & Design

jar1 December 7, 2022, 6:53pm 61

Yes, but (a; b) is horrible. That should be syntax for FrankenTuples.

FrankenTuple Fun

Topic		Replies	Views
Fixing the Piping/Chaining/Partial Application Issue (Rev 2) Internals & Design proposal , piping , chaining , partial-evaluation , threading	40	4315	November 26, 2022
Summary of piping/chaining proposal? Internals & Design	23	3505	August 13, 2024
Fixing the Piping/Chaining Issue Internals & Design proposal , piping , chaining , partial-evaluation , threading	212	8554	January 16, 2023
Seeking feedback on Chainables before registering it Package Announcements package , feedback , chain	16	408	March 14, 2026
[RFC] PipelessPipes.jl (now Chain.jl) Package Announcements	61	5164	March 25, 2021

Fixing the Piping/Chaining Issue (Rev 3)

Related topics