f(x,y,z) = 4*x+3*y+2*z

Currying means that we can rewrite the function as a composition of 3 functions(a function for each param):

f(x)(y)(z) = 2*z+(3*y+(4*x))

The direct use of this is what is called Partial Function where if you have a function that accepts n parameters then you can generate from it one of more functions with some parameter values already filled in. Ruby 1.9 comes with support for currying concept(through the Proc#curry method) and this blog post is explaining how you can use it effectively.
I’m going to walk you through a simple example to explain the concept, however i need to mention few things:
1- The main example is taken from the free Scala By Example book(First-Class Functions chapter), however i have replaced recursion calls by simple upto iterators.
2- In Ruby 1.9 you can use block.(*args) just like you use block.call(*args) or block[*args] in Ruby 1.8, so i’ll stick to block.(*) notation.
3- I could have used the inject method, but i preferred readability to concise code.

Let’s start the simple tutorial by adding three methods:
1- A method to sum all integers between two given numbers a and b.
2- A method to sum the squares of all integers between two given numbers a and b.
3- A method to to sum the powers 2^n of all integers n between two given numbers a and b.

###################################
# Normal definitions
###################################
sum_ints = lambda do |a,b|
  s = 0 ; a.upto(b){|n| s += n } ; s 
end
 
sum_of_squares = lambda do |a,b|
  s = 0 ; a.upto(b){|n| s += n**2 } ;s 
end
 
sum_of_powers_of_2 = lambda do |a,b|
  s = 0 ; a.upto(b){|n| s += 2**n } ; s 
end
 
puts sum_ints.(1,5) #=> 15
puts sum_of_squares.(1,5) #=> 55
puts sum_of_powers_of_2.(1,5) #=> 62

Cool, however if you focus on the 3 methods, you will notice that these methods are all instances of a pattern Σf(n) for a range of values a -> b. We can factor out the common pattern by defining a method sum:

############################################
# Some refactoring to make some abstraction
# Passing the sum mechanism itself
############################################
 
sum = lambda do |f,a,b|
  s = 0 ; a.upto(b){|n| s += f.(n) } ; s 
end
 
puts sum.(lambda{|x| x},1,5) #=> 15
puts sum.(lambda{|x| x**2},1,5) #=> 55
puts sum.(lambda{|x| 2**x},1,5) #=> 62

Ok, but what about having the formal definitions for the 3 methods? How can we have those definitions out of the sum method? Well that’s the use of currying and partial functions, in our case we just need to pass the first param to the sum method to specify what type of sum is it:

###################################
# More refactoring using currying
# Currying was added to Ruby 1.9
# Via Proc#curry
###################################
 
# generate the currying
currying = sum.curry
 
# Generate the partial functions
sum_ints = currying.(lambda{|x| x})
sum_of_squares = currying.(lambda{|x| x**2})
sum_of_powers_of_2 = currying.(lambda{|x| 2**x})
 
puts sum_ints.(1,5) #=> 15
puts sum_of_squares.(1,5) #=> 55
puts sum_of_powers_of_2.(1,5) #=> 62

That’s it! I hope I could clarify the use of currying, if not just add your comment here

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state. Functional programming has its roots in the lambda calculus, a formal system developed in the 1930s to investigate function definition, function application, and recursion. Many functional programming languages can be viewed as embellishments to the lambda calculus.

That’s a clear definition, however and if it’s not, the following walk through some concepts of functional programming should result in a better understanding:

Pure functions

In practice, the difference between a mathematical function and the notion of a “function” used in imperative programming is that imperative functions can have side effects, changing the value of already calculated computations. Because of this they lack referential transparency, i.e. the same language expression can result in different values at different times depending on the state of the executing program. Conversely, in functional code, the output value of a function depends only on the arguments that are input to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) both times. Eliminating side-effects can make it much easier to understand and predict the behavior of a program, which is one of the key motivations for the development of functional programming.

Pure functions support the mathematical definition of a function:

y = f(x)

Which means:
1- A function should return the same exact value given the same exact input.
2- A function does one thing exactly(has one clear mission), it has no side effects like changing some other value or write to stream or any other mission rather than its assigned one.

In fact Ruby doesn’t force you to write pure functions, but certainly it helps you to do so. Actually exercising yourself to write in pure functional style when possible helps you really in many ways:
1- It makes your code clean, readable and self-documenting.
2- It makes your code more “thread safe”
3- It helps you more when it comes to TDD.

Let’s have a look on how Ruby helps you do Pure functional code:

The ! symbol

Most of Ruby programmers know the ! symbol that comes at the end of method names like gsub!, merge! and many other methods. The ! symbol means: “Use it cautiously”. However If you focus more, you will notice that most of time, the ! symbol means: “This is a method that has a side effect; it alters the object which is invoked on!”.

s = "hello" #=> "hello"
up_s = s.upcase #=> "HELLO"
puts s.upcase! #=> "HELLO"
puts s #=> "HELLO"

As you can see, the upcase! method is not a pure functional method cause it has a side effect, it changes the string itself. On the other hand, the upcase method is a pure functional one as it returns the corresponding value with no other side effects.

On all hows, it’s highly recommended that you stick to this convention of method naming when you code in Ruby.

Expressions

Everything is evaluated as an expression in Ruby: literals, method calls, variables… even a control structure has a value. For example you can do this in Ruby:

if num == "one" then val = 1
elsif num == "two" then val = 2
else then val = 3
end

But that is a weak use of Ruby’s power, instead you’d better do:

val = if num == "one" then   1
elsif num == "two" then  2
else 3
end

Return value

Ruby returns the last expression value as the return value of the method invocation, so you don’t need an explicit return statement.

def greeting(name)
  "Hello #{name}!"
end
puts greeting('khelll') #=> "Hello khelll!"

Together, the auto returned value and evaluating code as expressions are indeed a big support for pure functional code as finally they both serve the fact of having a value out of your method.

Higher-order functions

Functions are higher-order when they can take other functions as arguments, and return them as results. This is done in Ruby using lambda and block logic. If you don’t know how to use blocks, please do yourself a favor and visit this comprehensive article by Robert Sosinski.

Blocks in Ruby can help you do very nice things, one of them is ability to add control structure like syntax to your code. Check the following example, where a loop control structure is being defined:

# a trivial example that adds a loop control structure
# it takes a range and yields the passed block.
def loop(x,&b)
  for i in x do
    b.call(i)
  end
end
 
# use the above defined method
loop(1..10) do |x|
  puts x
end

Internal DSLs is also one of the nice things that you can achieve with block syntax in Ruby.

Currying and Partial Functions

Higher-order functions enable Currying, which the ability to take a function that accepts n parameters and turns it into a composition of n functions each of them take 1 parameter. A direct use of currying is the Partial Functions where if you have a function that accepts n parameters then you can generate from it one of more functions with some parameter values already filled in. Ruby 1.9 comes with support for this concept. check the following example:

# defining a proc that sums 2 numbers
plus = lambda {|a,b| a + b} #=> #<Proc:0x8e236ac@(irb):1 (lambda)> 
 
# notice the new call to procs in ruby 1.9 using the period symbol
plus.(3,5) #=> 8 
 
# i want a modified version of the above proc that fills the first parameter with the value '1'
# so i generate the currying then i use a partial function by supplying the first parameter
# with value '1'
plus_one = plus.curry.(1) #=> #<Proc:0x8dde908>
 
# I can use the new proc as normal
plus_one.(5) #=> 6

For extended example about currying, check Ruby Currying blog post by me .

Type systems and pattern matching

Pattern matching allows complicated control decisions based on data structure to be expressed in a concise manner. in simpler words, it’s a data structure based matching. Pure functional languages should support this concept, however and afaik this is still not supported in Ruby, but there are several trials to add this concept. check this blog post by Eric Torreborre.

Strict versus lazy evaluation

Strict evaluation always fully evaluates function arguments before invoking the function. Lazy evaluation does not evaluate function arguments unless their values are required to be evaluated. One use of Lazy evaluation is the performance increases due to avoiding unnecessary calculations.

However as the following example shows, Ruby use Strict evaluation strategy:

print length([2+1, 3*2, 1/0, 5-4])
=>ZeroDivisionError: divided by 0

The third parameter of the passed array contains a division by zero operation and as Ruby is doing strict evaluation, the above snippet of code will raise an exception.

Recursion

Iteration (looping) in functional languages is usually accomplished via recursion. Ruby doesn’t force you to recursion but it allows you to do so. However following recursion style has it’s own tax: Performance.
Ruby 1.9 comes with some “tail call optimizations”, more here.

Conclusion

1- As you can tell, Ruby helps you write in functional style but it doesn’t force you to it.
2- Writing in functional style enhances your code and makes it more self documented. Actually it will make it more thread-safe also.
3- The main support for FB in ruby comes from the use of blocks and lambdas, also from the fact that everything is evaluated as an expression.
4- Ruby still lack an important aspect of FP: Pattern Matching and Lazy Evaluation.
5- There should be more work on tail recursion optimization, to encourage developers to use recursion.
6- Any other thoughts?