# Fixing the Piping/Chaining Issue (Rev 3)

**URL:** <https://discourse.julialang.org/t/fixing-the-piping-chaining-issue-rev-3/90836>\
**Category:** Internals & Design\
**Tags:** multithreading, syntax, piping, chaining, threading\
**Created:** [November 26, 2022, 2:50am UTC](https://discourse.julialang.org/t/fixing-the-piping-chaining-issue-rev-3/90836 "2022-11-26T02:50:46Z")\
**Posts on this page:** 1\
**Showing post:** 41

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [December 6, 2022, 11:56am UTC](https://discourse.julialang.org/t/fixing-the-piping-chaining-issue-rev-3/90836/41 "2022-12-06T11:56:47Z")

</div>

Quite creative, I like it!

> [@Jollywatt](#):
>
> The main selling point seems to be repurposing brace syntax `{ }` to be function composition _with built-in support for partial application_.
> 
> There is a lot more to this proposal, but I’m not so sure about the rest of it.
> 
> …
> 
> I also prefer `Chain.jl` ’s use of `_` as the anonymous argument over `it` or any alphanumeric name.

I think there’s a certain nuance that’s missing though, which is:

> [@Fixing the Piping/Chaining Issue](https://discourse.julialang.org/t/fixing-the-piping-chaining-issue/89654/144):
>
> I think the ultimate objective should be to ~~find~~ settle on a syntax which can be a proper part of the language, so that the effort to build out the other things that would depend on it can be justified.

Namely, I’m trying to create a concept which is as general as possible, and as a result, trying to avoid the behavior of threading the argument into a default position. Additionally, as has been expressed [previously](https://discourse.julialang.org/t/fixing-the-piping-chaining-issue-rev-3/90836/21), the use of `_` is somewhat wasteful, when within the local context it is possible to define new keywords—this would keep `_` free for use in partial application, as [PR #24990](https://github.com/JuliaLang/julia/pull/24990) proposes.

Indeed, if this proposal were to be accepted _and_ #24990 were accepted (which is my hope), then many of the expressions here could look closer to Chain.jl:

```julia
"chains".{
    split(_, "")
    _.^2
    join(_, "•")
    uppercase
}

```

> [@Jollywatt](#):
>
> Personally, I find `x |> {f, g}` better than `x.{f, g}`

The other points that this misses are: 1) creation of an unneeded lambda (increases compile time) and 2) operator precedence. It’s frequent for chains to be short sub-expressions inside larger ones (e.g., `arr.{filter(f, _), first}.a+1`), and the lower precedence of `|>` forces more of it to be placed within the chain, e.g. `arr |> {filter(f, _), first, it.a+1}`, which is clumsier. The high precedence of `.` is useful.

> [@Sukera](#):
>
> typing `{` on my german keyboard requires pressing ALTGR (on the right side of the spacebar) as well as `7` (`0` for `}`) in the number row (also on the right side of the keyboard).

Oh dear, now I understand the dislike for curly braces! 😅 How prevalent are such keyboards?

---

_[View the full topic](https://discourse.julialang.org/t/fixing-the-piping-chaining-issue-rev-3/90836)._