Why not adopt "Python Style" indentation for Ruby?

#1

As far as I can see, the ‘end’ keyword is ‘repeating yourself’ when
used with properly indented code.

class Foo

def bar(value)
if value < 7
puts “hello”
else
puts “world”
end
end

def foobar
puts “foobar”
end

end

could be

class Foo

def bar(value)
if value < 7
puts “hello”
else
puts “world”

def foobar
puts “foobar”

with no reduction in meaning, yet 25% fewer lines of code.

What are the reasons why this isn’t used/implemented/liked? It would
be a small change to the interpreter. Enabling meaningful indentation
would only make ‘end’ optional, not invalid; backwards compatibility
wouldn’t be a problem.

(I use both Ruby and Python. I think indentation is one of the few
language features where Python leads Ruby.)

If this post generates a positive response, I’ll make a patch for Ruby
1.9.

#2

Hi,

In message “Re: Why not adopt “Python Style” indentation for Ruby?”
on Fri, 18 May 2007 16:25:03 +0900, Chris D.
removed_email_address@domain.invalid writes:

|What are the reasons why this isn’t used/implemented/liked?

Python style block by indentation is an interesting idea, but it works
badly with

  • tab/space mixture
  • templates, e.g. eRuby
  • expression with code chunk, e.g lambdas and blocks

So I’d rather be conservative here.

          matz.
#3

On 18/05/07, Yukihiro M. removed_email_address@domain.invalid wrote:

  • tab/space mixture
  • templates, e.g. eRuby
  • expression with code chunk, e.g lambdas and blocks
  • clipboards, email, pastebins, and other places where the code is not
    preserved literally

Thanks

Michal

#4

Actually,

Isn’t end repeating yourself full stop?

Do we really need it?

Julian.

On Fri, 18 May 2007 16:25:03 +0900

#5
  • tab/space mixture
  • templates, e.g. eRuby
  • expression with code chunk, e.g lambdas and blocks
  • clipboards, email, pastebins, and other places where the code is not
    preserved literally
  • code generators

tabs can be made forbidden (g.v.rossum himself said he’d never
supported tabs in the first place if he new what it would cauze)

maybe it can be made optional. or one could write a little conversion
script.

i agree python’s indentation looks clean. yet i have experienced
allmost all of the above mentioned “cons”…

_c.

#6

On May 18, 2007, at 11:04 AM, Michal S. wrote:

works
badly with

  • tab/space mixture
  • templates, e.g. eRuby
  • expression with code chunk, e.g lambdas and blocks
  • clipboards, email, pastebins, and other places where the code is not
    preserved literally

code generators

#7

On May 18, 2007, at 12:50 PM, cies wrote:

maybe it can be made optional. or one could write a little
conversion script.

Or add source filters:

http://search.cpan.org/~fxn/Acme-Pythonic-0.45/lib/Acme/Pythonic.pm

MWUUAHAHAHA.

– fxn

#8

On Fri, May 18, 2007 at 06:09:23PM +0900, Xavier N. wrote:

preserved literally

code generators

Disabling sections of code, i.e.

if false

… code with original indentation

end

Also, multi-level namespaces where you don’t want to indent the entire
source file that much, e.g.

module Foo
module Bar
class Baz
def wibble

end
end # Baz
end # Bar
end # Foo

(Admittedly, I believe it’s now possible to write

module Foo; module Bar; end; end
class Foo::Bar::Baz

end)

#9

Hi,

In message “Re: Why not adopt “Python Style” indentation for Ruby?”
on Fri, 18 May 2007 22:01:13 +0900, Daniel M.
removed_email_address@domain.invalid writes:

|Note that the Haskell folks have managed to evolve a language in which
|python-like spacing can be used to mark the extent of discrete code
|chunks, but so can traditional braces.

I admit Haskell syntax is much better than Python’s. But I am not yet
sure if it can be applied to Ruby.

          matz.
#10

Chris D. removed_email_address@domain.invalid writes:

As far as I can see, the ‘end’ keyword is ‘repeating yourself’ when
used with properly indented code.

Note that the Haskell folks have managed to evolve a language in which
python-like spacing can be used to mark the extent of discrete code
chunks, but so can traditional braces.

This is more then kind of thing I’d like to see in Ruby: having it
allow the compact python notation, but not require it. (So that,
e.g., code generators would still be easy to write)

I think anyone serious about adding indentation-as-syntax to Ruby
should take a very close look at how Haskell manages to allow it
without requiring it.

#11

On 5/18/07, Chris D. removed_email_address@domain.invalid wrote:

What are the reasons why this isn’t used/implemented/liked? It would
be a small change to the interpreter. Enabling meaningful indentation
would only make ‘end’ optional, not invalid; backwards compatibility
wouldn’t be a problem.

(I use both Ruby and Python. I think indentation is one of the few
language features where Python leads Ruby.)

This is a very subjective thing. A lot of people don’t use Python
because they don’t like this feature.

In my case I like the symmetry that Ruby’s matching end provides. I
find it makes the code easier to read and maintain. I’ve written and
maintained some Python code that “trails off into nowhere” with a long
series of indentations. I find this “stairway” code rather painful to
work with.

But if it is possible to add this feature to Ruby without breaking
anything, it could be interesting. It would certainly draw a few
Pythonists to check out Ruby.

Ryan

#12

“Yukihiro M.” removed_email_address@domain.invalid wrote in message
news:removed_email_address@domain.invalid…

  • tab/space mixture
  • templates, e.g. eRuby
  • expression with code chunk, e.g lambdas and blocks

So I’d rather be conservative here.

matz.

imho: indentation should not define semantic;
suggestion: make ‘end’ optional if code block contains only one
statement;

BRs
Sergey V.

#13

On 18.05.2007 15:36, Yukihiro M. wrote:

sure if it can be applied to Ruby.
Just to throw in my 0.02EUR here: I don’t think it’s worth the effort
(which I guess is huge) because Ruby’s syntax is concise already. If
I got to decide I would rather see those efforts go into JVM based Ruby
implementations and / or native threads. But that’s just my personal
preference.

Kind regards

robert

#14

Hi,

In message “Re: Why not adopt “Python Style” indentation for Ruby?”
on Fri, 18 May 2007 23:15:05 +0900, “S.Volkov” removed_email_address@domain.invalid
writes:

|imho: indentation should not define semantic;

Agreed.

|suggestion: make ‘end’ optional if code block contains only one statement;

I’m not sure if we can define syntax for above suggestion.

while cond
puts a
puts b # delimit by indentation or else??

or maybe

while cond: puts a # should be in same line

          matz.
#15

On 5/18/07, Yukihiro M. removed_email_address@domain.invalid wrote:

sure if it can be applied to Ruby.

                                                    matz.

I’ve picked up on python in the last couple months and like the
indentation. In addition to forced readablity, I find another
practical benefit is that it eliminates hard to track down syntax
errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
these errors can be painful to track down in a large file with lots of
blocks within blocks.

Syntactically it isn’t too difficult once you have the lexer generate
indent and unindent tokens. Then the parser just looks for matching
indent and unindent tokens instead of {} or begin/end, etc.

You might consider something like this as an alternative block syntax.
Maybe a “:” followed by a newline (and extra indentation) would start
this style. I’m not sure of a clean way to handle arguments though.

p.s. in the late eighties I made a little shell language (for the
Atari ST) that used indentation just like python.

#16

Dnia Fri, 18 May 2007 22:36:58 +0900, Yukihiro M. napisa³(a):

I admit Haskell syntax is much better than Python’s.

Matz, you must be joking… Python is much easier to read than Haskell.

#17

Dnia Fri, 18 May 2007 16:38:05 +0900, Yukihiro M. napisa³(a):

Python style block by indentation is an interesting idea, but it works
badly with

  • tab/space mixture

Tabs are against PEP8 which recomends space usage only.

  • templates, e.g. eRuby

eRuby is crap if you compare it with Haml template
http://haml.hamptoncatlin.com/.

It is interesting how they use indendation and how clean it can be. And
finally… they are written in Ruby and for Ruby users! :slight_smile:

What do you think about OPTIONAL block indendation in Ruby?

#18

On 5/18/07, Eric M. removed_email_address@domain.invalid wrote:

I’ve picked up on python in the last couple months and like the
indentation. In addition to forced readablity, I find another
practical benefit is that it eliminates hard to track down syntax
errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
these errors can be painful to track down in a large file with lots of
blocks within blocks.

You could always run it through a tool to clean up code and provide
proper indentation. I personally don’t like it when a language
dictates how my code ought to look, since I’m pretty picky myself :s

Syntactically it isn’t too difficult once you have the lexer generate
indent and unindent tokens. Then the parser just looks for matching
indent and unindent tokens instead of {} or begin/end, etc.

When working in a team, regardless of how the code has been formatted,
I’ve always been able to slap pieces of code together and not worry
about indentation (when such language doesn’t worry about
indentation). Working in python always adds a little extra stress
when mixing and matching code, and the problem gets bigger when
indentation isn’t standardized across teams or when applying code from
the web.

filipe

#19

On 5/18/07, Jaroslaw Z. removed_email_address@domain.invalid wrote:

  • templates, e.g. eRuby

eRuby is crap if you compare it with Haml template
http://haml.hamptoncatlin.com/.

Except eRuby is a general templating system, and Haml is for XHTML
generation.

#20

In message removed_email_address@domain.invalid, Yukihiro
Matsumoto writes:

|suggestion: make ‘end’ optional if code block contains only one statement;

I’m not sure if we can define syntax for above suggestion.

I am pretty sure we can’t, unless we acquire a machine sufficiently
quantum to let us simply generate multiple outputs for each input
program. That would, I think, resolve the question. Sort of.

-s