Proposal: add a version of @chain that takes its first input on the left

[fredcallaway]

Motivation:

Imagine I have written the following code:

ys = map(xs) do x
    x + 1
end

Now I decide I want to filter out the even numbers. I could jump back and add @chain before map, but this defeats one of the main benefits of piping—writing code in the order that you naturally think of it.

The proposal is to support something like this

ys = map(xs) do x
    x + 1
end @tochain filter(iseven, _)

where @tochain(expr) evaluates to something like

|> x -> @chain expr

Another, perhaps cleaner, option would be to define @fchain as a version of @chain that returns an anonymous function, supporting the pattern:

ys = map(xs) do x
    x + 1
end |> @fchain filter(iseven, _)

This would also allow defining functions like keepeven = @fchain filter(iseven, _) although I'm not sure that's really desirable.

[jkrumbiegel]

The proposal is to support something like this

ys = map(xs) do x
    x + 1
end @tochain filter(iseven, _)

That doesn't work because there are no infix macros. After end the expression is done and any further code will result in a syntax error. You cannot resolve the macro to |> to make it infix, that's decided at parse time.

@fchain seems a bit too niche for me to add it here, I'd rather keep the API as small as possible. If the only thing it does is to wrap the chain in a function, then I don't really think it's much better than the normal

ys = map(xs) do x
    x + 1
end |> x -> @chain x filter(iseven, _)

In general, I agree with you that sometimes it would be nice to have simpler continuation, especially when working in the REPL where you can't jump and edit as easily as in an editor. That's one reason why I almost never use the plain REPL, I pretty much always use VSCode to write the code to send to the REPL, exactly for that reason that it's too annoying to edit code already written in the REPL (like prepending @chain in your example)