I saw facets has some similar feature that uses #* instead, maybe because it looks a bit closer to Haskell's composition syntax. Nevertheless, I still like #<< better, it feels your are "connecting" the blocks together.

What about #* for composing traditionally (right to left) and #| for piping (left to right)? In mathematics, depending of the area and the subject, both ways are used, and some argue that "piping" is more natural than "precomposing". However, when functions are "piped", the arguments are usually on the left: (arguments)(function1 function2).

Update: i think having the both was a bad idea, it would be redundant.

Update: i think having the both was a bad idea, it would be redundant.

I was going to say the same thing. Having both #* and #| is redundant and also a bit confusing, since #| doesn't really feel to be the opposite operation of #* at any context. We should choose one or the other but not both.
I still like #| (chaining from left to right) a bit better, but I rather have #* than nothing.

I think that the meaning of #<- would not be symmetric with the meaning of #->.

Also, in mathematics, arrows are more like relations than operations. When used to describe functions, usually function arguments go to the arrow's tail, function values to the arrow's head, and function's name, for example, goes on top of the arrow.
(In this sense Ruby's lambda syntax would look to me more natural in the form f = (a,b)->{ a + b } instead of f = ->(a,b){ a + b }.)

The main drawback of #* in my opinion is that is does not specify the direction of composition ((f*g)(x) is f(g(x)) or g(f(x))?), but since in Ruby function arguments are written on the right (f(g(x))), i think it can be assumed that the inner function is on the right and the outer is on the left.

Speaking from a more programming-related viewpoint, f(g(x)) is what is used e.g. in Haskell, and probably in many other functional languages, and so may be familiar with many programmers.

However, we should take into account that a functional language writes e.g. reverse(sort(array)), so it makes sense to define revsort = reverse * sort (i.e. (f ∘ g)(x) is f(g(x))). But in Ruby, it would be array.sort.reverse, so revsort = sort * reverseve may feel much more natural (i.e. (f ∘ g)(x) is g(f(x))).

I agree that (f ∘ g)(x) is g(f(x)) is more intuitive from a purely
programmatic point of view. It is "natural" for the operations to be
applied left to right, exactly like method chaining.

When functions are applied from left to right, the argument is usually (if not always) on the left. The form (x)(fg)=((x)f)g may look awkward (though i personally used it in a math paper), so i think usually the "exponential" notation is preferred: xfg = (xf )g, where xf corresponds to f(x) in the usual notation.

With method chaining, IMO, the "main argument" of a method is the receiver, and it is on the left. Lambdas and Procs are not chained in the same way as method calls.

Update: I agree that the common syntax for calling functions (f(x) rather then (x)f) should not be an obstacle if Ruby decides to consistently multiply functions putting the inner on the left and the outer on the right. Another syntax for calling functions can be invented in the future, or rubists can learn to live with this inconsistency. For example, Ruby (or Matz) can decide to multiply lambdas with the inner on the left and the outer on the right, and add the following syntax:

In Math multiplication is always associative, even for matrix. I.e: (A*B)*C == A*(B*C). If we use * for ∘ (composition) it resembles multiplication. Function composition is analog to matrix multiplication which are commonly used for transformation compositions as well. In fact, function composition is also associative.

So, when representing h = f ∘ g as h = f * g it makes sense to me (although Math preferring a different symbol for multiplication and composition is a good indication that we should consider this as well for Ruby - more on that later on). But Math representation is procedural, not object oriented. If we try to mix both approaches to fit Ruby philosophy this could lead to great confusion.

You can't know beforehand if bad_argument_name is an array, a number or a proc/lambda. If we read this instead:

defbad_name(bad_argument_name, b)
bad_argument_name <- b
end

we would then have a clear indication that bad_argument_name is probably a proc/lambda. I know the same argument could be used to differentiate << between strings and arrays among other cases. But I think that function composition is conceptually much different from those other operations (concatenation, multiplication) than concatenation (<<) is for strings and arrays. In both cases we are concatenating but concatenation means different things for strings and arrays in non surprising ways.

But then using this arrow notation I would expect that (a <- b) would mean "a before b" (b(a(...))) while (a ∘ b) means "a after b" (a(b(...))).

I find it a bit awful to use "hypotenuse = square_sum <- sqrt", although it is the way OO usually work ([4, 5].square_num.sqrt - pseudo-code of course). But we would not be using "[4, 5].hypotenuse", but "hypotenuse.call 4, 5", right? So, since we're using procedural notation for procs/lambdas we should be thinking of procedural programming when deciding which operator to use.

I would really prefer to have lambda syntax as "double = <-{|n| n * 2}" and function composition as "hypotenuse = sqrt -> square_sum" (sqrt after square_sum). But since I don't believe the lambda syntax won't ever change, let's try to see this over a different perspective.

Instead of reading (a <- b) as "a before b", I'll try to think of it as being "b applied to a" (a(b(...))). This also make sense to me so I can easily get used to this. It would work the same way as "*" but there would be a clear indication that this refers to function composition rather than some generic multiplication algorithm.

Having said that, I'd like to confirm that I'm ok with either * or <- and I'd really like to have function composition as part of Ruby.

+1 to #*.
+1 to rosenfeld's first 2 paragraphs ( h = f ∘ g as h = f * g, and matrix multiplication analogy).
-1 to "<-". Rationale: It is too easy invent a guitar with one more string. Furthermore, when it comes to operators, I consider design by jury a weak approach.

One thing that might be worth discussing is the necessity of the type checking: should it be possible to compose any callable object (rather than explicitly Procs and Methods)? The Ruby implementation suggested in the description of this issue suggests calling to_proc on the given argument but we could also demand that the supplied argument responds to call, e.g. in pure Ruby:

Regarding the syntax: I also support * as the operator where f * g = f(g(x)) (as it seems close enough to the mathematical syntax already used by other languages such as Haskell and Idris) but if that is too divisive, we could choose a method name from the mathematical definition (https://en.wikipedia.org/wiki/Function_composition) instead:

The notation g ∘ f is read as "g circle f ", or "g round f ", or "g composed with f ", "g after f ", "g following f ", or "g of f", or "g on f ".

I'm teaching Haskell in a graduate class, so I'm quite familiar with function composition and use it a lot, but the original example isn't convincing at all. For me, in Ruby, something like val.strip.capitalize reads much, much better than some artificially forced function composition. If there were a method String#prepend, it would be even more natural: val.strip.capitalize.prepend('Title: ').

If there are better examples that feel more natural in Ruby, please post them here.

I'm teaching Haskell in a graduate class, so I'm quite familiar with function composition and use it a lot, but the original example isn't convincing at all. For me, in Ruby, something like val.strip.capitalize reads much, much better than some artificially forced function composition. If there were a method String#prepend, it would be even more natural: val.strip.capitalize.prepend('Title: ').

If there are better examples that feel more natural in Ruby, please post them here.

I'm teaching Haskell in a graduate class, so I'm quite familiar with function composition and use it a lot, but the original example isn't convincing at all. For me, in Ruby, something like val.strip.capitalize reads much, much better than some artificially forced function composition. If there were a method String#prepend, it would be even more natural: val.strip.capitalize.prepend('Title: ').

If there are better examples that feel more natural in Ruby, please post them here.

I don't believe you need a pure PF language to benefit from a feature like this. Many ETL projects like transproc (https://github.com/solnic/transproc) would probably find it useful too.

I don't believe you need a pure PF language to benefit from a feature like this. Many ETL projects like transproc (https://github.com/solnic/transproc) would probably find it useful too.

Transproc is what actually inspired me to submit a patch here: my hope is that having functional composition in the Ruby language itself will enable easier data pipelining using only Procs, Methods and other objects implementing call. The presence of curry (http://ruby-doc.org/core-2.2.2/Proc.html#method-i-curry) seems like a good precedent for adding such functional primitives to the core.

The feature being added is function composition; not relation composition, not method chaining. Its target audience is most likely to read f * g as “f after g”, so that’s how it should work. Perhaps some Ruby programmers will not use this feature directly (as with Proc#curry) because they neither program nor think in a functional style, but it should be designed to be useful and familiar to those who do. The proposed implementation achieves that.

I'm teaching Haskell in a graduate class, so I'm quite familiar with function composition and use it a lot, but the original example isn't convincing at all. For me, in Ruby, something like val.strip.capitalize reads much, much better than some artificially forced function composition. If there were a method String#prepend, it would be even more natural: val.strip.capitalize.prepend('Title: ').

If there are better examples that feel more natural in Ruby, please post them here.

I fully agree with you that a good example really helps to understand the problem which lead to a better solution.

The few times I've missed function composition is ruby is always when I wanted to replace the same pattern :

res = step1(base)
res = step2(res)
res = step3(res)
...
res

I hate having to mutate the res variable and I would hate even more creating different temp variables especially when I do not know how many steps there will be. I would like to be able to combine the steps then apply the step combination to base
There are a lot of examples for this pattern so here is one : data retrieval with ActiveRecord ( I assume most people know this library but this is only an example )

With the recent addition of Hash#to_proc and performance improvements to Procs in 2.3.0, I have rebased my patch (attached) to add composition between Procs, Methods and other objects responding to call with * in the hope of reviving this proposal.

What motivated me was map f (map g xs) = map (f . g) xs, and what I still don't understand (being a newbie to extending Ruby or understanding its internals) is that .map(&some_proc).map(&some_other_proc) still behaves better than .map(&(some_proc * some_other_proc)) given my current implementation of compose. Although I think composition has a lot of uses, the admittedly small but free performance benefit I expected to gain was top of my list.

I do think emphasis on composition suggests a somewhat different style of writing Ruby, but I think it can be a good one, actually.

The best possible name is discussed for 6 years already, and feature seems pretty nice to have. I believe that sometimes it is just good to make "executive decision" about name once and for all, at least better than postpone feature for years.

Currently planning on releasing a gem this weekend that will do a similar thing, it could serve as inspiration for an implementation, but my C is no where near good enough to try at the Ruby core level.

Aside: Have we ever considered implicitly to_procing anything passed to a method expecting a block? e.g. arr.map(&:to_s) becomes arr.map(:to_s)