From: Florian Frank <flori@...>
Date: 2005-03-22T00:01:29+09:00
Subject: Re: Paul Graham recommends Ruby

David A. Black wrote:

> Are you saying you'd like to have foo {} be the same as foo({})

Not necessarily, I only pointed out, that there is a problem, that could 
be resolved with a different empty hash constructor, like

def foo(h) h.class end

foo [:] # => Hash

Or even Hash[] and Hash['a': 1, 'b': 2] for Hash.[]. It would also be 
possible to have Tree['a': 1, 'b': 2] in this case. What is the impact 
on the planned keyword syntax in this case?

> (assuming both are lambdas/blocks)?  But then, what about:
>
>   def foo; end
>   foo {}        # called with block, or wrong # of arguments?
>
> As often happens, the solution:
>
>   foo() {}
>
> involves more punctuation :-)

True, but the real source of the problem is, that Ruby handles block 
parameters differently than other parameters. I don't think, that this 
is really necessary, things could be made far easier here.

It's difficult to answer questions, like: Why don't I have to declare 
block parameters like other parameters? But if I do, why do I have to 
use this weird &-sigil? Why do I have to use it, if I want to pass the 
block to another method, that expects a block? Why can I call every 
method, that doesn't expect a block, with a block, that will be silently 
ingored? Why can't I pass more than one block to a method?

The answers to those question would perhaps include, that the block 
syntax wasn't intended be of such a general usefulness for functional 
objects, closures and the like, but only as an iteration construct. For 
2.0 it would be a good idea, to get rid of this bad legacy. It would 
perhaps be a good idea to make {} the Proc constructor, abandon 
non-objectified blocks (what about the performance trade off?) in favor of

def foo(block)
  block[]
end
foo {}

or

def foo(b1, b2)
  b1[]
  b2[]
end
foo {}, {}

and perhaps define the following

def foo(b1, b2)
  b1.call
  yield # always the last block declared is executed
end

> But Ruby isn't within miles of having that problem.  My point is that
> I don't like the idea of just putting things in Ruby because they are
> the culture and heritage of *other* languages.  Nor do I think that if
> something is part of the culture and heritage of Ruby, it therefore
> has to be removed :-)  (I know you weren't saying that.)
>
I suspect, things got screwed up step by step in Perl, too. This will 
always be a problem, if people stop asking questions (like I did above), 
why things are done in this and such a way, even if the answers cannot 
really satisfy.

-- 
Florian Frank