From: Robert Klemme Date: 2009-01-11T02:19:31+09:00 Subject: Re: functional programming On 10.01.2009 15:50, Mike Gold wrote: > Brian Candler wrote: >> Mike Gold wrote: >>> Pascal was making a simulation of first-class functions in ruby. The >>> difference between lambda { } and a real first-class function is quite >>> profound. >> For the benefit of this duffer, could you briefly explain the >> difference? > > It has already been shown. You need to make a sincere effort to > understand the post to which you replied. If you did not understand > Pascal's post, then ask a question. Frankly, I find this reply of yours at least unhelpful if not hostile (which might just be an effect of brevity). That question (which was quite precise, even contrasting a definition of "first class functions" with Ruby's capabilities) actually refers to a statement that you made so you could at least point to the explanation you have seen. From what I see Pascal creates a DSL that mimics Lisp in Ruby - with all the basic functions like cons, car and all the bracketing (which is by no means needed for a functional language). He also contrasts Ruby's capabilities with (Common) Lisp's. But: Lisp is just one functional language among many and the fact that expressions are objects in Lisp and the special feature of Lisp macros is not mandatory for a functional language as far as I can see. http://en.wikipedia.org/wiki/Functional_programming So, while we can agree that Ruby != Lisp - and especially Ruby lacks Lisp's macros and access to expressions as objects - there is nothing that prevents functional programming in Ruby at all. And you do neither need Lisp's syntax for this nor Lisp's macros. Back to Brian's original question: When reading through Pascal's statements in this thread the only thing that I can see so far is that Ruby cannot treat arbitrary expressions as objects. But as I said, this does not seem to be a mandatory feature of a functional language. http://en.wikipedia.org/wiki/First-class_function I tend to agree with Martin DeMello's statement about the two core concepts of functional programming. The only thing I would add is that while programming without side effects might not make sense in Ruby it is possible nevertheless. You pay a price in GC overhead but this is irrelevant for answering whether Ruby has functional capabilities. Regards robert -- remember.guy do |as, often| as.you_can - without end