>>>>> "Ben" == Ben Tilly <ben_tilly / hotmail.com> writes:

Ben> Clemens Hintze <c.hintze / gmx.net> wrote:
>>  >>>>> "Phil" == Phil Tomson <ptkwt / user2.teleport.com> writes:
>>
Phil> Being very new to Ruby (2-3 days) and very familiar with
>>  Then, may I welcome you here? We really appreciate everyone
>> who wants to give it a try :-)

Ben> I only wish the rest of your tone was as welcoming.

Ahh ... what? Do you think my tone was unpolite or rude??? Wow! How
have you got that impression?

(...)

>>  And here is one BIG difference between Ruby and Perl. In Perl
>> the { ... } are merely block delimiters. You are right! And so
>> for Ruby's usage of { ... }.

Ben> Merely?

Yes, merely! But see below, please ...

Ben> The rest of my reply will have an annoyed tone BECAUSE YOU
Ben> without having any CAUSE to yell.

What??? Yelling??? Now you do astonish me! How got you that
impression? Is it because I use upcase letters to emphase (catch eye)
some words?  I do that regulary, sometimes I use also convention like
*that* or _this_. IIRC, nobody has ever accused me to yelling by doing
so (not that this counts anyhow, as my memory is very short timed ;-)

In regulary documents, I would use kursive or bold font. What should I
use in ASCII documents to {\em not} offend peoples like you?

Anyway, I beg pardon for giving you the impression of yelling!

But why do you think, that I (...)CLEARLY KNOW NOTHING ABOUT(...), is
beyond my horizon. Perhaps I have explained it from another point of
view? Perhaps from a more abstract view, dismissing all internals how
it is iplemented? Had you taken these into account before accusing me?
If not, then, sorry to say that, I found your tone a bit rude!

However, if you had taken into account those, why are you still
thinking that I do know nothing about it?

Ben> Is it really such a hard rule to be sure you know what you
Ben> are talking about before you yell?

I thought I am sure. But perhaps you have misunderstood me?

>> BUT in Ruby a block (let me call it R-BLOCK) is a TOTALLY
>> DIFFERENT thing as a block in Perl (P-BLOCK). A P-BLOCK only
>> groups statements in the source and is only used via
>> compilation stage to determine such groups of statements!

Ben> It is not obvious to the casual scripter, but a block in Perl
Ben> is a lot more than just a group of statements.

Not if I view and explain it from an very abstract point of view! I
know that in Perl every thing is an object; but not in an OOP sense. I
know that block are complex internally. But I believe to express the
difference in Ruby and Perl it would not be necessary to go into
internals.

>> R-BLOCKs, however, constitutes REAL OBJECTS that happen to
>> CONTAIN code. Only the R-BLOCKs objects are not DIRECTLY
>> accessible like any other object. You may access them via:

Ben> WHY ARE YOU YELLING?

I AM NOT YELLING! Sorry I couldn't resist ;-)

Ben> They are not directly accessible in Perl either.  But they
Ben> are real internal things.  There are rather fewer obvious
Ben> hooks, but what do you think a scope is attached to?  At the
Ben> end of a block is when garbage collecting etc takes place.
Ben> Blocks are what you hang lexical variables off of.  If you
Ben> start generating closures in Perl, you start producing new
Ben> blocks.  And conversely the continued existence of a block is
Ben> necessary for closures to work properly, each variable knows
Ben> which copy of the block it is associated with.

I know this. But from my explanation POV, I thought it was not
necessary to go so far. In C/C++ blocks are also created via {
... }. They also can own automatic variables with a certain scope. But
there, they are not complex objects like in Perl. But from the
programmer's POV they looks and feel like Perl ones. That was what I
tried to explain.

Ben> As a result, far from just being a group of statements, a
Ben> block in Perl has a considerable internal structure.  In fact
Ben> there is real overhead both entering and leaving a block
Ben> because of everything that goes on then.

I know; again: It was an abstraction and simplification. As I cannot
access blocks from a Perl program, I see them as C/C++ like
blocks. But I know they are not equal.

>> yield : Calling an associated block block_given? : Check if an
>> block is associated proc | lambda | Proc.new : Convert a block
>> to a Proc instance &var : - In formal parameter list, convert
>> attached block to a Proc instance and pass that to 'var' - In
>> an actual parameter list, converts a Proc instance back to a
>> R-BLOCK object.

Ben> The internal organization of Perl exposes no equivalent to
Ben> that That doesn't mean that the internal organization of a
Ben> block in Perl isn't a fairly complex thing.

That was not what I had intend. Only to explain the difference. Ruby
blocks may be accessed/converted via Ruby commands; so that makes them
{\em objects} for me. Perl ones couldn't, that makes them more like
C/C++ blocks for me.

I know in reality this is not true. I also believe that the internal
realization of ruby blocks and perl blocks is not too different. But
I thing that most often it is a good thing to avoid such internals if
your goal is only to explain simple behavior. But perhaps my way is
not your way of explaning things. But I hope that group is large
enough for our both ways of explanation. :-)

Ben> (There has been discussion in Perl of adding continuations.
Ben> But a couple of key people (eg Mark Dominus) don't want it
Ben> for various internal reasons.)

>> Whereby a Proc instance is something similar to Perl's sub
>> reference:
>>
>> sub { ... };
>>
>> To stress it again, that do ... end and { ... } constitutes
>> REAL objects, that can be dealt with.
>>
>> Statements like 'def', 'if', 'for', etc. that need only
>> statement grouping, but not no R-BLOCK objects, will have the
>> different syntax/convention, that the statement opens the
>> grouping and a corresponding 'end' will close it.

Ben> You have not actually explained why all of this extra
Ben> behaviour cannot exist but not be accessible.  Or why similar

Because, perhaps, as blocks in Ruby opens new scope as in Perl, but it
does not in statement like: 'if', 'while', ...

Of course you could have blocks behaving different if used for a 'if'
than used otherwise. But that would make the handling inconsistent,
IMHO.

Ben> syntax in different places cannot wind up being internally
Ben> being represented differently.  In fact Ruby already does
Ben> that.  Syntactically what is the difference between a block
Ben> and a hash?

Caught me! Of course your could do this. But that would makes it even
more difficult to parse things like that:

if func { ... }

Would func getting { ... } as argument, or is { ... } the then-block
of the 'if' statement. You could solve that, but I think it is not
worth the trouble. Especially, as I already mentioned, you then-block
shall not open a new scope in opposition what every Ruby block do!

Or if you do this:

if func { ... } {
...
} else {
...
}

looks pretty ugly, IMHO!

>> You see, no easy way to get Perl's or C/C++'s behavior here!

Ben> No, your explanation doesn't explain that for me.  It *DID*
Ben> tell me that you are willing to pontificate about Perl
Ben> without really understanding it, but failed to convince.

It may be that it failed to convince you! My fault then. But please do
not accuse me to something I have not intent.

Ben> Now as it happens, even being pretty unfamiliar with the
Ben> language, I can come up with a very good reason why Ruby
Ben> would not want to match Perl's behaviour.  Here it is.

(... really good explanation snipped ...)

Ben> Was that so hard?  A simple explanation delivered without
Ben> having to go out on a limb about how the internals of other
Ben> languages work, and without any need to yell.

I have never told anything of the internals of other languages or Ruby
in my Mail. Right opposite to that! I have tried to avoid internals
and show it from a abstract and simplified POV.

It was {\em you} that has assumed and accused me to do this!

>> I hope you will anyway find fun with Ruby :-)

Ben> Seeing you YELL incorrect stuff about other languages in
Ben> response to a reasonable question does take the blush
Ben> off. :-(

I hope that my explanation makes clear what I had intent with my
explanation. Except the yelling thingy -- that I didn't know its
offending potential -- I think I have not doing anything wrong. I
really hope you will understand my intention correclty after my
explanation.

Let us try to stay in peace here. There should be enough place for us
both!

> Sincerely, Ben

Best regards,
\cle