Being very new to Ruby (2-3 days) and very familiar with Perl, I tend to
prefer { .. } for block delimiters.  From what I can tell in Ruby you can
use either do .. end or { .. } for blocks.  What if that flexibility was
also allowed for method definitions so that you could have:

def somemethod {
  ...

def somemethod
  ...
end

Perl and C folks would feel more 'at home' and it would be consistent with
the flexibility allowed for block definitions.  (and vi users could still
use the brace matching feature, shift-5, to find the start and end of a
method definition - yeah, I know, a method should be much shorter than a
page length, but sometimes it happens.).

Phil

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

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

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!

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:

  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.

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 see, no easy way to get Perl's or C/C++'s behavior here!

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

(...)

    Phil> Phil

\cle

P> Being very new to Ruby (2-3 days) and very familiar with Perl, I tend to
P> prefer { .. } for block delimiters.  From what I can tell in Ruby you can
P> use either do .. end or { .. } for blocks.

 Not really, "{ ... }" and "do ... end" are for an iterator (i.e. NODE_ITER)

 You can have a block (well a NODE_BLOCK) when you write

   if a
      p a
      p a
   end

 or

   begin
      p a
      p a
   end if defined? a

 Do you want also write ?

  {
     p a
     p a
  } if defined? a

 it seems ugly for me

Guy Decoux

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?

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.

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

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.

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

Play nice.  Don't assume bad motives on the part of the other party.
Always assume that the other party may have something important to
contribute even if you don't agree with their viewpoint.  If you think
that they're factually wrong, point it out to them, but do so in the
humility of knowing that you've been wrong before.  Enough preaching.

Anyway, I didn't mean to start some kind of argument here, my apologies.

Phil

--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------

In message "[ruby-talk:6995] block syntax/def syntax question/suggestion"

|Being very new to Ruby (2-3 days) and very familiar with Perl, I tend to
|prefer { .. } for block delimiters.  From what I can tell in Ruby you can
|use either do .. end or { .. } for blocks.  What if that flexibility was
|also allowed for method definitions so that you could have:

Request like this arise time to time.  But

  (a) Ruby should remain Ruby.  So the syntax enhancement should done
      in compatible way.

  (b) The human brain is very flexible enough to handle several syntax
      at the same time, like me using Japanese and English.  The
      grammatical variety does not help programmers in real life, but
      often bring troubles to them, making programs appear unstable.

  (c) Proper tool like ruby-mode.el for Emacs helps.

  (d) Despite all the sentences above, I don't refuse syntax
      enhancement.  But it's hard to design compatible enhancement.  I
      have tried several times (the first one was at 1995), and all my
      trials failed.

In a word, although I believe in TMTOWTDI, variety of core syntax
might be too much.

                                                        matz.

By the way, "There's More Than One LANGUAGE to Do it" was the word of
Larry Wall at the Perl/Ruby Conference in Kyoto.

Also I have seen more than my share of anti-Perl FUD from
supporters of languges that see themselves as competing
with Perl.  (Languages like Python.)  That leaves me a little
sensitive. :-(

Apologies if I misread the situation.  But I read it
through several times, and each time found myself reacting
at the same place.

[...]

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

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

[...]

At this point I was convinced that you were trying to lecture
on the internals of Perl, and what you are saying about them
is very very far from correct.  In fact you are going through
a lot of energy to emphasize that blocks have "no other role"
when in fact they do have other roles.

Had you limited yourself to saying that the exposed behaviour
is different, I would have reacted substantially less.

This is to imitate the way that map, grep, sort etc work.

I think that the best explanations about why specific things
do not fit into Ruby should involve only the design of Ruby.

[...]

A good rule of thumb.  If someone proposes new syntax, don't
look for implementation problems.  Look for syntactical
issues.  Implementation quirks can be solved and ironed out.
Syntactical issues get fixed in stone and turned into
backwards compatibility problems.

Is it legitimate in Ruby to have a function named "else"
that takes one argument and have "func" take 3?

Eww...

read more »