Piping data to functions

[andrewmarx]

Something I've seen elsewhere is the concept of piping data to functions, which can drastically increase readability in cases where someone would either use intermediate variables or call functions as parameters.

Pseudocode for a contrived example:

x = {1,-7,-5,3}

// Without pipes, intermediate variables.

a = sum(x)
b = abs(a)
c = sqrt(b)
result = round(c, 2)


// Without pipes, nesting functions.

result = round(sqrt(abs(sum(x))), 2)


// With pipes the result on the left of the pipe is passed as the first parameter
//of the function on the right, allowing the code to be read left to right.

result = x %>% sum() %>% abs() %>% sqrt() %>% round(2)


// It's particularly nice for splitting code across lines

result = 
  x %>% 
  sum() %>% 
  abs() %>% 
  sqrt() %>% 
  round(2)

The %>% operator is just an example (from R), it could be something else

I'm just learning rust, and know nothing about language development, so the complexities involved might make this impractical. At the same time, it would also be really interesting to see how something like this could be incorporated to work with tuples and multiple return values.

[Luthaf]

If your functions do take a &self as first parameter, you can achieve similar result with dot chaining:

result = x.sum()
          .abs()
          .sqrt()
          .round(2);

[burdges]

I think you're stuck with the reverse polish dot chaining on &self or self for Rust.

As an aside, if you consider a language like Haskell, Idris, OCaML, etc. where juxtaposition is high-precedence curried function application, then you have both . that acts as function composition and $ that acts as low-precedence curried function application. I'd consider this the most elegant and expressive way of doing this. And I hope someone eventually develops such a language built on borrowing instead of garbage collection. I do think Rust's decision to resemble C and object oriented languages makes Rust more approachable for most programmers. It also seemingly made it easier to focus on zero-cost abstraction, like by simplifying type-inference. To be precise, Idris now strikes a nice enough compromise on overloading to suggest that Rust could looked like a functional language, but those developments happened concurrently with Rust's development, and Idris' type inference used to be incredibly weak, so dealing with this could've been a distraction for Rust.

[oli-obk]

It's actually pretty simple to implement this with a wrapper type: https://is.gd/42O3Ns

But I agree that it's nice that Rust code is readable for people who've never seen a functional language and I wouldn't want to break this for purity's sake.

[nixpulvis]

While I'm on a little Rust RFC binge I'll just swing by here and say that I really hope to never see syntax like x %>% y in Rust. One of the things (along with many, many others) that first drew me to Rust was that it's actually pretty syntactically light. Nothing like C99 of course, but much easier to read than Haskell or the like.

[mark-i-m]

I think this is an attempt at building convenient function composition. And i would totally support that!

[alilleybrinker]

So, translating the pseudocode above into something more Rust-y:

// ... assume various functions are implemented here.

fn main() {
    let x = vec![1, -7, -5, 3];
    let a = sum(x);
    let b = abs(a);
    let c = sqrt(b);
    let result = round(c, 2);
    let result = round(sqrt(abs(sum(x))), 2);
    let result = x %>% sum %>% abs %>% sqrt %>% |x| round(x, 2)
}

I'm not completely opposed to adding an infix function composition operator. But I don't think %>% is the right name for it. Pulling the name from Haskell, you could have either .> (which in Haskell is a convenient name for flip (.), or you can use >>> from Control.Arrow, which is more general):

// ... assume various functions are implemented here.

fn main() {
    let x = vec![1, -7, -5, 3];
    let a = sum(x);
    let b = abs(a);
    let c = sqrt(b);
    let result = round(c, 2);
    let result = round(sqrt(abs(sum(x))), 2);
    let result = x >>> sum >>> abs >>> sqrt >>> |x| round(x, 2)
}

[mark-i-m]

I was thinking we could define the bitwise-or operator for functions and closures...

…

On Jul 2, 2017 12:24 PM, "Andrew Brinker" ***@***.***> wrote: So, translating the pseudocode above into something more Rust-y: // ... assume various functions are implemented here. fn main() { let x = vec![1, -7, -5, 3]; let a = sum(x); let b = abs(a); let c = sqrt(b); let result = round(c, 2); let result = round(sqrt(abs(sum(x))), 2); let result = x %>% sum %>% abs %>% sqrt %>% |x| round(x, 2) } I'm not completely opposed to adding an infix function composition operator. But I don't think %>% is the right name for it. Pulling the name from Haskell, you could have either .> (which in Haskell is a convenient name for flip (.), or you can use >>> from Control.Arrow, which is more general): // ... assume various functions are implemented here. fn main() { let x = vec![1, -7, -5, 3]; let a = sum(x); let b = abs(a); let c = sqrt(b); let result = round(c, 2); let result = round(sqrt(abs(sum(x))), 2); let result = x >>> sum >>> abs >>> sqrt >>> |x| round(x, 2) } — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2049 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIazwBBuc6tcJxopsGqvAGO1qdHFnWTZks5sJ8RJgaJpZM4OGqNe> .

[durka]

See also the pipeline crate which implements this in a macro.

[alilleybrinker]

There is something worth pointing out here, which is the distinction between (.) and (<<<) (and, equivalently, between (.>) and (>>>)). (.) and (.>) are function composition operators, one right-to-left ((.)) and one left-to-right ((.>)). (<<<) and (>>>) are more generic composition operators. In Haskell, they are defined on Category types, where a Category is defined as having an identity "morphism" (id :: Category cat => cat a a, which is like a generic version of the identity function, id :: a -> a), and having morphism composition, (.) :: Category cat => cat b c -> cat a b -> cat a c (yes, this annoyingly overloads the . operator. Like the last operator, this is a generic version of (.) :: (b -> c) -> (a -> b) -> (a -> c)).

(<<<) is equivalent to the Category version of (.), and is defined as (<<<) :: Category cat => cat b c -> cat a b -> cat a c. (>>>) is the same function with the first two arguments flipped (making it left-to-right rather than right-to-left). Its type is (>>>) :: Category cat => cat a b -> cat b c -> cat a c.

I mention this because if we're going to do infix composition, there's the question of whether we'd want to keep it to functions of one argument (like with (.)), or do we want to (can we? not right now, I believe) make it more generic, and akin to the Category typeclass in Haskell?

Name	Direction	Defined on
.	right-to-left	functions of one argument (a -> b)
.>	left-to-right	functions of one argument (a -> b)
<<<	right-to-left	all categories (with functions described above)
>>>	left-to-right	all categories (with functions described above)

[alilleybrinker]

@mark-i-m, that particular overloading seems like it would be confusing. I certainly wouldn't expect bitwise-or on functions to work, much less to provide function composition.

It reminds me a bit of C++ overloading >> and << for I/O, and not just left/right bit shifting.

[nixpulvis]

Call me crazy, but one day we wont be limited to shitty ASCII keyboards, could we start using unicode like ∘ for this?

Only like 75% joking.

[nixpulvis]

In reality foo.bar().baz() should be prefered imo.

[alilleybrinker]

@nixpulvis, I mean, APL and APL family languages have all gone down this rabbit hole. In the Haskell world, the proliferation of operators (imo) really hurts readability. I think there's a core set that can be good, but I am generally against going completely crazy with introducing new operators.

Haskell's lens library drives me nuts sometimes, because a lot of the docs use the custom operators rather than the equivalent prefix functions.

[mark-i-m]

Yeah, i guess chaining method calls are the primary alternative... Did anybody know if they equally expressive?

[nixpulvis]

They should be, but might require creating a trait.