[ruby-talk:7046] Re: block syntax/def syntax question/suggestion

Clemens Hintze <[e-mail]> wrote:
>
> >>>>> "Ben" == Ben Tilly <[e-mail]> writes:
>
>     Ben> Clemens Hintze <[e-mail]> wrote:
>     >>  >>>>> "Phil" == Phil Tomson <[e-mail]> 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?

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.

[...]
>     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. :-(

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

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

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

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

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

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

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

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

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

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

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

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

Your emphasized statement that blocks "only group statements"
really looked to me to be commentary on the internals of
Perl.  That is what I reacted to, and I apologize again for
my strong reaction to this misunderstanding.

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

Glad you liked it. :-)

>     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 understand how it happened.  Hopefully we can
both work to avoid further misunderstandings like that.

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

I believe I do.

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

Amen.

> > Sincerely, Ben
>
>Best regards,
>\cle

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