Pascal J. Bourguignon wrote:
> Of course, if ruby is not good at optimizing functional code, and this
> posed any performance problem in the deployed applications, you would
> better switch to Common Lisp or Haskell.

Perhaps most importantly, Ruby doesn't optimise tail recursion (although 
I think I read somewhere that ruby1.9 can do this, but only if you set a 
flag when compiling the interpreter)

It's also true that cons(a,b) is going to be more efficient than [a] + 
b, because the latter creates a whole new Array object and copies all 
the elements. (This is of benefit primarily for algorithms which 
generate new lists by prepending elements to the front of existing 
lists)

However if you don't care about this, you can write your functional 
algorithms using Ruby's Array as if it were a list.

class Array
  def car
    self[0]
  end
  def cdr
    self[1..-1]
  end
end

If you want though, you can create a true Cons object in Ruby. If you 
make it Enumerable then you can keep much of the Ruby goodness in that 
area.

class Cons
  include Enumerable
  attr_accessor :car, :cdr
  def initialize(car, cdr = nil)
    @car = car
    @cdr = cdr
  end
  def each(&blk)
    yield @car
    @cdr.each(&blk) if @cdr
  end
  class << self
    alias :[] :new
  end
end

l = Cons[1, Cons[2, Cons[3]]]
puts l.inject(0) { |acc,v| acc + v }
m = Cons[4, l]
puts m.inject(0) { |acc,v| acc + v }

p l.to_a    # using Enumerable#to_a
p m.to_a

You may find this more attractive than going the whole 
"lets-pretend-Ruby-is-Lisp" approach. Similarly, I don't really see the 
need to define a 'function' again from scratch, when you have lambda 
{...} natively.
-- 
Posted via http://www.ruby-forum.com/.