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 :-)

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

>     Phil> Perl, I tend to prefer { .. } for block delimiters.  From
>
>Yes ... but see below ...
>
>     Phil> what I can tell in Ruby you can use either do .. end or {
>     Phil> .. } for blocks.  What if that flexibility was also allowed
>     Phil> for method definitions so that you could have:
>
>     Phil> def somemethod { ...  }
>
>     Phil> in addition to the current syntax:
>
>     Phil> def somemethod ...  end
>
>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 { ... }.

Merely?

The rest of my reply will have an annoyed tone BECAUSE YOU
ARE YELLING ABOUT SOMETHING YOU CLEARLY KNOW NOTHING ABOUT
without having any CAUSE to yell.

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

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

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

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

WHY ARE YOU YELLING?

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

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

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

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

(There has been discussion in Perl of adding continuations.
But a couple of key people (eg Mark Dominus) don't want it
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.

You have not actually explained why all of this extra
behaviour cannot exist but not be accessible.  Or why
similar syntax in different places cannot wind up being
internally being represented differently.  In fact Ruby
already does that.  Syntactically what is the difference
between a block and a hash?

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

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

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

  Suppose we see this snippet of code:

    def what_am_i  (n,m) {
      n, m
    }

  well with the proposed rule this should return two
  things.  But there is already reasonable and defined
  behaviour if I show you a little more:

    def what_am_i  (n,m) {
      n, m
    }
    end

  which (less obfuscated) is a fairly reasonable
  function:

    def what_am_i  (n,m)
      {n, m}
    end

    what_am_i("a", "hash\n")["a"] #-> "hash"

  Making parsing this kind of construct ambiguous is a
  rather dangerous design decision.

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

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

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

Sincerely,
Ben
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com