Rick DeNatale wrote:
Why do I get the impression that this thread is trying to develop a
new language called FrankenRuPy? <G>
Now, now! It's just a sweet little creation. It couldn't hurt anyone could it ?
B
What if it does? It might accidentally cause the death of the mad
scientist that created it, and attract the attention of the townsfolk
who will come with torches and pitchforks to kill the beast! Oh noes!
Oh, wait, that's the plot of an old book. Never mind.
···
On Tue, May 22, 2007 at 07:05:04AM +0900, Brad Phelan wrote:
Rick DeNatale wrote:
>Why do I get the impression that this thread is trying to develop a
>new language called FrankenRuPy? <G>
>
>Now, now! It's just a sweet little creation. It couldn't hurt anyone
could it ?
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of others
we should be glad of an Opportunity to serve others by any Invention of
ours, and this we should do freely and generously."
Chad Perrin wrote:
Rick DeNatale wrote:
Why do I get the impression that this thread is trying to develop a
new language called FrankenRuPy? <G>Now, now! It's just a sweet little creation. It couldn't hurt anyone could it ?
What if it does? It might accidentally cause the death of the mad
scientist that created it, and attract the attention of the townsfolk
who will come with torches and pitchforks to kill the beast! Oh noes!Oh, wait, that's the plot of an old book. Never mind.
I upgraded the little library so that it has better error detection
and can handle else, end and rescue dedents even if the colon : eol
operator has been used.
http://xtargets.com/snippets/posts/show/68
def foo:
[1,2,3,4].each do |i|:
puts i
[1,2,3,4].each do |j|:
puts i
if i == 2 :
puts "foo"
else:
puts "bar"
is now possible. BTW if this triggers a rubyforge project I do like
the name "Frankenrupy", Rick!
Brad Phelan wrote:
Chad Perrin wrote:
Rick DeNatale wrote:
Why do I get the impression that this thread is trying to develop a
new language called FrankenRuPy? <G>Now, now! It's just a sweet little creation. It couldn't hurt anyone could it ?
What if it does? It might accidentally cause the death of the mad
scientist that created it, and attract the attention of the townsfolk
who will come with torches and pitchforks to kill the beast! Oh noes!Oh, wait, that's the plot of an old book. Never mind.
I upgraded the little library so that it has better error detection
and can handle else, end and rescue dedents even if the colon : eol
operator has been used.http://xtargets.com/snippets/posts/show/68
def foo:
[1,2,3,4].each do |i|:
puts i
[1,2,3,4].each do |j|:
puts i
if i == 2 :
puts "foo"
else:
puts "bar"is now possible. BTW if this triggers a rubyforge project I do like
the name "Frankenrupy", Rick!--
Brad Phelan
http://xtargets.com
In general I think that above is not a good idea for Ruby. However it does look good when dealing with libraries like Markaby where the number of closing ends starts to look very scary From some of my own templates
table do
@components.each do |row|
tr do
row.each do |col|
td do
pre do
text col
end
end
end
end
end
end
end
whereas it could look like
table do :
@components.each do |row| :
tr do
row.each do |col| :
td do :
pre do :
text col
which gives it a feel like a YAML file.
Hi --
In general I think that above is not a good idea for Ruby. However it does look good when dealing with libraries like Markaby where the number of closing ends starts to look very scary From some of my own templates
table do
@components.each do |row|
tr do
row.each do |col|
td do
pre do
text col
end
end
end
end
end
end
endwhereas it could look like
table do :
@components.each do |row| :
tr do
row.each do |col| :
td do :
pre do :
text colwhich gives it a feel like a YAML file.
I prefer Ruby files that feel like Ruby files (why is everyone so
concerned with trying to figure what, other than Ruby, Ruby should
look like?), but meanwhile if you use standard indentation (and get
rid of the extraneous end in your example 
it looks a lot nicer to
start with:
table do
@components.each do |row|
tr do
row.each do |col|
td do
pre do
text col
end
end
end
end
end
end
David
···
On Tue, 22 May 2007, Brad Phelan wrote:
--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
dblack@wobblini.net wrote:
I prefer Ruby files that feel like Ruby files (why is everyone so
concerned with trying to figure what, other than Ruby, Ruby should
look like?), but meanwhile if you use standard indentation (and get
rid of the extraneous end in your example
start with:table do
@components.each do |row|
tr do
row.each do |col|
td do
pre do
text col
end
end
end
end
end
endDavid
But I want a *blue* bike shed next to *my* nuclear power plant. <ducking>
Anyhow, here's a couple of examples of things pretty much "standard Ruby" that I still find confusing coming from other descendants of Algol 60 syntax:
1. attribute_accessor :person
self.person = "Ed"
I really want it to be "attribute_accessor person" -- the constant mixing of the same name with and without a preceding colon in Ruby is as confusing to me as Perl's "$hash{'key'}" referring to an entry in "%hash" vs. another variable entirely called "$hash".
2. Both curly braces and begin / end pairs to define scope, with one variant having a higher binding priority than the other. The fact that I don't even remember which one it is that has the higher binding priority is an added factor in my dislike.
There are some others, but those are the two biggies. I'm slowly getting used to semicolons as separators and open syntactic forms forcing a continuation, but even those irritated me at first when I started learning R after spending a number of years with Perl.
And with the judicious use of {} vs. do end there are other
alternatives which may suit individual tastes depending on how tightly
you like to see the code:
table do
@components.each do |row|
tr do
row.each do |col|
td {pre {text col}
end
end
end
end
or the ultra tight:
table {@components.each {|row| tr {row.each {|col| td {pre {text col}}}}}
or if you aren't religious about reserving brackets for one-line
blocks (I'm not):
table {
@components.each { |row|
tr {
row.each { |col|
td {pre {text col}
}
}
}
Or anywhere in-between.
···
On 5/22/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
Hi --
On Tue, 22 May 2007, Brad Phelan wrote:
> In general I think that above is not a good idea for Ruby. However it does
> look good when dealing with libraries like Markaby where the number of
> closing ends starts to look very scary From some of my own templates
>
> table do
> @components.each do |row|
> tr do
> row.each do |col|
> td do
> pre do
> text col
> end
> end
> end
> end
> end
> end
> end
>
> whereas it could look like
>
> table do :
> @components.each do |row| :
> tr do
> row.each do |col| :
> td do :
> pre do :
> text col
>
> which gives it a feel like a YAML file.I prefer Ruby files that feel like Ruby files (why is everyone so
concerned with trying to figure what, other than Ruby, Ruby should
look like?), but meanwhile if you use standard indentation (and get
rid of the extraneous end in your example
start with:table do
@components.each do |row|
tr do
row.each do |col|
td do
pre do
text col
end
end
end
end
end
end
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
dblack@wobblini.net wrote:
Hi --
In general I think that above is not a good idea for Ruby. However it does look good when dealing with libraries like Markaby where the number of closing ends starts to look very scary From some of my own templates
table do
@components.each do |row|
tr do
row.each do |col|
td do
pre do
text col
end
end
end
end
end
end
endwhereas it could look like
table do :
@components.each do |row| :
tr do
row.each do |col| :
td do :
pre do :
text colwhich gives it a feel like a YAML file.
I prefer Ruby files that feel like Ruby files (why is everyone so
concerned with trying to figure what, other than Ruby, Ruby should
look like?), but meanwhile if you use standard indentation (and get
rid of the extraneous end in your example
start with:
I am not concerned really either way with the indentation thingie. I
don't think that is the main difference between python and Ruby. In my op' the fact that Python does not do generic blocks is the main arguing point. I am not sure why the indentation issue raises so much heat.
What interests me about this thread is that, if you wish,
you can transparently add your own dialect to ruby by overloading
require. I've done the same thing before to load ERB files as if
they were real ruby files on the path. I jumped in at the challenge
of the OP as to whether transparent preprocessing is possible. The fact that it is and so simply is a nice sign of the power of the ruby language.
B
···
On Tue, 22 May 2007, Brad Phelan wrote:
M. Edward (Ed) Borasky wrote:
...
But I want a *blue* bike shed next to *my* nuclear power plant. <ducking>
Coming soon from the Pragmatic Programmers: "What Color is Your Bike Shed?" (Chapter 1: Why Ruby Syntax Sucks; previews are available on ruby-talk.)
Anyhow, here's a couple of examples of things pretty much "standard Ruby" that I still find confusing coming from other descendants of Algol 60 syntax:
1. attribute_accessor :person
self.person = "Ed"
I really want it to be "attribute_accessor person" -- the constant mixing of the same name with and without a preceding colon in Ruby is as confusing to me as Perl's "$hash{'key'}" referring to an entry in "%hash" vs. another variable entirely called "$hash".
I can understand that being confusing at first, if you've never used an expression-based language, but once you have seen code in which the argument is evaluated from some nontrivial expression (or called from some other class method), you should find it not at all strange, but rather like an old friend.
attr_accessor(*File.read("attr_list").split)
It starts getting confusing again when you have to remember that the alias keyword _doesn't_ work this way (but Module#alias_method does).
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Hi --
Anyhow, here's a couple of examples of things pretty much "standard Ruby" that I still find confusing coming from other descendants of Algol 60 syntax:
1. attribute_accessor :person
self.person = "Ed"
I really want it to be "attribute_accessor person" -- the constant mixing of the same name with and without a preceding colon in Ruby is as confusing to me as Perl's "$hash{'key'}" referring to an entry in "%hash" vs. another variable entirely called "$hash".
That's not a syntax vagary, though. Consider:
class C
x = "y"
attr_accessor x
end
C.new.y = 1
You only get the "inert" identifier behavior with keywords
x = 1
def x # not 1, of course
end
alias old_x x # ditto
attr_accessor is just using normal method-argument syntax/semantics.
David
···
On Wed, 23 May 2007, M. Edward (Ed) Borasky wrote:
--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
But I want a *blue* bike shed next to *my* nuclear power plant. <ducking>
Anyhow, here's a couple of examples of things pretty much "standard
Ruby" that I still find confusing coming from other descendants of Algol
60 syntax:1. attribute_accessor :person
self.person = "Ed"
I really want it to be "attribute_accessor person"
I assume you meant attr_accessor which is a method which takes one or
more symbols or strings and generates methods with names based on
those strings which reference instance variable names based on those
strings.
attr_accessor person
would use the VALUE of the variable person as the name, and since
person would likely not be defined yet, that value would be nil.
-- the constant
mixing of the same name with and without a preceding colon in Ruby is as
confusing to me as Perl's "$hash{'key'}" referring to an entry in
"%hash" vs. another variable entirely called "$hash".
I won't comment on perl's use of sigils in this regard.
2. Both curly braces and begin / end pairs to define scope, with one
variant having a higher binding priority than the other. The fact that I
don't even remember which one it is that has the higher binding priority
is an added factor in my dislike.
I think there's some misunderstanding here.
Curly braces are used to denote a proc, begin/end delimits a sequence
of expressions which are executed in sequence and whose value is the
last expression executed. Begin blocks are usually used with internal
rescue clauses for exception handling. The pickaxe classifies
begin/end as an operator with low precedence thus
a * fred + begin
puts "Hi mom"
5
end
is evaluated as
(a * fred ) + (begin
puts "Hi mom"
5
end)
{} and do/end aren't operators, but in almost all cases delimit procs
and so the question of their relative priority is moot as far as I can
tell since you can't have two procs next to each other in ruby source.
As for the 'binding priority' of {} vs. begin/end, I'm not sure I can
think of a legal situation in which the sequence
{...} begin...
could even occur in ruby code with no line break before the begin.
But I could be wrong.
There are some others, but those are the two biggies. I'm slowly getting
used to semicolons as separators and open syntactic forms forcing a
continuation, but even those irritated me at first when I started
learning R after spending a number of years with Perl.
When learning a language, I think that it's best to work with these
irritations until the logic of why they are there starts to reveal
itself with experience. Fighting it just inhibits learning how to
think in the new language.
I wouldn't expect that English should be changed so that the order
natural of his nouns and his adjectives in her sentences would be
reversed; or that the articles before all of his nouns should be
required; or that the genders should be assigned to all his nouns, or
that the pronouns possesive should agree in the gender with the
possession instead of the possessor; to make her more natural to
speakers native French.
Language design involves a careful balancing of several factors. I
think that both Matz and Guido did admirable jobs in designing and
evolving Ruby and Python respectively, each with a different set of
principles.
Even Shakespeare stuck to the English rules when he wrote in English,
and the French rules when he wrote in French. unless he was trying for
comic effect as when Katharine's lady-in-waiting, Alice was teaching
her English in Henry V.
Personally, I'd prefer to let Ruby be Ruby, and Python be Python, or
as the French say: Vive la difference!
···
On 5/22/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Agreed. Indentation vs. other ways of delimiting code blocks is just
a surface issue. For the most part, it is just a preference thing.
The lack of a real lambda (and its verbose syntax compared to ruby
blocks) in python is a much bigger issue. I still think python's
crippling of the lambda has to do with the indentation thing. The way
they did it, indented code blocks ("suites") are only part of
statements (not more generic expressions). Since a lambda is an
expression (probably used in an enclosing statment), it doesn't get to
have generic code blocks. With some rework, blocks delimited by
indentation don't have to be so limited.
···
On 5/22/07, Brad Phelan <bradphelan@xtargets.com> wrote:
I am not concerned really either way with the indentation thingie. I
don't think that is the main difference between python and Ruby. In my
op' the fact that Python does not do generic blocks is the main arguing
point. I am not sure why the indentation issue raises so much heat.What interests me about this thread is that, if you wish,
you can transparently add your own dialect to ruby by overloading
require. I've done the same thing before to load ERB files as if
they were real ruby files on the path. I jumped in at the challenge
of the OP as to whether transparent preprocessing is possible. The fact
that it is and so simply is a nice sign of the power of the ruby language.
What interests me about this thread is that, if you wish,
you can transparently add your own dialect to ruby by overloading
require. I've done the same thing before to load ERB files as if
they were real ruby files on the path. I jumped in at the challenge
of the OP as to whether transparent preprocessing is possible. The fact
that it is and so simply is a nice sign of the power of the ruby language.
As the OP in this thread, but not the one it spawned from, I just
wanted to turn the question from whether or not Ruby should be Python
to **how** to make Ruby Python if one so chose. I wouldn't really do
it myself, but the question of how is a pretty interesting question
(and also one which has less risk of generating flame wars).
A few months back, during the Fizzbuzz craze, I saw a Fizzbuzz solver
which worked by defining a algorithm in Haskell which ran in a Haskell
interpreter which ran inside a Lisp interpreter which ran inside
another Lisp interpreter which was written in Ruby. Sometimes the
question of how to do something is interesting for its own sake,
whether the thing is worth doing or not.
···
--
Giles Bowkett
I'm running a time management experiment: I'm only checking e-mail
twice per day, at 11am and 5pm. If you need to get in touch quicker
than that, call me on my cell.
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
For the sake of readability, I'd probably lean more toward:
table do
@components.each do |row|
tr do
row.each {|col| td { pre { text col } } }
end
end
end
. . . or something like that. Up to three layers of any one type of
delimiter and up to sixty characters or so width seem to be fine for
parsing by eye, and splitting brace-delimited lines over several lines
in Ruby just looks wrong somehow. Maybe that's just me, though.
···
On Wed, May 23, 2007 at 12:27:21AM +0900, Rick DeNatale wrote:
And with the judicious use of {} vs. do end there are other
alternatives which may suit individual tastes depending on how tightly
you like to see the code:table do
@components.each do |row|
tr do
row.each do |col|
td {pre {text col}
end
end
end
endor the ultra tight:
table {@components.each {|row| tr {row.each {|col| td {pre {text col}}}}}
or if you aren't religious about reserving brackets for one-line
blocks (I'm not):table {
@components.each { |row|
tr {
row.each { |col|
td {pre {text col}
}
}
}
}Or anywhere in-between.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
MacUser, Nov. 1990: "There comes a time in the history of any project when
it becomes necessary to shoot the engineers and begin production."
Rick DeNatale wrote:
...
2. Both curly braces and begin / end pairs to define scope, with one
variant having a higher binding priority than the other. The fact that I
don't even remember which one it is that has the higher binding priority
is an added factor in my dislike.I think there's some misunderstanding here.
Curly braces are used to denote a proc, begin/end delimits a sequence
of expressions which are executed in sequence and whose value is the
last expression executed.
Ed probably meant do...end, not begin...end.
{} and do/end aren't operators, but in almost all cases delimit procs
and so the question of their relative priority is moot as far as I can
tell since you can't have two procs next to each other in ruby source.
This is the precedence issue:
def foo(*)
puts "FOO" if block_given?
end
def bar(*)
puts "BAR" if block_given?
end
foo bar do end
foo bar { }
__END__
Output:
FOO
BAR
···
On 5/22/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Eric Mahurin wrote:
I am not concerned really either way with the indentation thingie. I
don't think that is the main difference between python and Ruby. In my
op' the fact that Python does not do generic blocks is the main arguing
point. I am not sure why the indentation issue raises so much heat.What interests me about this thread is that, if you wish,
you can transparently add your own dialect to ruby by overloading
require. I've done the same thing before to load ERB files as if
they were real ruby files on the path. I jumped in at the challenge
of the OP as to whether transparent preprocessing is possible. The fact
that it is and so simply is a nice sign of the power of the ruby language.Agreed. Indentation vs. other ways of delimiting code blocks is just
a surface issue. For the most part, it is just a preference thing.The lack of a real lambda (and its verbose syntax compared to ruby
blocks) in python is a much bigger issue. I still think python's
crippling of the lambda has to do with the indentation thing. The way
they did it, indented code blocks ("suites") are only part of
statements (not more generic expressions). Since a lambda is an
expression (probably used in an enclosing statment), it doesn't get to
have generic code blocks. With some rework, blocks delimited by
indentation don't have to be so limited.
Recently python allowed it's yield statement to be an expression
and return a value.
a = ( yield b )
However I cannot see a useful way to use that from within python
as there is no intuiative way for the code block to return a value.
The only way to take advantage of it is the nonintuitve
coroutine syntax ala generator.send ( ... )
http://docs.python.org/whatsnew/pep-342.html
I don't see a fundamental reason that Python could not be extended
to have generic blocks ala Ruby but from reading some of the PEP's
it seems to be a deliberate design decision to avoid generic blocks.
The rationale as I have understood it is that generic blocks hide
looping constructs which should be explicit ( foreach ).
PEP 343 – The “with” Statement | peps.python.org
"""
PEP 340, Anonymous Block Statements, combined many powerful ideas:
using generators as block templates, adding exception handling and
finalization to generators, and more. Besides praise it received
a lot of opposition from people who didn't like the fact that it
was, under the covers, a (potential) looping construct. This
meant that break and continue in a block-statement would break or
continue the block-statement, even if it was used as a non-looping
resource management tool.
"""
Read the full PEP 343 to see the lengths that are gone to to implement
this. However I am curious to see some more knowledgeable Ruby people
explain how Ruby deals with the concerns raised by the Python guys. Some
of the issues are the usage of break and continue within blocks. Does
continue/break used from within a block continue/break the block or the most local for loop. I haven't tried myself to see what happens.
>I am not concerned really either way with the indentation thingie. I
>don't think that is the main difference between python and Ruby. In my
>op' the fact that Python does not do generic blocks is the main arguing
>point. I am not sure why the indentation issue raises so much heat.Agreed. Indentation vs. other ways of delimiting code blocks is just
a surface issue. For the most part, it is just a preference thing.
That's why it draws so much heat: it's a preference thing. People foo
don't like finding a language that suits their preferences, getting into
it and really getting familiar with it, then having someone bar come
from another language's norms to start suggesting it should be changed
to suit their (foo's) preferences less well. Meanwhile, other people
bar who find a language that suits their preferences really well start
wanting to go around to all other languages they use and start
recommending those languages be modified to suit their preferences,
regardless of the fact that these other languages probably suit the
preferences of other people foo who already use them. It relates to the
fact that everyone wants to believe his or her preferences are "right"
and others' are "wrong".
The term "religious war" or "holy war" in relation to programming
languages, vi/emacs/VisualStudio, et cetera, is disturbingly appropriate
because of the root psychological causes in common between these
arguments over preferences and those over religious observance
preferences, I think.
The lack of a real lambda (and its verbose syntax compared to ruby
blocks) in python is a much bigger issue. I still think python's
crippling of the lambda has to do with the indentation thing. The way
they did it, indented code blocks ("suites") are only part of
statements (not more generic expressions). Since a lambda is an
expression (probably used in an enclosing statment), it doesn't get to
have generic code blocks. With some rework, blocks delimited by
indentation don't have to be so limited.
I remember reading that Guido just flat-out stated once that lambdas
would never be allowed to have more than one line, as though he simply
felt that multi-line lambdas were "bad" somehow. I don't know if the
reasoning you suggest might have been behind it, but the way I read it,
it seemed like Guido is interested in mandating certain restrictions to
enforce his ideas of good programming practice. The assumption there
would be that he believes multi-line lambdas interfere with some aspect
of good programming practice -- probably something to do with human
readability. He might also simply want to discourage people from using
lambdas where objects "should" be used instead. I could just be
misinterpreting the motivation, of course.
···
On Wed, May 23, 2007 at 04:28:45AM +0900, Eric Mahurin wrote:
On 5/22/07, Brad Phelan <bradphelan@xtargets.com> wrote:
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Thomas McCauley: "The measure of a man's real character is what he would do
if he knew he would never be found out."
Fair enough, I'll file that in the "you learn something new every day"
file. Actually the more I learn the better the day.
I haven't run into this since my preference is to parenthesize
arguments unless it's part of a DSL. So I would have coded:
foo(bar) {}
foo(bar) do..end
or
foo(bar {})
foo(bar do..end)
Thanks!
···
On 5/22/07, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
This is the precedence issue:
def foo(*)
puts "FOO" if block_given?
enddef bar(*)
puts "BAR" if block_given?
endfoo bar do end
foo bar { }__END__
Output:
FOO
BAR
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/