From: "Adam P. Jenkins" Date: 2005-06-30T04:50:42+09:00 Subject: Re: iterators and block arguments Daniel Brockman wrote: > "Adam P. Jenkins" writes: > > >>Eric Mahurin wrote: >> >> >>>"Adam P. Jenkins" wrote: >>> >>> >>>>Rather I have to wrap print in a block: >>>> >>>> myArray.each { |elem| print elem } >>>> >>>>Wouldn't it have been cool to just be able to write: >>>> >>>> myArray.each print > > > Due to the deeply object-oriented nature of Ruby, I think your > semantics (call a global method with each element as argument) are > neither very feasible nor very useful. Not true at all. An OO language just has to support the concept of a bound method reference. For example, in Python: # Here's an unbound method of the "file" class: >>> file.write >>> # Here's a bound method >>> sys.stdout.write # Here's how you can use a bound method reference >>> w=sys.stdout.write >>> w("Hello\n") Hello >>> The assignment to "w" creates a bound method reference, that not only knows what method it refers to, but which object to send the method call to. C# implements a similar concept, and there's no fundamental reason that any OO language couldn't. So I don't agree at all that OO and functional paradigms don't mix in this regard. > > >>>The reason you can't is because a method name by itself calls >>>the method instead of returning the method object. >> >>Ok, fair enough. I would still prefer just >> >> myArray.each :print > > > Unfortunately, there is no straightforward way to redefine `each', > since every class has its own implementation. I'm just having an theoretical "could have been" discussion. I'm not suggesting there's any practical way to change things at this point. >>Obviously you can do what you need to do in the current Ruby >>implementation, it's just annoying and inconsistent in the same way >>that it's annoying in Java that you need to box or unbox primitive >>types depending on the context. Even the Java 1.5 syntactic sugar >>for autoboxing doesn't completely hide the distinction. Coming from >>programming in functional languages, Ruby's distinction between >>blocks, closures, and methods seems similarly unnecessary at a >>language level, though like Java's primitive/Object distinction, >>it's probably a useful compromise for runtime efficiency. > > > It doesn't sound like you have anything concrete to contribute. > No, Ruby is not Haskell --- so what? Hey now, that's an unnecessary low blow. Or are you suggesting we should forgo theoretical discussion, and limit ourselves to discussing things which are actually likely to make it into the next version of Ruby? This is a language newsgroup, and this a thread about arguably inconsistent semantics concerning blocks and procs. I'm not suggesting Ruby should be a certain way *because* some other language is that way, but rather I'm critiquing a certain aspect of the Ruby language by way of comparison to other languages. When I first started programming in Ruby, I didn't understand why it had separate concepts for blocks and closures, but I figured maybe it would become apparent after using it for a while. One guess I made was that maybe the first version of Ruby only had block/yield, and when it became apparent that blocks were too limited, procs were added as a more general mechanism, but block/yield had to stay for backward compatibility. After using Ruby at work for several months now, I've come to the conclusion that there is no good reason for the distinction at the language level, though at an implementation level, I have seen it mentioned that yield operates faster than Proc#call. I'd still be interested though in hearing if there is another rationale for the distinction. Adam