>>>>> "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> ARE YELLING ABOUT SOMETHING YOU CLEARLY KNOW NOTHING ABOUT
    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