Forum: Ruby How to adopt "Python Style" indentation for Ruby

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2007-05-21 08:54
(Received via mailing list)
Obviously based on the earlier thread. I think this is actually an
utterly terrible idea. Haven't you heard that song by Loverboy? "Pig
and elephant DNA just don't mix"? But I think the **implementation**
would be fascinating.

What would it take to write a Ruby pre-processor which parsed Ruby
written in a Pythonic style and turned it into actual valid Ruby? Or
even a Ruby library like Xavier's Perl example, which allows you to
code Ruby as if it were Python after just requiring the library? The
original post's main argument was that indentation is a stable,
consistent shorthand for Ruby's end statements. If all you're looking
to do is use tabs as syntactic sugar, then it should be pretty easy to
just write something which knows how to translate a sequence of tabs
in and tabs out into a series of end statements at the end.

Is this only doable in Perl, because Perl has source filtering? Would
you have to encase the Pythonic "Ruby" in a string and then run that
string through a processor after the fact, or could it "just work"
without any obvious prep on the user's part? If you did it as a
string, it should be as easy as counting tabs. But source filtering,
that sounds like the better way.

--
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
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (Guest)
on 2007-05-21 09:33
(Received via mailing list)
On Mon, May 21, 2007 at 03:53:25PM +0900, Giles Bowkett wrote:
> What would it take to write a Ruby pre-processor which parsed Ruby
> written in a Pythonic style and turned it into actual valid Ruby? Or
> even a Ruby library like Xavier's Perl example, which allows you to
> code Ruby as if it were Python after just requiring the library? The
> original post's main argument was that indentation is a stable,
> consistent shorthand for Ruby's end statements. If all you're looking
> to do is use tabs as syntactic sugar, then it should be pretty easy to
> just write something which knows how to translate a sequence of tabs
> in and tabs out into a series of end statements at the end.

Actually, I'd happily settle for something simpler: a pretty-printer
which
just reads (normal) Ruby and re-outputs it with standard indentation.

This would immediately solve the problem of "where did I miss out an
'end'
statement?" - you'd just pipe it into this utility and inspect. In the
past
I've had to resort to binary chops to solve this: copy source.rb to x.rb
and
remove chunks of method definitions until I find the offending one. This
is
painful.

As an alternative: the existing Ruby parser could be modified to spit
out a
warning whenever it sees non-standard nesting, e.g. "end at line <x>
doesn't
align with start of block/method at line <y>". It only need do this for
an
'end' which is at the start of a line.

Regards,

Brian.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2007-05-21 13:46
(Received via mailing list)
On 5/21/07, Brian Candler <B.Candler@pobox.com> wrote:
> On Mon, May 21, 2007 at 03:53:25PM +0900, Giles Bowkett wrote:
> > What would it take to write a Ruby pre-processor which parsed Ruby
> > written in a Pythonic style and turned it into actual valid Ruby?

> Actually, I'd happily settle for something simpler: a pretty-printer which
> just reads (normal) Ruby and re-outputs it with standard indentation.
>
> This would immediately solve the problem of "where did I miss out an 'end'
> statement?" -

In vim, I find that ggVG= does that job well enough.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/
Feee221f9eb7818d90625ea141bfd60c?d=identicon&s=25 bbiker (Guest)
on 2007-05-21 17:41
(Received via mailing list)
On May 21, 3:32 am, Brian Candler <B.Cand...@pobox.com> wrote:
>
> warning whenever it sees non-standard nesting, e.g. "end at line <x> doesn't
> align with start of block/method at line <y>". It only need do this for an
> 'end' which is at the start of a line.
>
> Regards,
>
> Brian.

I use Arachono Ruby IDE. Its editor has a feature whereby I can select
a number of lines to comment out or uncomment the lines. This makes
finding the missing end fairly easier.

I find python indentation much harder to read. For my use, I rather
stick with the "end"s.
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2007-05-21 18:37
(Received via mailing list)
> Actually, I'd happily settle for something simpler: a pretty-printer which
> just reads (normal) Ruby and re-outputs it with standard indentation.

This already exists, and was written by somebody on this list, but I'm
having a hard time googling it.

--
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
53f7def58ca1dfdc13369dfd5e2aaace?d=identicon&s=25 Brad Phelan (Guest)
on 2007-05-29 19:56
(Received via mailing list)
Giles Bowkett wrote:
> consistent shorthand for Ruby's end statements. If all you're looking
>
Another version of pyrb.rb has been written that allows proper
multilevel dedenting and removes the requirement for a separate
.pyrb file

You can now do in test.rb


#####################################
require 'pyrb.rb'
__END__

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"


foo
#####################################

http://xtargets.com/snippets/posts/show/68

Disclaimer : The above library in no way whatsoever should be taken as a
suggestion that the author thinks Python is better than Ruby or
vice versa. All suggestions to that effect are purely fictional and
the author is in no way responsible for flame wars that may ensue
from use or misuse of the library. The author wrote the library
because it could be done and for no other reason.
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2007-05-29 21:36
(Received via mailing list)
> > Obviously based on the earlier thread. I think this is actually an
> > utterly terrible idea. Haven't you heard that song by Loverboy? "Pig
> > and elephant DNA just don't mix"? But I think the **implementation**
> > would be fascinating.
> >
> > What would it take to write a Ruby pre-processor which parsed Ruby
> > written in a Pythonic style and turned it into actual valid Ruby? Or

> Another version of pyrb.rb has been written that allows proper
> multilevel dedenting and removes the requirement for a separate
> .pyrb file

This is absurdly cool. How does it work?

Oh I get it:

> The trick to the new version is to use the __END__ keyword
> to block the Ruby scanner and then reload the current file after
> doing the preprocessing.

That's awesome! Sick and wrong in the best possible way. And **simple!**

--
Giles Bowkett

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
53f7def58ca1dfdc13369dfd5e2aaace?d=identicon&s=25 Brad Phelan (Guest)
on 2007-05-29 21:51
(Received via mailing list)
>
Sick, wrong and simple but unfortunately not my idea. There is a library
hanging around called hyphen-ruby which showed me the dark path.

B
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-05-30 01:38
(Received via mailing list)
On May 29, 3:50 pm, Brad Phelan <bradphe...@xtargets.com> wrote:
> Sick, wrong and simple but unfortunately not my idea. There is a library
> hanging around called hyphen-ruby which showed me the dark path.
>
> B

Actually you can do this without even using the __END__. pyrb.rb can
exit the process so it will never reach the rest of the original file.

T.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-05-30 01:42
(Received via mailing list)
On May 29, 7:37 pm, Trans <transf...@gmail.com> wrote:

> Actually you can do this without even using the __END__. pyrb.rb can
> exit the process so it will never reach the rest of the original file.

But then again, why bother? Just make a new executable called
'pyruby'. And use that to run your .pyrb scripts.

T.
53f7def58ca1dfdc13369dfd5e2aaace?d=identicon&s=25 Brad Phelan (Guest)
on 2007-05-30 07:01
(Received via mailing list)
Trans wrote:
>>
>> B
>
> Actually you can do this without even using the __END__. pyrb.rb can
> exit the process so it will never reach the rest of the original file.
>
> T.
>
>


I don't think that will work. I believe that Ruby will syntax check the
entire file before trying to execute any of it.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-05-30 20:28
(Received via mailing list)
On May 30, 1:00 am, Brad Phelan <bradphe...@xtargets.com> wrote:

> > Actually you can do this without even using the __END__. pyrb.rb can
> > exit the process so it will never reach the rest of the original file.
>
> > T.
>
> I don't think that will work. I believe that Ruby will syntax check the
> entire file before trying to execute any of it.

Ah, right. Did something like this myself once but I had overlooked
the fact that my variant code still passed for valid ruby. In any
case, using a separate 'pyruby' runner would be the best way
regardless.

T.
5f9c010866ed7b4ceff994510de2ef8c?d=identicon&s=25 Jaroslaw Zabiello (jzabiello)
on 2007-06-15 10:45
(Received via mailing list)
Dnia 29-05-2007 o 18:50:16 Brad Phelan <bradphelan@xtargets.com>
napisał(a):

> Giles Bowkett wrote:
> What would it take to write a Ruby pre-processor which parsed Ruby
> written in a Pythonic style and turned it into actual valid Ruby?

It is already written

http://lazibi.rubyforge.org/
Cf8586cf56fec72eb20a52e6797fea31?d=identicon&s=25 Brad Phelan (Guest)
on 2007-09-25 22:59
(Received via mailing list)
bbiker wrote:
>>> in and tabs out into a series of end statements at the end.
>> warning whenever it sees non-standard nesting, e.g. "end at line <x> doesn't
>
> I find python indentation much harder to read. For my use, I rather
> stick with the "end"s.
>

I've tried posting several times without success ... here again.

http://xtargets.com/snippets/posts/show/68

shows a partial solution to your challenge by overloading require. It is
a quick hack but shows you how to write your own pre-processor. The
new require checks to find files of type .pyrb and then coverts them
to .rb files before loading them.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2007-09-25 23:00
(Received via mailing list)
On 5/22/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
> >            @components.each do |row|
> >        end
> >                            pre do :
> start with:
>            end
>          end
>        end
>      end

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

My blog on Ruby
http://talklikeaduck.denhaven2.com/
53f7def58ca1dfdc13369dfd5e2aaace?d=identicon&s=25 Brad Phelan (Guest)
on 2007-09-25 23:01
(Received via mailing list)
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
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2007-09-25 23:02
(Received via mailing list)
> 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
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2007-09-25 23:03
(Received via mailing list)
On 5/22/07, Brad Phelan <bradphelan@xtargets.com> wrote:
> 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.
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2007-09-25 23:03
(Received via mailing list)
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.)

> 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).
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2007-09-25 23:03
(Received via mailing list)
Rick DeNatale wrote:
> On 5/22/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> 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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2007-09-25 23:03
(Received via mailing list)
On 5/22/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

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

My blog on Ruby
http://talklikeaduck.denhaven2.com/
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2007-09-25 23:04
(Received via mailing list)
Why do I get the impression that this thread is trying to develop a
new language called FrankenRuPy? <G>


--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2007-09-25 23:04
(Received via mailing list)
Hi --

On Tue, 22 May 2007, Brad Phelan wrote:

>                            pre do
>
>
> 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 :-) 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
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2007-09-25 23:04
(Received via mailing list)
> shows a partial solution to your challenge by overloading require. It is
> a quick hack but shows you how to write your own pre-processor. The
> new require checks to find files of type .pyrb and then coverts them
> to .rb files before loading them.

Neat! So all you do is write .pyrb files and you're good to go. And it
works basically by putting the tabs on a stack and using that to drive
the number of ends.

--
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
53f7def58ca1dfdc13369dfd5e2aaace?d=identicon&s=25 Brad Phelan (Guest)
on 2007-09-25 23:05
(Received via mailing list)
Eric Mahurin wrote:
> If you change this:
>                    stack.push indent
> Unfortunately, this isn't too easy to implement in a formal parser
>            puts i
>
> In this example, you get rid of 3 lines and 9 symbols/identifiers (and
> add the 3 ":"s) compared to the original ruby.
>
> All of these ":" solutions would have potential incompatibilities with
> the ? : operator and :symbol.
>

I think I would prefer the leaving the 'do' in and keeping the rubish
syntax. It will avoid the potential for the conflicts that you describe.

though I do like the economy of

 > def foo :
 >    [1,2,3,4].each : i
 >        puts i
 >        [1,2,3,4].each : i
 >            puts i

Perhapps another symbol other than :
Cf8586cf56fec72eb20a52e6797fea31?d=identicon&s=25 Brad Phelan (Guest)
on 2007-09-25 23:05
(Received via mailing list)
Chad Perrin wrote:
> 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!
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2007-09-25 23:06
(Received via mailing list)
On Wed, May 23, 2007 at 04:28:45AM +0900, Eric Mahurin wrote:
> 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.
>
> 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.
53f7def58ca1dfdc13369dfd5e2aaace?d=identicon&s=25 Brad Phelan (Guest)
on 2007-09-25 23:07
(Received via mailing list)
dblack@wobblini.net wrote:
>>        table do
>>            end
>>                        td do :
> rid of the extraneous end in your example :-) it looks a lot nicer to
> 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
D4a2c164dab947dff67c6d39f554526c?d=identicon&s=25 bradphelan (Guest)
on 2007-09-25 23:08
(Received via mailing list)
On May 21, 6:42 pm, "Giles Bowkett" <gil...@gmail.com> wrote:
> 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

Google groups seems to be broken. My posts do not appear. Just seeing
if this gets throught. My other post was via a different news agent.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2007-09-25 23:08
(Received via mailing list)
Hi --

On Wed, 23 May 2007, M. Edward (Ed) Borasky wrote:

> 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
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2007-09-25 23:09
(Received via mailing list)
On 5/21/07, Brad Phelan <phelan@tttech.ttt> wrote:
> I've tried posting several times without success ... here again.
>
> http://xtargets.com/snippets/posts/show/68
>
> shows a partial solution to your challenge by overloading require. It is
> a quick hack but shows you how to write your own pre-processor. The
> new require checks to find files of type .pyrb and then coverts them
> to .rb files before loading them.

If you change this:

                if l =~ /:\s*$/
                    stack.push indent
                    l.gsub! /:\s*$/,''
                end

to this:

                if l.sub!(/(\|[^\|]*\|)\s*:\s*$/,' do \1') or
l.sub!(/:\s*$/,'')
                    stack.push indent
                end

your example won't need the do's:

def foo:
    [1,2,3,4].each |i|:
        puts i
        [1,2,3,4].each |i|:
            puts i

Unfortunately, this isn't too easy to implement in a formal parser
though, since the "|" after each initially looks ambiguous with the
"|" operator.  The ":" to start the indentation style block should
probaly be where the "do" or "{" used to.  You could even get rid of
the || by using ":" to start the args and "\n" to end the args (you'd
need an exlicit * to mean don't care about the args):

def foo :
    [1,2,3,4].each : i
        puts i
        [1,2,3,4].each : i
            puts i

In this example, you get rid of 3 lines and 9 symbols/identifiers (and
add the 3 ":"s) compared to the original ruby.

All of these ":" solutions would have potential incompatibilities with
the ? : operator and :symbol.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2007-09-25 23:09
(Received via mailing list)
On Wed, May 23, 2007 at 12:27:21AM +0900, Rick DeNatale wrote:
>      end
>
> Or anywhere in-between.
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.
Cf8586cf56fec72eb20a52e6797fea31?d=identicon&s=25 Brad Phelan (Guest)
on 2007-09-25 23:10
(Received via mailing list)
Brad Phelan wrote:
>> What if it does?  It might accidentally cause the death of the mad
>
>             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.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2007-09-25 23:10
(Received via mailing list)
On 5/22/07, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:


> foo bar do end
> foo bar { }
>
> __END__
>
> Output:
>
> FOO
> BAR
>

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!

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2007-09-25 23:10
(Received via mailing list)
On 5/21/07, Brad Phelan <bradphelan@xtargets.com> wrote:
> though I do like the economy of
>
>  > def foo :
>  >    [1,2,3,4].each : i
>  >        puts i
>  >        [1,2,3,4].each : i
>  >            puts i
>
> Perhaps another symbol other than :

:: could work.  As long as it is not followed by an identifier
character it shouldn't collide.  You could use this code for starting
the block:

                if l.sub!(/::\s*$/,'') or l.sub!(/::\s+(.*)$/,' do
|\1|')
                    stack.push indent
                end

and then this should work:

def foo ::
    [1,2,3,4].each :: i
        puts i
        [1,2,3,4].each :: i
            puts i

With this code, to do the equivalent of do...end w/o args you'd need
an explicit do before the :: .  This could be fixed in a real parser
since it would know whether the block is for a builtin
def/while/if/class statement versus a standard lambda block.  In the
lambda block context maybe you'd want "::\n" to mean "do ||" and use
":: *\n" to mean "do |*|" (which is equivalent to a block without
args).  Otherwise you couldn't get the equivalent of "do ||".
53f7def58ca1dfdc13369dfd5e2aaace?d=identicon&s=25 Brad Phelan (Guest)
on 2007-09-25 23:10
(Received via mailing list)
Eric Mahurin wrote:
>> of the OP as to whether transparent preprocessing is possible. The fact
> 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 ).

     http://www.python.org/dev/peps/pep-0343/
     """
     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.
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2007-09-25 23:10
(Received via mailing list)
dblack@wobblini.net wrote:
>             td do
> David
>
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.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2007-09-25 23:10
(Received via mailing list)
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 ?

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.
This topic is locked and can not be replied to.