block syntax/def syntax question/suggestion 
Author Message
 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:

def somemethod {
  ...

Quote:
}

in addition to the current syntax:

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



Thu, 29 May 2003 09:59:46 GMT  
 block syntax/def syntax question/suggestion

    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



Thu, 29 May 2003 22:09:25 GMT  
 block syntax/def syntax question/suggestion

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



Thu, 29 May 2003 22:32:19 GMT  
 block syntax/def syntax question/suggestion

Quote:


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

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

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

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

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

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

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

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



Fri, 30 May 2003 01:49:46 GMT  
 block syntax/def syntax question/suggestion

Quote:


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

Being the original asker of the question.... I really didn't think he
(Clemens) was 'yelling' in his response.  

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

Yeah, this makes some sense, thanks.

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

Again, I didn't think anybody was yelling (till now, of course).  I didn't
totally understand the original repsonse, but I figured that I needed to
study Ruby a bit more in order to make more sense of it (I assumed the
problem was on my side).

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

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



Fri, 30 May 2003 08:00:06 GMT  
 block syntax/def syntax question/suggestion
Hi,

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.



Fri, 30 May 2003 12:42:09 GMT  
 block syntax/def syntax question/suggestion

Quote:




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

>Being the original asker of the question.... I really didn't think he
>(Clemens) was 'yelling' in his response.

Hmm.  Perhaps it was his EMPHASIZING points that were wrong
which got my goat.  I guess I am very sensitive to
capitalized words. :-(

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



Fri, 30 May 2003 12:22:49 GMT  
 block syntax/def syntax question/suggestion



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

Quote:
> Sincerely, Ben

Best regards,
\cle


Fri, 30 May 2003 19:39:00 GMT  
 block syntax/def syntax question/suggestion

Quote:




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

Because I am very sensitive to capital letters.  After
private discussion and re-reading your message it is
evident that you did not intend to come across as
yelling.  Please accept my sincere apologies for that
misreading.

[...]

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

I would never have misread *this* or _that_.  But EMPHASIS is
very loud to my eyes, and after such loudness my brain doesn't
work very well. :-(

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

I did not find your explanation consistent with a more
abstract point of view for reasons I will try to make clear.

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

Please understand, as soon as you start talking about
compilation it appears that you are talking about the actual
internals.  And when you emphasize that it *only* used in
compilation, that indicates that you think it has no other
role, and it is important for the reader to understand that.

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.

- Show quoted text -

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

If you know this, then why are you emphasizing that under the
hood Ruby blocks are so different from Perl blocks?

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

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

I am at least consistent in my misinterpretation of what
you meant. :-/

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

There is actually one situation where a Perl block can be
accessed and converted to an anonymous subroutine, and that
is when passed to a function whose prototype has an "&" in
it.  Perl's prototypes are one of the messier "features"
(I call it a mistake) of the language.

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

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

I suspect that they are similar as well.  But I don't know
enough about Ruby's internals to say for sure.

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

[...]

Quote:
>     >> 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', ...

Now *that* is a good reason.

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

Or you could have blocks scoping differently if delimited
in different ways.  That would, in fact, be a reasonable
compromise if a syntax was found that fit.

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

Well it was obvious to me because I am painfully aware in Perl
of how Byzantine the parsing rules can become for telling an
anonymous hash apart from a block.  So as soon as I saw {...}
being used in Ruby for both... :-)

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

See, there are lots of problems!

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.

Quote:
>Or if you do this:

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

>looks pretty ugly, IMHO!

Oh! Oh! Oh!

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

Eww...

- Show quoted text -

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

...

read more »



Fri, 30 May 2003 23:23:21 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Implementing letrec-syntax using only let-syntax and syntax-rules

2. Syntax Questions for a new language with somewhat Smalltalk-like syntax

3. Syntax-case vs. syntax-rules

4. syntax in syntax

5. is define-syntax inside define-syntax OK?

6. define-syntax must be followed by syntax-rules ??

7. unusual define-syntax syntax

8. Converting AT&T syntax to Intel syntax

9. problem translating nasm syntax to gas syntax

10. inline assembler error - porting Intel syntax to AT&T syntax

11. Actual USEFULNESS of old Syntax (was Re: New Syntax -- with an implementation)

12. Lisp syntax : Lisp objects :: Scheme syntax : characters

 

 
Powered by phpBB® Forum Software