Hi --

On Tue, 22 Mar 2005, Florian Frank wrote:

> 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.

I still don't have my head around the new block param syntax... but
isn't it going to be more different from methods than the current one?

> 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?

Some of these questions are harder than others :-)  To the last two, I
would say: every method call can take an optional code block, to which
transfer can be controlled with 'yield'.  I guess I accept that as a
design characteristic.

> 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

That leaves me asking: if yield has this situation-dependent behavior,
why does it exist at all?  I'm afraid to say it -- I don't want to
appear too non-questioning :-) -- but I actually like the singularity
of the block/yield chain.  If the block is done away with (not likely,
I suspect), then 'yield' makes no sense.  If one were designing a
language where blocks were always objectified and always treated as
regular arguments, I don't think one would ever come up with the idea
of a special keyword to call the last one in a list.

>> 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.

I don't think we're in any danger of people not questioning Ruby's
design enough :-)


David

-- 
David A. Black
dblack / wobblini.net