Ruby Forum Ruby > Why not adopt "Python Style" indentation for Ruby?

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.

Hi,

In message "Re: Why not adopt "Python Style" indentation for Ruby?"
    on Fri, 18 May 2007 16:25:03 +0900, Chris Dew 
<cmsdew@googlemail.com> 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.

On 18/05/07, Yukihiro Matsumoto <matz@ruby-lang.org> 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

Actually,

Isn't end repeating yourself full stop?

Do we really need it?

Julian.

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

On May 18, 2007, at 11:04 AM, Michal Suchanek 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

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

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

On Fri, May 18, 2007 at 06:09:23PM +0900, Xavier Noria 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)

Chris Dew <cmsdew@googlemail.com> 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.

Hi,

In message "Re: Why not adopt "Python Style" indentation for Ruby?"
    on Fri, 18 May 2007 22:01:13 +0900, Daniel Martin 
<martin@snowplow.org> 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.

On 18.05.2007 15:36, Yukihiro Matsumoto 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

On 5/18/07, Chris Dew <cmsdew@googlemail.com> 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

"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in message
news:1179473895.694681.23173.nullmailer@x31.netlab.jp...
>
>  * 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 Volkov

Hi,

In message "Re: Why not adopt "Python Style" indentation for Ruby?"
    on Fri, 18 May 2007 23:15:05 +0900, "S.Volkov" <svolkov@comcast.net> 
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.

Dnia Fri, 18 May 2007 16:38:05 +0900, Yukihiro Matsumoto 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! :)

What do you think about OPTIONAL block indendation in Ruby?

On 5/18/07, Yukihiro Matsumoto <matz@ruby-lang.org> 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.

Dnia Fri, 18 May 2007 22:36:58 +0900, Yukihiro Matsumoto 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.

On 5/18/07, Jaroslaw Zabiello <hipertracker@gmail.com> 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.

On 5/18/07, Eric Mahurin <eric.mahurin@gmail.com> wrote:
<snip>
> 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

On 5/18/07, Jaroslaw Zabiello <hipertracker@gmail.com> wrote:
>
>
He didn't say anything about readability. In terms of syntax structure 
and
consistency, Haskell *is* better than Python. Every language is easy to 
read
if you're used to reading it.

Jason

In message <1179498273.407463.1345.nullmailer@x31.netlab.jp>, 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

Dnia Sat, 19 May 2007 00:26:15 +0900, Gregory Brown napisa³(a):

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

It is not true. Haml can generate non valid XML content as well. But it 
is
true that Haml main target is XHTML and CSS generation. For CSS 
generation
is Sass which uses very similiar approach
http://haml.hamptoncatlin.com/docs/sass

Is it not strange that such solution was invented
by Ruby, not Python, guys? :)

On 5/18/07, Jaroslaw Zabiello <hipertracker@gmail.com> wrote:
> >   * templates, e.g. eRuby
> eRuby is crap if you compare it with Haml template
> http://haml.hamptoncatlin.com/.

How well does Haml work with non-HTML templating?

-austin

Hi,

In message "Re: Why not adopt "Python Style" indentation for Ruby?"
    on Sat, 19 May 2007 00:20:06 +0900, Jaroslaw Zabiello 
<hipertracker@gmail.com> writes:

|> I admit Haskell syntax is much better than Python's.  
|
|Matz, you must be joking... Python is much easier to read than Haskell.

To rephrase, "Haskell INDENTATION SYNTAX is much better than
Python's".   Clear?

              matz.

On 5/18/07, Eric Mahurin <eric.mahurin@gmail.com> wrote:
> On 5/18/07, Yukihiro Matsumoto <matz@ruby-lang.org> 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.

Scope indicated by whitespace is an indication, IMO, that the compiler
thinks that it knows better than you do.

Always a mistake.

I want a programming language that works how I do; I don't want to
have to work how a stupid programming language requires it.

(I sometimes put debug statements flush left so that it's a simple
/^p<CR> to search for them. Can't do that with scope controlled by
whitespace. Dumb, dumb, dumb, dumb.)

-austin

On 5/18/07, Jaroslaw Zabiello <hipertracker@gmail.com> wrote:
> Dnia Sat, 19 May 2007 00:26:15 +0900, Gregory Brown napisa³(a):
> > Except eRuby is a general templating system, and Haml is for XHTML generation.
> It is not true. Haml can generate non valid XML content as well. But it is
> true that Haml main target is XHTML and CSS generation. For CSS generation
> is Sass which uses very similiar approach
> http://haml.hamptoncatlin.com/docs/sass

Neither is useful for those of us who want general purpose templating.

There are bigger problems in the world than your little web-apps.

-austin, generates C++ with erb

Hi,

In message "Re: Why not adopt "Python Style" indentation for Ruby?"
    on Sat, 19 May 2007 00:15:05 +0900, Jaroslaw Zabiello 
<hipertracker@gmail.com> writes:

|What do you think about OPTIONAL block indendation in Ruby?

I am not positive for general block-by-indentation idea.  If one
REALLY loves the idea, Python always waits for you.

But I sometime want "end"-less single line structure (in normal
order), e.g.

  if foo then bar  # pseudo syntax; you may require delimiters

not

  bar if foo

especially when I write very small code chunk.  Not knowing what
syntax it should be.

              matz.

In message 
<9e7db9110705180919t527d5e10o5e6a8e96f2245b88@mail.gmail.com>, "Austin 
Ziegler" writ
es:
>(I sometimes put debug statements flush left so that it's a simple
>/^p<CR> to search for them. Can't do that with scope controlled by
>whitespace. Dumb, dumb, dumb, dumb.)

Suspiciously familiar!

-s

On 5/18/07, Austin Ziegler <halostatue@gmail.com> wrote:
> thinks that it knows better than you do.
>
> Always a mistake.
>
> I want a programming language that works how I do; I don't want to
> have to work how a stupid programming language requires it.
>
> (I sometimes put debug statements flush left so that it's a simple
> /^p<CR> to search for them. Can't do that with scope controlled by
> whitespace. Dumb, dumb, dumb, dumb.)

That is the exact same case I find the indentation thing gets in the
way.  I had to change my way of putting in print debug statements
(same as yours).  Every language makes you change your ways a bit.  Of
course python's debug facilities (pdb) are much better than ruby's so
I don't do print debugging as much.

I would rather have multiple ways to specify blocks:
* {}'s
* indentation
* in-line (single statement/expression)

BTW, python's lambda sucks!  You can't put generic code in there - it
must be a single expression.  I think it has to do with the
indentation thing.  Only statements can have code blocks (using
indentation) and a lambda is an expression.  I don't like the clear
separation of statements and expressions that python has.  I think it
all comes back to the indentation thing.  They didn't do it right.
Sounds like Haskell did (but I have no experience with it).

On May 18, 12:19 pm, "Eric Mahurin" <eric.mahu...@gmail.com> wrote:
>
> blocks within blocks.
No, it is just the other way around.  Languages that use curly braces
for indentation like C, Perl, etc. are EASY to work with once code is
not properly factored and it extends outside a single page.  Ruby is
easy only when you use {, not so much when you use do/end,
unfortunately, as most editors know nothing about it.  Some good
editors (emacs, for example), can tell you the context you are in the
modeline with curly braces, but not so with other block indentation
types.  And most editors can easily find matching braces.  No editor I
am aware knows how to match indentation yet or do/end contexts (not
that it could not be coded, thou).

Python is a true nightmare to debug and understand once you have code
that trails off a single page.  A good example of these problems, for
example, is the Maya Python API which is as ugly as it can be, using
all of the ugliest things of python (tabulation using tabs, lots of
underscore methods, lots of code that is not easily refactored, etc).

Another problem with indentation only that has not been mentioned is
that simple cut and paste of source code between two files is not
guaranteed to work (and often will lead to a syntax error or worse, a
runtime error).  This to me is still a big no-no for indentation only,
as most programmers *do* often cut and paste code from different
contexts or files.  With languages that use braces or Ruby's do/end
you really don't have to worry about that, for the most part.

On 2007-05-18, gga <GGarramuno@aol.com> wrote:

> No editor I am aware knows how to match indentation yet or do/end
> contexts (not that it could not be coded, thou).

Emacs + ruby-mode.el understands do/end just fine.

Regards,

Jeremy Henty

Chris Dew wrote:
> 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"

The is one big disadvantage in Python's syntax. Things like...

def bar(value); (value<7) ? (puts "hello") : (puts "world"); end

...are not possible in Python - and they are useful for the typical 
one-to-three-liners in support areas, where Ruby still has the chance to 
replace Perl - a chance that Python never had.

I know that my example has nothing to do with documentation oriented 
software development, but this is not necessary for a broad range of 
small ad-hoc tools.

Wolfgang Nádasi-Donner

"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in message
news:1179498273.407463.1345.nullmailer@x31.netlab.jp...
> Hi,
>
> In message "Re: Why not adopt "Python Style" indentation for Ruby?"
>    on Fri, 18 May 2007 23:15:05 +0900, "S.Volkov" <svolkov@comcast.net> 
> writes:
>
..
>
> |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??
You are right, not feasible - rejected :)

> or maybe
>
>  while cond: puts a  # should be in same line
Thus we introduce new semantic for newline!
Following construct becomes invalid (and confusing):
    while cond: puts a
        puts b
    end
=>my personal opinion - NO

imho: we need special terminator anyway, now it is 'end', could be 
another;
suggestion: introduce ';;' terminator for 'implicit blocks (not started 
with
class/module/def/do/begin), ie:
#--
    while cond : puts a ; puts b ;;
    # but
    while cond do puts a ; puts b end
#-- until - same as while
#--
    if cond : p a ;;
#--
    if cond : p a else p b ;;
#-- unless - same as if
#--
    for var in expr : p var ;;
    # but
    for var in expr do p var end
#-- case - sorry my lunch time ended, has to return back to my office..

BRs
Sergey Volkov

> *language* features where Python leads Ruby.)
Here my 5 cents...

Gentlemen, if you want to code Python style, go ahead, program in
Python.

I mean every language has it's pros an cons. I come from a Java world
(11 years of Java) and I am not asking that Ruby should be Java like.
That is absolute nonsense.

Ruby is like Ruby, so, if you like it (as I do) take it, if you
don't...  there are lots of different programming languages out there
you can choose from, or like Mats, go ahead and develop your own (you
will notice it's actually not that easy to do it right...)

Cheers,

Enrique Comba Riepenhausen

Hi,

In message "Re: Why not adopt "Python Style" indentation for Ruby?"
    on Sat, 19 May 2007 03:15:17 +0900, "S.Volkov" <svolkov@comcast.net> 
writes:

|imho: we need special terminator anyway, now it is 'end', could be another;
|suggestion: introduce ';;' terminator for 'implicit blocks (not started with 
|class/module/def/do/begin), ie:

For your information, 1.9 once had exact same syntax you've proposed
for a short while.  I have a time machine.  The idea was abandoned
since it caused serious unreadability.

              matz.

On 5/18/07, gga <GGarramuno@aol.com> wrote:
> No, it is just the other way around.  Languages that use curly braces
> for indentation like C, Perl, etc. are EASY to work with once code is
> not properly factored and it extends outside a single page.  Ruby is
> easy only when you use {, not so much when you use do/end,
> unfortunately, as most editors know nothing about it.  Some good
> editors (emacs, for example), can tell you the context you are in the
> modeline with curly braces, but not so with other block indentation
> types.  And most editors can easily find matching braces.  No editor I
> am aware knows how to match indentation yet or do/end contexts (not
> that it could not be coded, thou).

Vim does this just fine.

-austin

On 5/18/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> with
> |class/module/def/do/begin), ie:
>
> For your information, 1.9 once had exact same syntax you've proposed
> for a short while.  I have a time machine.  The idea was abandoned
> since it caused serious unreadability.
>
>                                                         matz.


Very glad to hear it. We don't want Ruby turning into Ocaml, rife with
unreadable symbols and impossible to follow constructions.

Ruby's do/end is just fine. So we can't do two-liner if statements. I've
never, ever liked that syntax as it makes code at first glance 
confusing.
e.g.:

int i = 0, j = 0, x = 0;
for(i = 0; i < 10 ; i++)
for(j = 0; j < 30; j++);
for(x = 0; x < 100; x++)
printf(i + j + x);

I'm a big fan of the more verbose keywords of Ruby because for one there 
are
very few of them and two it makes the language easy to read.

Jason

Eric Mahurin schrieb:

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


What about another syntax:
Putting a special character at the beginning of every line that is
governed by significant whitespace.
Thes would cause no problems with normal Ruby syntax,
but would provide a way to use significant indentation if one really
wants to.

If "~" were that special character, it would look like that:
~ 5.times do |n|
~   n.times do
~     print n
~   puts

Of course, hardly any editor would be prepared to support this,
currently...

This approach would have the additional advantage
of being more robust to contexts where leading whitespace
gets stripped.


Cheers
Sven

Yukihiro Matsumoto schrieb:

>syntax it should be.
>
+1

Sven

On May 18, 5:22 pm, Sven Suska <sven71...@suska.org> wrote:
> but would provide a way to use significant indentation if one really
> wants to.
>
> If "~" were that special character, it would look like that:
> ~ 5.times do |n|
> ~   n.times do
> ~     print n
> ~   puts

I can't count how many times I've forgotten "do". Sometimes I have
wished a colon could "induce" the block:

  5.times |n|:
    n.times:
      print n
    puts

But I don't think a line prefix is worth the trouble.

T.

On 5/18/07, Trans <transfire@gmail.com> wrote:
> > Putting a special character at the beginning of every line that is
>
> I can't count how many times I've forgotten "do". Sometimes I have
> wished a colon could "induce" the block:
That puzzles me, would you not forget the ":" then? Or do you have a
lot of Python experience. Not that I think bad of the ":" syntax, just
wondering.

Robert

"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in message
news:1179512451.328481.6736.nullmailer@x31.netlab.jp...
> |class/module/def/do/begin), ie:
>
> For your information, 1.9 once had exact same syntax you've proposed
> for a short while.  I have a time machine.  The idea was abandoned
> since it caused serious unreadability.
always? may be real cause was abuse of this syntax?

well, if suffix did not work,
can we try prefix syntax for 'end'-less constructs?
(if not has been tried before)
suggestion:
    :& - prefixes 'single statement body' code block in
          class/module/def/unless/then/else/while/until
#- samples
    if cond :& puts a
    if cond : puts a else :& puts b
    while cond :& puts a
    for var in expr :& puts var
    # also valid:

    if cond :& (puts a; puts b)
    while cond :& begin puts a end
#- single statements 'chain'
    unless cond_a
        :& for ea in expr
            :& for eb in ezpr
                :& if cond(ea, eb)
                    :& do_smthng
#- simple functor with local state
    class<<fib=Object.new
        :& def get(m)
            :& (@fh||=Hash.new{|h,n|h[n]=n<2?n:h[n-1]+h[n-2]})[m]
    fib.get 10
    #-> 55

BRs
Sergey

On May 19, 2:38 am, "Robert Dober" <robert.do...@gmail.com> wrote:
>
> > > ~     print n
> > > ~   puts
>
> > I can't count how many times I've forgotten "do". Sometimes I have
> > wished a colon could "induce" the block:
>
> That puzzles me, would you not forget the ":" then? Or do you have a
> lot of Python experience. Not that I think bad of the ":" syntax, just
> wondering.

Hehe. Probably so. I'm not a hisser ;) But I think I would forget the
colon much less often, especially given it created indention
significance.

T.

On May 18, 2:41 pm, Jeremy Henty <onepo...@starurchin.org> wrote:
> On 2007-05-18, gga <GGarram...@aol.com> wrote:
>
> > No editor I am aware knows how to match indentation yet or do/end
> > contexts (not that it could not be coded, thou).
>
> Emacs + ruby-mode.el understands do/end just fine.
>
> Regards,
>
> Jeremy Henty

No, it doesn't.  When I type a close brace in emacs, I get the
corresponding line where the matching brace matches (hilited if
visible in the page, or in the modeline if not).
When I position myself next to a brace, I get the same hiliting
happening.  Can't recall if that's a feature of hilite or the electric
mode of emacs.
However, whenever I type "end" to close a block, I have NO clue where
the block begins.  And if it is code I did not write, not knowing
where the code begins is a killer.
Being emacs, I *could* potentially hack the lisp code to handle do/end
blocks properly (or indentation too).  I haven't seen anyone do it yet
(and publically give it away).

On May 18, 4:23 am, Chris Dew <cms...@googlemail.com> wrote:
> ...
> 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.)

I personally prefer that 'end' be in place, so that all ruby code is
readable. I personally believe there may be something wrong with a
syntax which sacrifices explicit readability (for everyone, not just
python programmers) for increased typing speed and the illusory gain
of 'fewer LOC'. This was one of the major reasons which convinced me
to use ruby instead of python.

On Sun, May 20, 2007 at 12:05:06AM +0900, Brendan wrote:
> > *language* features where Python leads Ruby.)
> 
> I personally prefer that 'end' be in place, so that all ruby code is
> readable. I personally believe there may be something wrong with a
> syntax which sacrifices explicit readability (for everyone, not just
> python programmers) for increased typing speed and the illusory gain
> of 'fewer LOC'. This was one of the major reasons which convinced me
> to use ruby instead of python.

I, personally, don't have an argument on principle like that for my own
preferences in this matter.  I just like the fact that an "end" makes it
look more complete to me.  Reading Python code always makes me feel like
my eyes are just going to trail off the right-hand edge of the page
because the "shape" of the code never brings me back to the leftmost
edge, the way code "should".

When I look at Python code, and ponder the way it does things so
differently from Ruby regarding delimiters and indentation (the same
thing in Python), it seems to me that Python was created for people who
write code in a particular mindset, and it's not a mindset I share when
I'm writing code.  I guess maybe some people, when writing code, think
in footnote hierarchies, while others (like me) think in nested scopes.

That's just an off-the-cuff hypothesis.

Chad Perrin wrote:
>>> (I use both Ruby and Python.  I think indentation is one of the few
> look more complete to me.  Reading Python code always makes me feel like
>
> That's just an off-the-cuff hypothesis.
>
I've been watching this debate go by for some time, and I'm not sure
this sort of thing can ever be solved, but here are my personal 
opinions:

1. When you come right down to it, there are only a few basic syntax
styles that have survived the test of time. *Most* languages, including
C, Ruby, Pascal and Perl, use some variant of the Algol 60 syntax. The
other "survivors" are the Lisp/Scheme variant of prefix notation,
Forth's postfix notation, and the regular expression syntax. I suppose
assembly language syntax has also survived, and FORTRAN and COBOL, but I
don't think anyone would design a new language with those.

2. I think Python's "variant" of Algol 60 notation is less than
satisfactory, but I also have problems with the liberality present in
the syntax of Perl and Ruby. I don't like to make the reader or parser
work any harder than necessary just for the convenience of the coder. So
I like explicit delimiters like curly braces, parentheses, mandatory
semicolons at the end of statements, begin/end pairs, etc. for the Algol
60 languages. Lisp/Scheme and Forth were deliberately designed to make
the parser's job trivial, and I like them too. :)

3. I've pretty much given up on the dream that I'll be able to program
in one language only, although some languages are close enough. At the
moment, I can get just about everything done in either Perl or R, with
the other languages simply being fun to learn and use but not essential.
I could probably eliminate Perl if there were more R programmers, but
there aren't and won't be, because R is designed for scientists and
mathematicians, not business people.

Trans schrieb:

>>~   n.times do
>>~     print n
>>~   puts
>>    
>>
>
>But I don't think a line prefix is worth the trouble.
>  
>
Trouble? -- I want the editor to insert the prefix, of course.
Some editors are already able to do this with line comments,
so they can be adapted easily.

Sven

On May 18, 12:58 pm, "Eric Mahurin" <eric.mahu...@gmail.com> wrote:
> > > these errors can be painful to track down in a large file with lots of
> > (I sometimes put debug statements flush left so that it's a simple
> > /^p<CR> to search for them. Can't do that with scope controlled by
> > whitespace. Dumb, dumb, dumb, dumb.)
>
> That is the exact same case I find the indentation thing gets in the
> way.  I had to change my way of putting in print debug statements
> (same as yours).  Every language makes you change your ways a bit.  Of
> course python's debug facilities (pdb) are much better than ruby's so

Well, I think that's going to change over the next year. If you
haven't tried Ken Sibilev's ruby-debug, 
http://rubyforge.org/projects/ruby-debug/
give it a shot. Over the last year it has improved quite a bit and I
expect over the next year it will make the same steady progress. I'm
hoping the next release will have a user manual, and possibly start
adding some regression tests (which by the way pdb doesn't currently
have).

As someone who's a little bit familiar with both debuggers, I think
the design of ruby-debug is the cleaner and more flexible. In fact, I
think it's the best organized debugger of any that I've seen so far.
(But then. as it grows..)

On 19.05.2007 20:48, M. Edward (Ed) Borasky wrote:

> 2. I think Python's "variant" of Algol 60 notation is less than 
> satisfactory, but I also have problems with the liberality present in 
> the syntax of Perl and Ruby. I don't like to make the reader or parser 
> work any harder than necessary just for the convenience of the coder.

I would understand why you would want to make the reader's job easier -
but the parser?  That's just a piece of software and I believe that we
should always strive to make software easier to use for humans not 
machines.

Besides of that, personally I don't find the current Ruby syntax hard to
read.  Do you have some examples where you feel that reading Ruby is
made hard(er) because of the liberties you mention?

Kind regards

  robert

IMHO, at least in complicated cases, the reader has to emulate a
parer, so both are the same.

Whenever there is syntax that's tricky to parse, it's also tricky to 
read.

See pythons space-vs-tab problem, for example.


Aur

Quoting Robert Klemme <shortcutter@googlemail.com>:

>
> Besides of that, personally I don't find the current Ruby syntax hard to
> read.  Do you have some examples where you feel that reading Ruby is
> made hard(er) because of the liberties you mention?
>
> Kind regards
>
>   robert

I can think of three examples right off the top of my head: Rails, Rake 
and
RSpec. There's something really eerie about seeing code like that. You 
*know*
it works, but you can't figure out why or how.

On 20/05/07, znmeb@cesmail.net <znmeb@cesmail.net> wrote:
> Quoting Robert Klemme <shortcutter@googlemail.com>:

> > Besides of that, personally I don't find the current Ruby syntax hard to
> > read.  Do you have some examples where you feel that reading Ruby is
> > made hard(er) because of the liberties you mention?

> I can think of three examples right off the top of my head: Rails, Rake and
> RSpec. There's something really eerie about seeing code like that. You *know*
> it works, but you can't figure out why or how.

And you think replacing do/end with indentation would help?

I really can't see how - could you give an example?

Trans wrote:
> On May 18, 5:22 pm, Sven Suska <sven71...@suska.org> wrote:
>> but would provide a way to use significant indentation if one really
>> wants to.
>>
>> If "~" were that special character, it would look like that:
>> ~ 5.times do |n|
>> ~   n.times do
>> ~     print n
>> ~   puts
> 
> I can't count how many times I've forgotten "do". Sometimes I have
> wished a colon could "induce" the block:
> 
>   5.times |n|:
>     n.times:
>       print n
>     puts
> 
> But I don't think a line prefix is worth the trouble.
> 
> T.

I totally agree. A line pre-fix is a bit pointless in my opinion, 
although I am in favour in moving towards a Python-style indentation 
syntax. As for the 'do' issue I don't see why it can't be removed, if 
something is always expected then you can just assume its there, right?

  5.times do |n|
    n.times do
      print n
    end
    puts
  end

(Or using the ':' instead) Could just be:

  5.times |n|
    n.times
      print n
    end
    puts
  end

On 5/20/07, Peter Marsh <evil_grunger@hotmail.com> wrote:
> >
> > T.
>     puts
>
Sorry, but how would you handle block_given? without parameters?

On 5/20/07, Dick Davies <rasputnik@gmail.com> wrote:
>
> And you think replacing do/end with indentation would help?
>
> I really can't see how - could you give an example?
>

Let's try:

describe 'myself'
  it 'should be readable'
    lambda
      @reader.reading
    .should change
      @reader.knowledge
    .by(text.amount)


# pretty much impossible, if you ask me :)
# same in usual ruby now

describe 'myself' do
  it 'should be readable'
    lambda{ @reader.reading }.
      should change{ @reader.knowledge }.
      by(text.amount)
  end
end

# well?

Michael Fellinger wrote:
> On 5/20/07, Peter Marsh <evil_grunger@hotmail.com> wrote:
>> >
>> > T.
>>     puts
>>
> Sorry, but how would you handle block_given? without parameters?

I'm still quite new to Ruby, so I'm not entirely sure what you mean, 
could you explain what you feel the problem would be please?

On 20/05/07, Michael Fellinger <m.fellinger@gmail.com> wrote:
> On 5/20/07, Dick Davies <rasputnik@gmail.com> wrote:

>       @reader.reading
>     lambda{ @reader.reading }.
>       should change{ @reader.knowledge }.
>       by(text.amount)
>   end
> end
>
> # well?

The only extra words there are do/end and you could replace them
with {} if they really bothered you.

If you're saying you personally don't like do/end blocks, then you're
as entitled to that opinion as anyone else, but I don't see this as 
making
DSLs any more or less comprehensible personally

On 5/20/07, Dick Davies <rasputnik@gmail.com> wrote:
> > describe 'myself'
> >
> The only extra words there are do/end and you could replace them
> with {} if they really bothered you.
>
> If you're saying you personally don't like do/end blocks, then you're
> as entitled to that opinion as anyone else, but I don't see this as making
> DSLs any more or less comprehensible personally
>

uh, actually that was an example that i can't interpret the
indentation. I do like the idea of supporting indentation, but not
within ruby.
It's just getting into a mess with method-calls with blocks, manual
lambdas and doing methodchains like foo{bar}.duh{x} - it's not really
about the braces but about the possibility to write that code in a
different syntax at all.

If someone is brighter than me, you're welcome to propose alternatives 
:)

On 5/20/07, znmeb@cesmail.net <znmeb@cesmail.net> wrote:

> I can think of three examples right off the top of my head: Rails, Rake and
> RSpec. There's something really eerie about seeing code like that. You *know*
> it works, but you can't figure out why or how.

None of those are especially magical if you have a decent understand
of how Ruby works.
method_missing + block syntax does not necessary mean evil black magic.

On May 18, 8:23 am, Chris Dew <cms...@googlemail.com> wrote:
> As far as I can see, the 'end' keyword is 'repeating yourself' when
> used with properly indented code.

Maybe it is maybe it isn't. Personally I'm an 'end' man. I like my
blocks.

It would be easier if you learnt to type, or used editor macros.

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

Nope, leave the language as it is. I like it unaltered thank you very
much.

However I've never understood why there has to be 'one true syntax'
for any computer language. As long as the syntax generates the same
ASTs in the interpreter I can't see why you couldn't choose the syntax
you prefer - whether that is whitespace indentation, or the symbolic
mush of the 'C' derived languages.

I can think of an argument for making a parser simpler at the expense of
programmer convenience, and that's the maintainability and portability 
of
the implementation. Some weighing of costs seems to be necessary here - 
for
example, by hacking that extra programmer convenience syntax into the
language, you might lose the ability to represent the language grammar
simply and portably. Implementing a parser for Ruby, for example, is
difficult, because there's no grammar that you can just plug right into 
a
parser and lexer generator. I've read accounts by people attempting to
implement Ruby interpreters where parsing seems to have been a major
stumbling block. There could be situations where that extra syntax might
just not be worth it.

Mushfeq.

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

Just a bit offtopic: I personally used tabs a lot and told people
that they could adjust them to their space-likings (2 or 4), however
as I comment quite a lot, i did find myself mixing tabs and spaces
so I finally changed, avoid using tabs, and use 2 spaces now
everywhere for code. (2 spaces because i like to keep 80 chars /
line, so i can fit more into a line :-) )

On Sun, May 20, 2007 at 09:43:15PM +0900, Michael Fellinger wrote:
> 
> Let's try:
> 
> describe 'myself'
>  it 'should be readable'
>    lambda
>      @reader.reading
>    .should change
>      @reader.knowledge
>    .by(text.amount)

If Ruby looked like that, I'd probably not have bothered -- just stuck
with Perl.

On May 20, 8:43 am, "Michael Fellinger" <m.fellin...@gmail.com> wrote:
> > > RSpec. There's something really eerie about seeing code like that. You *know*
>     lambda
>     lambda{ @reader.reading }.
>       should change{ @reader.knowledge }.
>       by(text.amount)
>   end
> end

(I take it you meant 'if' not 'it')

> # well?

Actually, the later is pretty dang ugly --maybe worse the the first.
However colons would help the first example quite a bit:

  describe 'myself':
    if 'should be readable':
      lambda:
        @reader.reading
      .should change:
        @reader.knowledge
      .by(text.amount)

Though any such indention significance is probably too big of a change
for Ruby at this point anyway. I'd much rather just see more
intelligent was to catch missing "end" errors. Even if meant the
option to put "endif", "endclass", etc.

T.


T.

On Mon, May 21, 2007 at 03:53:47AM +0900, Trans wrote:
>       .by(text.amount)
> 
> Though any such indention significance is probably too big of a change
> for Ruby at this point anyway. I'd much rather just see more
> intelligent was to catch missing "end" errors. Even if meant the
> option to put "endif", "endclass", etc.

I'd prefer we keep the plain ol' "end" syntax, and use editors that can
do delimiter matching as easily with "end" as with braces, brackets, or
parentheses.

On May 20, 3:00 pm, Chad Perrin <per...@apotheon.com> wrote:
> >         @reader.knowledge
> >       .by(text.amount)
>
> > Though any such indention significance is probably too big of a change
> > for Ruby at this point anyway. I'd much rather just see more
> > intelligent was to catch missing "end" errors. Even if meant the
> > option to put "endif", "endclass", etc.
>
> I'd prefer we keep the plain ol' "end" syntax, and use editors that can
> do delimiter matching as easily with "end" as with braces, brackets, or
> parentheses.

Yes, that would be nice, but I've yet to see an editor do it.

T.

On Sun, 20 May 2007 09:43:00 +0200, Robert Klemme 
<shortcutter@googlemail.com> said:
> On 19.05.2007 20:48, M. Edward (Ed) Borasky wrote:

>> I don't like to make the reader or parser work any harder than
>> necessary just for the convenience of the coder.

> I would understand why you would want to make the reader's job easier
> - but the parser?  That's just a piece of software and I believe
> that we should always strive to make software easier to use for
> humans not machines.

In general, I agree.  But I don't want to ignore parsers completely -
the easier a language is to parse, the easier it is for people to
develop tools to work with the language, making programmers' lives
easier.  I'm pretty sure that one of the reasons why there aren't many
C++ refactoring tools is because the language is incredibly difficult
to parse, for example.

David Carlton
carlton@bactrian.org

I agree that I would like the end statements to become more specific - 
at least optionally... I hate when you have a long class file and you 
get the dreaded Unexpected end of file, expecting END or something... 
and you have no idea where in the 200 lines you forgot to insert an end, 
or you left a brace hanging on the line above an end or what not. Even 
if we didn't mandate endif, we could let end do what it does, but with 
an optional argument (end if, end class, end def) - I would use these, 
and the interpreter would thus be able to catch the error a lot closer 
to the source -- class not closed at line 50 is more helpful then end of 
file at line 230...

Stian

On May 18, 3:50 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:
> > am aware knows how to match indentation yet or do/end contexts (not
> > that it could not be coded, thou).
>
> Vim does this just fine.
>

Really?  Not the vim I'm using (cream).  It matches parentheses/
brackets like most editors, but it does nothing to hilight matching do/
end or def/end blocks.  Its status line also tells me nothing about
what function or class I'm in either.  Worse, if I close a bracket,
and the opening of it is outside the "page", it does not tell me what
the opening statement was.  So... no, I'd say it definitively fails
and is worse than emacs.
Or perhaps there's a setting I missed?

On 5/20/07, gga <GGarramuno@aol.com> wrote:

> Really?  Not the vim I'm using (cream).  It matches parentheses/
> brackets like most editors, but it does nothing to hilight matching do/
> end or def/end blocks.  Its status line also tells me nothing about
> what function or class I'm in either.  Worse, if I close a bracket,
> and the opening of it is outside the "page", it does not tell me what
> the opening statement was.  So... no, I'd say it definitively fails
> and is worse than emacs.
> Or perhaps there's a setting I missed?

It's probably that Cream does not have the proper ruby configuration
files bundled with it.
Consider using plain vim or gvim rather than Cream, as it gets rid of
most of the reasons you'd use vim!

On May 21, 9:12 am, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
>
> It's probably that Cream does not have the proper ruby configuration
> files bundled with it.
> Consider using plain vim or gvim rather than Cream, as it gets rid of
> most of the reasons you'd use vim!

Someone wrote a macro (or whatever it is called) for gvim that
automatically inserts an "end" statement whenever you enter a keyword
that requires an "end".

for example:
type:

"if cond"  and press return

the cursor goes to the next line and an "end" statement appears on the
subsequent line with the proper indentation.

if cond
                  # cursor at start of this line.
end

On 5/20/07, gga <GGarramuno@aol.com> wrote:
> > > am aware knows how to match indentation yet or do/end contexts (not
> > > that it could not be coded, thou).
> > Vim does this just fine.
> Really?  Not the vim I'm using (cream).  It matches parentheses/
> brackets like most editors, but it does nothing to hilight matching do/
> end or def/end blocks.  Its status line also tells me nothing about
> what function or class I'm in either.  Worse, if I close a bracket,
> and the opening of it is outside the "page", it does not tell me what
> the opening statement was.  So... no, I'd say it definitively fails
> and is worse than emacs.

> Or perhaps there's a setting I missed?

I don't use the cream settings. I use vim with the Ruby settings
available on RubyForge. Now, automatic highlighting isn't present
(e.g., the same way you get with {}), but you *can* hit "%" to jump
between matching pairs. It isn't for everyone, either, but the folding
available with vim does more for me being certain of matched pairs
than anything else (if it doesn't fold properly, it isn't likely to
compile properly).

I have TextMate (but don't use it), and I'm pretty sure it can do the
same. I've heard good things about Kate from Linux users, too.

-austin

On Monday, May 21 2007, Austin Ziegler wrote:
> I have TextMate (but don't use it), and I'm pretty sure it can do the
> same. I've heard good things about Kate from Linux users, too.

Indeed, Kate is great (although not as good as what I'veseen/heard about
Textmate) butit certainly doesn't highlight do...end combinations, only 
the
standard [], {}, etc.  It may be possible to add support for it, 
however.

-Ben

On 2007-05-20 20:45:59 -0700, gga <GGarramuno@aol.com> said:

>>> types.  And most editors can easily find matching braces.  No editor I
> and the opening of it is outside the "page", it does not tell me what
> the opening statement was.  So... no, I'd say it definitively fails
> and is worse than emacs.
> Or perhaps there's a setting I missed?

% works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
not sure if this is the same as the dist that a few guys have been
working on at rubyforge.

On 6/1/07, Erik Hollensbe <erik@hollensbe.org> wrote:
> On 2007-05-20 20:45:59 -0700, gga <GGarramuno@aol.com> said:

> > Really?  Not the vim I'm using (cream).  It matches parentheses/
> > brackets like most editors, but it does nothing to hilight matching do/
> > end or def/end blocks.

> % works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
> not sure if this is the same as the dist that a few guys have been
> working on at rubyforge.

% in vim does something related to what he's asking for, but it
doesn't automatically highlight the matching token when the cursor
lands on it's mate.  G?Vim will do this for single character matching
tokens like ( ), [] and {}, as you move the cursor over one of these
it will highlight its mate if it doesn't have to scroll to do so.

Personally, I don't miss it much.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On 6/1/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> > % works, but I'm using a ruby-matchit plugin I found on vim.org. I'm
> > not sure if this is the same as the dist that a few guys have been
> > working on at rubyforge.
>
> % in vim does something related to what he's asking for, but it
> doesn't automatically highlight the matching token when the cursor
> lands on it's mate.  G?Vim will do this for single character matching
> tokens like ( ), [] and {}, as you move the cursor over one of these
> it will highlight its mate if it doesn't have to scroll to do so.

Actually, mate-highlighting was added in vim 7:
http://vimdoc.sourceforge.net/htmldoc/pi_paren.html#matchparen


HTH,
Keith

On 6/1/07, Keith Fahlgren <keith@audiobeta.com> wrote:
>
> Actually, mate-highlighting was added in vim 7:
> http://vimdoc.sourceforge.net/htmldoc/pi_paren.html#matchparen

Right, which is what I use.  And as I said, it only highlights  pairs
of single character delimiters which are unequal, it can't highlight
do/end or "/".

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

If you install the Vim/Ruby (http://vim-ruby.rubyforge.org/) plugins
it'll work with % and do/end.

Also, if you

:set sm

it will highlight briefly the opening of a block by the cursor going
there and back really quickly AND setting the opening and closing
markers in a different color.

There are some options with sm (showmatch) that I don't recall. Do

:help showmatch

in Vim for details.

My experience with Vim is that if you can think of ANYTHING for Vim to
do, chances are someone thought of it and created a plugin for it
(yes, you can play tetris and sokoban with vim ->
(http://www.vim.org/scripts/script_search_results.php?keywords=tetris&script_type=&order_by=rating&direction=descending&search=search).

If you haven't, I'd suggest checking the scripts section in vim.org
(http://www.vim.org/scripts/index.php). Also, use the search
(http://www.vim.org/search.php) to look for plugins.

HTH

Jerry.

I love indentations too..

Check out my project for Ruby space convention :/

http://lazibi.rubyforge.org

It's code generation.

> Jinjing Wang wrote:
> I love indentations too..
> 
> Check out my project for Ruby space convention :/
> 
> http://lazibi.rubyforge.org
> 
> It's code generation.
> 

You don't need to do code generation, at least in the way you have done
it. I posted a solution way back up this thread that does not require
the creation of intermediate files to load.

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


See

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

for the details.

Dear Mats,

I am kind of new to ruby and like it after looking python first.  As 
some other people said, my only major complaint is it's many "END". 
Among java/c/C++/python, the "END" keep reminding me the inconvenience 
of it during coding ruby.  I like ruby because it's easy to learn, and 
to read. It's designed for be friends of programmers.  But I feel the 
"END" may have a negative role to ruby's purpose or attraction.

I am fine to have "END" for class or methods. But for IF,WHILE, CASE, 
FOR, etc., when there are many levels it often make me confused what the 
matching part of the those "END"s are.

I understand and agree your comment that ruby had better to have 
something to close the code block. But I sincerely hope you could come 
up something else to replace the "END".

My first thought to use brace "{...}" to replace "END" since it's a 
popular convention.

I suggest to use only the "do...end" to formalize the blocks, brace {} 
will be stopped to be used. It seems to me it's a waste of symbols to 
have two ways to represent blocks, which may not be the most frequently 
used.  Or consider to use use:
 "/* */", "|...|", "<...>", "[...]" , "(...)", "((...))", , "//...//", " 
:...: ", " '...' ", " `...` " for blocks.

To enhance readability is probably one of ruby's design purpose and I 
really hope some thing could be done earlier to make the "END" looks 
prettier.

Thank you!

 On 18/05/07, Yukihiro Matsumoto <matz@ruby-lang.org> 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

Frasier Mruby wrote:

Why not adopt "Python Style" indentation for Ruby?   Because that would
  bite a big one.

> 
> I am fine to have "END" for class or methods. But for IF,WHILE, CASE, 
> FOR, etc., when there are many levels it often make me confused what the 
> matching part of the those "END"s are.

Then don't do that.  Seriously.  Twisty conditionals is a code smell.
(Having fought with deep hierarchies of YAML and HAML, the lack of an
explicit "end" token doesn't really help in complex documents; in fact,
it can be detriment.  Sometimes explicit is better than implicit.)


BTW, doesn't your code editor find the matching braces (or do/ends) for
you?  (If not, get a real editor.  They're free.)

> To enhance readability is probably one of ruby's design purpose and I 
> really hope some thing could be done earlier to make the "END" looks 
> prettier.

I *rarely* run into Ruby code that is not readable.  When I do, it's
almost always for a reason (e.g. Camping source code, or some code
golfing).

The idea that coders need to be coerced into writing readable code is as
flawed as that of the need for Java-style static typing to avoid bugs.

It sounds good in blog posts and mailing lists, but lacks empirical
evidence.


--
James Britt

www.happycamperstudios.com   - Wicked Cool Coding
www.jamesbritt.com           - Playing with Better Toys
www.ruby-doc.org             - Ruby Help & Documentation
www.rubystuff.com            - The Ruby Store for Ruby Stuff

James, thank you for you fast response.

I didn't propose to get rid of the "END" like python does, but wondered 
if there could be cleaner syntax to as an alternative for "END".

>James Britt wrote:
>> I am fine to have "END" for class or methods. But for IF,WHILE, CASE, 
>> FOR, etc., when there are many levels it often make me confused what the 
>> matching part of the those "END"s are.
> 
> Then don't do that.  Seriously.  Twisty conditionals is a code smell.
> (Having fought with deep hierarchies of YAML and HAML, the lack of an
> explicit "end" token doesn't really help in complex documents; in fact,
> it can be detriment.  Sometimes explicit is better than implicit.)
> 

Ruby code is reasonable or readable with "END". And I agree a better 
editor would help to find matching END, but still wonder if there could 
be room to make the ruby code cleaner by considering other syntax to 
replace "END".

What I was saying in previous post is to free up the braces "{}" out of 
block syntax to replace "END".  For blocks, besides "do...end", use 
something else like "[], or /**/. e.g.:

  class Foo
    def bar(b)
      c = b+1
      if b is not nil
        if c > 10
           c++
           if c %2 == 0
             c += 3
             print c
           end
        end

        if d < 9
           d += 2
           print d
        end
      end

      a = [1, 2]
      a.each {|num| print num }

    end
  end

  # tries to clean up the "END"s

  class Foo
    def bar(b) {
      c = b+1
      if b is not nil {
        if c > 10 {
           c++
           if c %2 == 0 {
             c += 3
             print c
           }
        }

        if d < 9 {
           d += 2
           print d
        }
      }

      a = [1, 2]
      a.each [|num| print num ]
      a.each (|num| print num )
      a.each < |num| print num >
      a.each /* |num| print num */
      a.each /# |num| print num #/
      ...
    }
  end

If {} can represent a bock, then personally it might also readable to 
use [] and syntax above to denote blocks.

I also like the idea that "END" is optional for one line if, like:

if a > 0 :
  print a

I can live with "END" in ruby, now just want to express an opinion or 
wish to make the ruby code more cleaner, and more programmer attracted.

Just my quick chip-in:

I find Ruby's syntax as-is works remarkably well. The only problem it 
causes me is with do-end mismatches where the parser just runs off the 
end of the file, with no indication of where the missing do or end might 
be. I have on many occasions resorted to chopping a copy of my source 
file to find the problem (that is, lopping out a class or a method at a 
time until the problem goes away)

DSL's are also a source of this problem:

  context "an empty object" do
    should "have zero size" do
      ...
    end
  end

Miss out either of those 'do's and it's hard to tell where the problem 
is.

Personally, the solution I would love to have is a parser/pretty-printer 
tool which can read a Ruby source file and spit it back out with 
"standardised" indentation. It would then be obvious where the problem 
lies. You'd get the benefit of python-style indentation, without 
actually having to use python-style indentation :-)

Unfortunately, the lack of specification makes it really hard to 
implement; and I don't think I could use something like ParseTree as I 
think it would rely on the file being parsed successfully up-front, 
whereas I want this for programs which don't parse. Maybe there's 
another ruby implementation which could do this. Otherwise, the best I 
can think of is to modify the existing Ruby parser to spit out 
auto-indented code as it reads the source.

I don't wish to change to a different text editor, and in any case, I 
don't believe that *any* editor has a sufficiently complete knowledge of 
Ruby lexing and parsing rules that it will always match the Ruby way of 
parsing source.

Anyway, if anyone knows of a tool which does this, it would make me very 
happy :-)

> Ruby code is reasonable or readable with "END". And I agree a better
> editor would help to find matching END, but still wonder if there could
> be room to make the ruby code cleaner by considering other syntax to
> replace "END".

After you use ruby for a while, you'll stop wanting to make it look
like some other language. You'll realize it's nice the way it is. And
certain things will start to grow on you, such as using @x instead of
self.__x.

> I also like the idea that "END" is optional for one line if, like:
>
> if a > 0 :
>   print a

If that's a one-line 'if', what's this?

  print a if a > 0

even better, that's what. :)

-- Mark.

On 6 oct. 08, at 15:57, Brian Candler wrote:
> Personally, the solution I would love to have is a parser/pretty- 
> printer
> tool which can read a Ruby source file and spit it back out with
> "standardised" indentation. It would then be obvious where the problem
> lies. You'd get the benefit of python-style indentation, without
> actually having to use python-style indentation :-)


Maybe this is close to what you want.
http://blog.neontology.com/posts/2006/05/10/beautiful-ruby-in-textmate

On 6 oct. 08, at 16:17, Joe Wölfel wrote:

>
> Maybe this is close to what you want.
> http://blog.neontology.com/posts/2006/05/10/beautiful-ruby-in-textmate
>
Sorry, here's a better link.
http://www.arachnoid.com/ruby/rubyBeautifier.html

Brian Candler wrote:

> 
> I don't wish to change to a different text editor, and in any case, I 
> don't believe that *any* editor has a sufficiently complete knowledge of 
> Ruby lexing and parsing rules that it will always match the Ruby way of 
> parsing source.
> 
> Anyway, if anyone knows of a tool which does this, it would make me very 
> happy :-)

Well, vi/vim/gvim users can have the code auto-format, which will "fix"
indentation.

When I get those nasty kEND errors I run the auto-format macro and scan
down the code until I see something out of place.  Then error is usually
a few lines above that point.


--
James Britt

www.happycamperstudios.com   - Wicked Cool Coding
www.jamesbritt.com           - Playing with Better Toys
www.ruby-doc.org             - Ruby Help & Documentation
www.rubystuff.com            - The Ruby Store for Ruby Stuff

Frasier Mruby wrote:
> Dear Mats,
>
> I am kind of new to ruby and like it after looking python first.  As 
> some other people said, my only major complaint is it's many "END". 
> Among java/c/C++/python, the "END" keep reminding me the inconvenience 
> of it during coding ruby.  I like ruby because it's easy to learn, and 
> to read. It's designed for be friends of programmers.  But I feel the 
> "END" may have a negative role to ruby's purpose or attraction.
>   

Like any new language, it takes some time to adjust your eyes and 
fingers.

> I am fine to have "END" for class or methods. But for IF,WHILE, CASE, 
> FOR, etc., when there are many levels it often make me confused what the 
> matching part of the those "END"s are.
>   

None of your suggestions seem to address this issue. Matching 'end' is
no harder than matching '}'. If you get confused, add documentation like
some people do:

end#if
end#while
end#class

> I understand and agree your comment that ruby had better to have 
> something to close the code block. But I sincerely hope you could come 
> up something else to replace the "END".
>
> My first thought to use brace "{...}" to replace "END" since it's a 
> popular convention.
>   

But then it looks like C/Java.

>   
I think 'end' looks fine, personally. I used to use curly braces all the
time, but now I find myself using them as little as possible. do/end
seems nicer and I don't get them confused with hashes that way.

Besides, I enjoy the current look for conditionals. Given your later
example, I prefer to see

if b is not nil

def bar b

than

if b is not nil {

def bar b {

Especially if it's going to lead to arguments about where that '{'
should go. Same line? Next line? Next line indented? I don't want C. I
don't want Java. I don't want parentheses around my conditionals when
they aren't needed. I don't want to have to use my shift key more than
necessary. I really don't see the problem with the current syntax. I
respect your opinion but definitely do not agree.

-Justin

Mark Thomas wrote:
> After you use ruby for a while, you'll stop wanting to make it look
> like some other language. You'll realize it's nice the way it is. And
> certain things will start to grow on you, such as using @x instead of
> self.__x.
> 

Ok. I will try to use ruby more then.  I like ruby's other syntax such 
as @x than self.__x.  Only complaint is the "END", which I have to type 
even for a couple of short lines of IF.

> If that's a one-line 'if', what's this?
> 
>   print a if a > 0
> 
> even better, that's what. :)
> 
> -- Mark.

Yeah, that's one line if but it seems Mats mentioned one syntax before 
like :  if a > 0 then do this  . Sth like that.  When if clause is 
longer the existing one-line if may not looks elegant.  Thanks.

I've thought that one rather likes the structure of a language learned
first.

I learned Ruby first then Python.

I never liked the indentation of Python probably as a result

Tom

On Mon, Oct 6, 2008 at 5:46 PM, Tom Reilly <w3gat@nwlagardener.org> 
wrote:
> I've thought that one rather likes the structure of a language learned
> first.
>
> I learned Ruby first then Python.
>
> I never liked the indentation of Python probably as a result

Actually, the more I write in scheme, the more I like its structure.
It all just works.

martin

Justin Collins wrote:

> None of your suggestions seem to address this issue. Matching 'end' is
> no harder than matching '}'. If you get confused, add documentation like
> some people do:
> 
> end#if
> end#while
> end#class
> 

It's a good way.  It's just that there're  more typings.  If you says 
"matching end is no harder than }, then }  could be an considered as an 
option I assume.

>> My first thought to use brace "{...}" to replace "END" since it's a 
>> popular convention.
>>   
> 
> But then it looks like C/Java.
> 

Liking other languages may not be bad.  Ruby's syntax on my first 
impression is that it's similar to python, thinking about the "class" or 
"def". Ruby has evolved by learning merits from other languages.

> I think 'end' looks fine, personally. I used to use curly braces all the
> time, but now I find myself using them as little as possible. do/end
> seems nicer and I don't get them confused with hashes that way.
> 

Thanks for your reply, Justin.    It seems I am not the only one who are 
concerned with the "END".  Not 2 years ago, 1 year ago, or now.  On 
ruby's logo, it says "programmer's best friend". It seems ruby's 
objective is to make it programmer-friendly language.  When there are 
not few people have been wondering if any improvement could be made on 
its syntax, some effort may need to be considered on the improvement. 
If it's determined there's absolutely no room to improve, then that's 
fine.

 If no improvement will be made in near future, I can live with "END", 
though in my mind I may still have the thought of it and wondering if it 
could be made better.

Don't get my wrong. I hope ruby getting better and can attract more 
programmers. With this mind, I pointed what I felt, which is shared by 
other new comers.

Hi --

On Tue, 7 Oct 2008, Tom Reilly wrote:

> I've thought that one rather likes the structure of a language learned first.

I like the structure of Ruby more than that of BASIC, so there goes
that theory :-)


David

On Mon, Oct 6, 2008 at 6:18 PM, Frasier Mruby <flyingkite@edoors.com> 
wrote:

> Only complaint is the "END", which I have to type
> even for a couple of short lines of IF.

If you use an IDE/editor like NetBeans, you don't -- it's inserted for 
you
when you enter something like

  if @foo.nil? <return>
    | # cursor placed here
  end # auto-inserted

FWIW,

+1

I always type (), [], {}, do/end, begin/end,<>, etc. upfront together 
and then insert what goes in between. I can't quite remember the last 
time I have mismatched these in any language.

OTOH, I can't stand Python's semantically significant white space 
approach. It seems to give me trouble a lot more often than I'd like... 
perhaps because I have not used it long enough.

Alex

+1

I've used Java for years, and it's great, but I would not want to make 
Ruby
more like Java. I'm new to Ruby, but really enjoy it so far. As for 
Python,
I just can't get my self into it. I attended one of Mark Lutz's training
sessions, just to find I didn't care for coding Python. I'm sure it's a
great language, but I guess it's not for me. Mark did a great job. I 
find
Ruby very easy to use, and the syntax well thought out. Don't change a
thing, at least not until I've learned it better.

Alle Tuesday 07 October 2008, Tom Reilly ha scritto:
> I've thought that one rather likes the structure of a language learned
> first.
>
> I learned Ruby first then Python.
>
> I never liked the indentation of Python probably as a result
>
> Tom

I learned Python first, hated its indentation-based structure, switched 
to
Ruby and loved it.

Stefano

David A. Black wrote:
>
> David
>

Yeah :( Although sometimes I miss the simplicity of ON KEY GOSUB...

-Justin

Hi,

At Tue, 7 Oct 2008 04:57:45 +0900,
Brian Candler wrote in [ruby-talk:317027]:
> I find Ruby's syntax as-is works remarkably well. The only problem it 
> causes me is with do-end mismatches where the parser just runs off the 
> end of the file, with no indication of where the missing do or end might 
> be. I have on many occasions resorted to chopping a copy of my source 
> file to find the problem (that is, lopping out a class or a method at a 
> time until the problem goes away)

Python style indentation also can't help you alone.  How can it
know which did you intend?

  if x == "ok":
    print "ok"
    print "foo"

  if x == "ok":
    print "ok"
  print "foo"


> Personally, the solution I would love to have is a parser/pretty-printer 
> tool which can read a Ruby source file and spit it back out with 
> "standardised" indentation. It would then be obvious where the problem 
> lies. You'd get the benefit of python-style indentation, without 
> actually having to use python-style indentation :-)

Recent 1.9 warns when it see a mismatch.

$ ./ruby -ve 'begin
  end'
ruby 1.9.0 (2008-10-07 revision 19704) [i686-linux]
./ruby: warning: mismatched indentations: line 1:'begin' and line 
2:'end'

I code in ruby and c++.

I love {} in c++.

I love "do", "end" in ruby.

That's just because I am deeply grateful for what both these languages
let me achieve, each in it's own field.

Gaspard

Hi --

On Tue, 7 Oct 2008, Frasier Mruby wrote:

>
> It's a good way.  It's just that there're  more typings.  If you says
> "matching end is no harder than }, then }  could be an considered as an
> option I assume.

That doesn't follow.

>>> My first thought to use brace "{...}" to replace "END" since it's a
>>> popular convention.
>>>
>>
>> But then it looks like C/Java.
>>
>
> Liking other languages may not be bad.  Ruby's syntax on my first
> impression is that it's similar to python, thinking about the "class" or
> "def". Ruby has evolved by learning merits from other languages.

Yes, to a large extent. But Ruby also *is* a language. It's not an
experiment in how to stick different ideas from other languages
together.

Have you written to any C mailing lists, suggesting that C adopt
features from Ruby?

> its syntax, some effort may need to be considered on the improvement.
> If it's determined there's absolutely no room to improve, then that's
> fine.

It's been discussed a million times over many years, if that's what
you mean. If Matz were going to remove the "end" keyword, I think he
would have done it by now.

> If no improvement will be made in near future, I can live with "END",
> though in my mind I may still have the thought of it and wondering if it
> could be made better.
>
> Don't get my wrong. I hope ruby getting better and can attract more
> programmers. With this mind, I pointed what I felt, which is shared by
> other new comers.

Please don't put this in terms of Ruby attracting programmers. Ruby
does about as good a job as any language I've ever heard of, when it
comes to having programmers like it. Not everyone does, of course, but
Matz has accomplished something truly great and amazing in exactly
that sense. "end" is not a test of whether or not Ruby is an
attractive language, and curly braces are not Ruby's ticket to
popularity.

In general, the best thing by far is to spend some time with the
language, and let it speak to you.


David

Hi --

On Tue, 7 Oct 2008, Gaspard Bucher wrote:

> I code in ruby and c++.
>
> I love {} in c++.
>
> I love "do", "end" in ruby.
>
> That's just because I am deeply grateful for what both these languages let me 
> achieve, each in it's own field.

Absolutely. Very few of these "features" really have any absolute
quality of being good or bad, outside of their context.


David

I have to mention in the first line of each post.  I agree the idea of 
closing a code block with something like "END", but suggest to use 
something else to replace it such as "{ }".

>Have you written to any C mailing lists, suggesting that C adopt
>features from Ruby?
If you felt insulted when some people ask if ruby could make improvement 
in future on its syntax, I feel sorry for that and think people could be 
better off to have an opener mind.  Event if I didn't write to any C 
mailing list asking C to improve its syntax, but there are much chances 
that some other people had written to Java mailing list ask java to 
adopt some nice feature from ruby or other languages.  That might be the 
reason in jdk1.5 there were some syntax improvement like the adoption of 
Generics. In future release, Python might have considered to remove 
"self" as suggested by someone who wrote to python mailing list.  It's a 
common scenario that suggestions were brought up to ask the possibility 
of syntax improvement,just like the first article in this thread posted 
by someone else.

>It's been discussed a million times over many years, if that's what
>you mean.
If the "END" will not be considered to be replaced, then I suggest ruby 
forum people be better off to add a FAQ page so that to prevent other 
people from asking the same question again and again, since probably I 
am not the only person who are concerned with the "END".

>"end" is not a test of whether or not Ruby is an attractive language,
It's a not test, but I, or other may have noticed cases (could be more 
potentially) some ruby users' concerns about "END", while relatively 
fewer people complaining about the curly braces.

I will take other's advice and use more and get myself familiar with 
it.Thank you for your time.

Hi --

On Tue, 7 Oct 2008, Frasier Mruby wrote:

> If the "END" will not be considered to be replaced, then I suggest ruby
> forum people be better off to add a FAQ page so that to prevent other
> people from asking the same question again and again, since probably I
> am not the only person who are concerned with the "END".

You can't have a FAQ entry for every aspect of Ruby syntax that
probably won't be changed :-)

>> "end" is not a test of whether or not Ruby is an attractive language,
> It's a not test, but I, or other may have noticed cases (could be more
> potentially) some ruby users' concerns about "END", while relatively
> fewer people complaining about the curly braces.

I think that's because the curly braces are not used, and 'end' is.
People don't complain about things they don't like that aren't in the
language :-)


David

2008/10/7 Frasier Mruby <flyingkite@edoors.com>:
> I am kind of new to ruby and like it after looking python first.
[...]
> I have to mention in the first line of each post.  I agree the idea of
> closing a code block with something like "END", but suggest to use
> something else to replace it such as "{ }".

How about first learning and using the language instead of suggesting
changes right away?

>>Have you written to any C mailing lists, suggesting that C adopt
>>features from Ruby?
> If you felt insulted when some people ask if ruby could make improvement
> in future on its syntax, I feel sorry for that and think people could be
> better off to have an opener mind.

What about you?  How open is your mind?

>  Event if I didn't write to any C
> mailing list asking C to improve its syntax, but there are much chances
> that some other people had written to Java mailing list ask java to
> adopt some nice feature from ruby or other languages.  That might be the
> reason in jdk1.5 there were some syntax improvement like the adoption of
> Generics. In future release, Python might have considered to remove
> "self" as suggested by someone who wrote to python mailing list.  It's a
> common scenario that suggestions were brought up to ask the possibility
> of syntax improvement,just like the first article in this thread posted
> by someone else.

Well, but well thought out suggestions with a realistic perspective of
realization need good understanding of the matter. And with changes in
programming language syntax matters are always quite complicated - if
only for the thousands or millions of lines of code that might be
affected.

>>It's been discussed a million times over many years, if that's what
>>you mean.
> If the "END" will not be considered to be replaced, then I suggest ruby
> forum people be better off to add a FAQ page so that to prevent other
> people from asking the same question again and again, since probably I
> am not the only person who are concerned with the "END".

You can easily search the archives of this list and find out.  Note:
you could have done it /before/ jumping right into the next language
change discussion.

> I will take other's advice and use more and get myself familiar with
> it.Thank you for your time.

That's a good course of action.

Regards

robert

Robert Klemme wrote:
> What about you?  How open is your mind?
"Open", as my understanding, is allowing others to say something and not 
forbid them. I won't feel bad, impatient,or angry if other people brings 
up suggestions which I don't agree, and won't use sarcastic tones to 
reply newbie's messages.

> Well, but well thought out suggestions with a realistic perspective of
> realization need good understanding of the matter. And with changes in
> programming language syntax matters are always quite complicated - if
> only for the thousands or millions of lines of code that might be
> affected.
> 
That's true. Agree.  It's just that Mats mentioned during development of 
new releases he expressed the intention of improve the ruby syntax.

> You can easily search the archives of this list and find out.  Note:
> you could have done it /before/ jumping right into the next language
> change discussion.

I DID the search /before/ this discussion.  I didn't find other 
discussion about the replacement of "END". Sorry.  This thread is one of 
the closest. (You can try searching the "END" in the forum.) If you know 
easier way, please let me and other newbies know so that they don't jump 
in next time.

Thank you for your time.

"Or consider to use use:
>  "/* */", "|...|", "<...>", "[...]" , "(...)", "((...))", , "//...//", "
> :...: ", " '...' ", " `...` " for blocks."
>
I can't stand with the idea of using other chars than braces {} for a 
block,
I think it's particular to ruby to write:
names.each { |name| puts name }
I think do...end is a little long for a small block like this.

"My first thought to use brace "{...}" to replace "END" since it's a
> popular convention."

Well, if you take the braces, you will have to put one just after the
condition(if, else, ...)
and "{" is often useless I think. If you indent your code, where will 
you
write the "{" ? after the "if" on the same line ?  on a new line ?
That's why I like the "end", one end for everything, and only one place 
if
you indent.

And the syntax "do(sth) if condition" is fast and logical to write.But I
think we should not use this for long lines for readability reasons.

Regards,
Benoit

It seems that  DSLs in Ruby get some of their power from the optional
nature of parenthesis.  I wonder if making 'end' more optional too
would make DSLs yet more powerful and expressive.  It might be an
interesting experiment to see what Ruby would look like if 'end' were
optional in places where indentation made it unambiguous.  In that
way, it would be consistent with parenthesis being optional.

BTW, the term "domain-specific language" seems inaccurate.   Many of
these languages are really double-entendre languages.  Their power of
expression seems to come from having two equally good and correct
interpretations - one domain specific and one in Ruby.  The double
entendre doesn't just eliminate clutter, it also eliminates the
mental gymnastics required to translate from one language to another.

Nobuyoshi Nakada wrote:
> Recent 1.9 warns when it see a mismatch.
> 
> $ ./ruby -ve 'begin
>   end'
> ruby 1.9.0 (2008-10-07 revision 19704) [i686-linux]
> ./ruby: warning: mismatched indentations: line 1:'begin' and line 
> 2:'end'

Ooh, that's nice. Now I have a reason to install 1.9 alongside a 
production ruby (although I'll be very careful to keep the two separate)

Thanks,

Brian.

Yukihiro Matsumoto wrote:
> But I sometime want "end"-less single line structure (in normal
> order), e.g.
> 
>   if foo then bar  # pseudo syntax; you may require delimiters
> 
> not
> 
>   bar if foo
> 
> especially when I write very small code chunk.  Not knowing what
> syntax it should be.

As an observation, I always found ruby's "then" to be a rather 
superfluous non-keyword; that is,

  if a == b then
    ...
  end

  if a == b
    ... same
  end

  if a == b then ...; end

  if a == b; ... same; end

So a possible (but highly incompatible) approach would be for "then" to 
introduce a single-line block, e.g.

  if a == b then puts "hello"; puts "world"    # end implied

  if a == b
    puts "hello"
    puts "world"
  end

It could also be used, although less obviously, in other constructs:

  while !a.empty? then puts a.shift

I'm not sure what 'then' followed immediately by newline should do.

Anyway, this is just an idle thought, as it would break lots of things.

On Tue, Oct 7, 2008 at 3:35 PM, Brian Candler <b.candler@pobox.com> 
wrote:
> It could also be used, although less obviously, in other constructs:
>
>  while !a.empty? then puts a.shift

"while then"?  (kinda sounds funny to my ears :)

And, in this case, is it really better than:
        puts a.shift while !a.empty?

Benoit Daloze wrote:
> I can't stand with the idea of using other chars than braces {} >for a  block,
> I think it's particular to ruby to write:
> names.each { |name| puts name }
Does it looks a little  better if using square brace? since it LOOKs 
more like a "block":
names.each [ |name| puts name ]

> I think do...end is a little long for a small block like this.
Agree.  do...end is suitable for multiple lines block.

And can curly brace be used replacing "END" while it is kept as it is to 
represent blocks?  Any parsing difficulty?

>where will you write the "{" ? after the "if" on the same line >?  on a new line ?
For simplicity reason, I would say put the "{" on the same line of "if".

Thanks for your reply.

unknown wrote:
> "while then"?  (kinda sounds funny to my ears :)

It does. I was just trying to see what happens if you apply the idea 
consistently. I guess taken to extremes you'd also get

    def f(x,y) then x+y

which I don't particularly like, but then one-line method definitions 
are pretty unusual.

<aside>
I still like that better than "f =-> x,y {x+y}" from 1.9, which is 
horrid

I'd much rather have a new keyword: "f = fn(x,y) {x+y}"
</aside>

> And, in this case, is it really better than:
>         puts a.shift while !a.empty?

No, not really.

It might be useful for 'if' though. I quite often write code with lots 
of backwards lines:

   something if foo
   raise "Error" unless bar
   other if baz

and it would be good to write them the right way round. (Although 
"unless...then" doesn't really read well either)

More importantly,

   if (x = some_big_calculation) then x.something

can't be written in backwards form currently.

...me too...

On Tue, Oct 07, 2008 at 02:35:10AM +0900, Frasier Mruby wrote:
> I am kind of new to ruby and like it after looking python first.

It might take some time for that particular taste to fade away...
keep on :)

> It's designed for be friends of programmers.  But I feel the
> "END" may have a negative role to ruby's purpose or attraction.

It's very subjective, you might want to have a look at a dozen
more languages (e.g. Modula-2 also uses END with no problem).

>  On 18/05/07, Yukihiro Matsumoto 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

...and teamwork is more nasty since there's one more choke point.


On Tue, Oct 07, 2008 at 11:47:35PM +0900, Robert Klemme wrote:
> How about first learning and using the language instead of
> suggesting changes right away?

It helps in wider sense: while getting acquainted with a new OS,
or with a university lab people who were there before you.
Lurking and learning what is valued in this community and what
is frowned upon helps getting into being valued and not frowned.
Or, well, quitting without much ado -- that's better at times.

> > If you felt insulted when some people ask if ruby could make
> > improvement in future on its syntax

It probably could but what you suggest is taking one of the worst
design flaws in Python and planting it into Ruby.  It is not an
improvement by any measure.

> > I feel sorry for that and think people could be better off to
> > have an opener mind.
> What about you?  How open is your mind?

...e.g. regarding adopting new syntax and comparing it over
a few weeks :-)

> > I will take other's advice and use more and get myself
> > familiar with it.

Good luck, and don't get frustrated :-)  You'll understand people
who objected after more code behind.... both written and read.


On Wed, Oct 08, 2008 at 01:23:10AM +0900, Frasier Mruby wrote:
> "Open", as my understanding, is allowing others to say
> something and not forbid them.

JFYI: some tend to mix up "openness", "freedom" and "impunity".
These are all different things, e.g. I'm not particularly "open"
to badmouthing or brutal wording.

> I won't feel bad, impatient,or angry if other people brings up
> suggestions which I don't agree

Wonder if you've already tried that couple hundred times on
the same old matter. :) [for sufficient N of matters if you had]

> and won't use sarcastic tones to reply newbie's messages.

There's also a problem of time available.  As one proverb would
put it, "one can ask so many questions that thousand wizards
won't keep up answering".

So being patient to suggestions one wouldn't agree to is respecting
the other side, but being patient to first learn about something
and then ask why things are this way not the other (and only then
suggesting to fix or improve something) is even more so.


On Tue, Oct 07, 2008 at 10:25:42AM +0900, Martin DeMello wrote:
> > I never liked the indentation of Python probably as a result
> Actually, the more I write in scheme, the more I like its
> structure.  It all just works.

It's not about structure in the first place, functional languages
differ in approach; syntax is an effect, not the cause.  See also
http://mitpress.mit.edu/sicp/

BTW Ruby is a nice language in terms of softly understanding OOP
or FP to those who would do C or shell before.  IMO much better
than bare C++ or Java (got headaches), or probably LISP (was too
young when put my nose in it for the first time)...


On Tue, Oct 07, 2008 at 07:01:31PM +0900, David A. Black wrote:
> Have you written to any C mailing lists, suggesting that C adopt
> features from Ruby?

Fortuned, sir! :)

I posted a message in this thread under the circumstances of:

1. I agreed that ruby had better to close the code block using a 
keyword. I didn't repeat the topic "why not adopt python style".
2. Some other ruby users (sound have much more ruby experience than me) 
has similar concerns about "END". (The author of 1st article in this 
thread seems like a ruby core contributor.)
3. Mats expressed his intention since 2006 to experiment new syntax as 
alternative for "END". (In 1.9, the ";;" was experimented but abandoned 
later.)

So basically I asked if other similar experiment would be made in 
future. And I wondered if curly braces "{}" could be considered as an 
alternative.  For blocks, use "do...end" if multiple lines, use other 
chars like "names.each [|name| puts name]" for single line.

|Michael Shigorin wrote:

> It helps in wider sense: while getting acquainted with a new OS,
> or with a university lab people who were there before you.
> Lurking and learning what is valued in this community and what
> is frowned upon helps getting into being valued and not frowned.

> So being patient to suggestions one wouldn't agree to is respecting
> the other side, but being patient to first learn about something
> and then ask why things are this way not the other (and only then
> suggesting to fix or improve something) is even more so.

I may not be alone. As I said in 2) above, it seems some 
more-experienced ruby users had similar concerns.

> It probably could but what you suggest is taking one of the worst
> design flaws in Python and planting it into Ruby.  It is not an
> improvement by any measure.

I appreciate the purpose of "END". I was not suggesting to use python 
style from my first post in this thread. Just wondered if there could be 
better syntax as an alternative.

> BTW Ruby is a nice language in terms of softly understanding OOP
I am excited about ruby,too.

>> Have you written to any C mailing lists, suggesting that C adopt
>> features from Ruby?
To be frankly, I can imagine if I haven't heard of ruby, and if I can't 
find others asking the same question, there are much chances I will send 
an email to python group suggesting them to remove the "self" out of 
python method argument list.  Syntax improvement requests, in my 
imagination, is not that an insult to a language, if one consider it's a 
suggestion with a good wish to make it better.  Maybe I underestimated 
language lovers' sensitivities.

> There's also a problem of time available.  As one proverb would
> put it, "one can ask so many questions that thousand wizards
> won't keep up answering".

I did the search both in Google and the forum, but didn't find a lot of 
discussion about alternative syntax for "END".  Since as David A. Black 
said (thanks for his reply, by the way), if similar question has been 
discussed "a million times", a FAQ page might help for both newbies and 
rubist to save everybody's time.  A topic discussed a millions times may 
suggest it's controversial, or suggest if there's room for improvement. 
Apologize for my ignorance if I missed anything.

Thank you for your time.

Then you're introducing a big chunk of parser ambiguity.  For example

    if a == b then puts "hello"; puts "world"    # end implied

Do you mean if a==b puts "hello" *AND* puts "world" or should you
output "hello" if it's true and "world" no matter what.  That would
put a big load on the parser to figure out the different between the
different line delimiters and how that impacts the code around it.

--Jeremy

On Tue, Oct 7, 2008 at 2:35 PM, Brian Candler <b.candler@pobox.com> 
wrote:
>> especially when I write very small code chunk.  Not knowing what
>    ... same
>
>
> Anyway, this is just an idle thought, as it would break lots of things.
> --
> Posted via http://www.ruby-forum.com/.
>
>



--
http://jeremymcanally.com/
http://entp.com/
http://omgbloglol.com

My books:
http://manning.com/mcanally/
http://humblelittlerubybook.com/ (FREE!)

Jeremy McAnally wrote:
> Then you're introducing a big chunk of parser ambiguity.  For example
> 
>     if a == b then puts "hello"; puts "world"    # end implied
> 
> Do you mean if a==b puts "hello" *AND* puts "world" or should you
> output "hello" if it's true and "world" no matter what.

I meant it would be equivalent to

  if a == b; puts "hello"; puts "world"; end

(I thought I wrote that out in full)

> That would
> put a big load on the parser to figure out the different between the
> different line delimiters and how that impacts the code around it.

If the rules are clearly defined, parsers are easy to write. It's 
certainly much clearer than many of the existing Ruby parsing rules :-)

I have to say bluntly I completely disagree with this.  It's an
example of having learned to use a hammer, requiring all the world to
be a nail.

The concept of 'block' structured languages with block ending is much
more prevalent both in language count and in user count than
indentation with semantic meaning.   For that I know of exactly two
languages, Python and Occam.. where Occam is quite a fringe language
these days (and maybe always was if you weren't programming
transputers, but I'm showing my age).

The most important thing to have, when learning a new language, is the
flexibility to adapt, the rules, conventions and idioms of that
language. The thing that stands most in the way of learning a language
is the stubborn requirement that all languages operate in the same
way.  They don't won't and for good reasons.

Ron.

Hi --

On Thu, 9 Oct 2008, Ron Fox wrote:

> The most important thing to have, when learning a new language, is the 
> flexibility to adapt, the rules, conventions and idioms of that language. The 
> thing that stands most in the way of learning a language is the stubborn 
> requirement that all languages operate in the same way.  They don't won't and 
> for good reasons.

You might find this interesting:

http://www.infoq.com/articles/coming-from-ruby

Another related matter is the recurrent wish for Ruby to become so
flexible, including in its syntax, that it will support any imaginable
programming paradigm and allow redefinition of every operator, literal
constructor, and keyword. That, too, has never made sense to me. For
one thing, and by definition, the world needs only one
pan-paradigmatic, syntax-agnostic language. Once there's one, there's
no need for a second one. So then the question becomes: should Ruby
take on that role? Or, to look at it another way: should the existence
of the pan-paradigmatic language necessitate the death of an existing
language? And if so, should the doomed language be Ruby?

Once you look at it that way, turning Ruby into language soup makes no
sense at all.

Anyway, a slightly different train of thought, but your comments
brought it to mind.


David

David A. Black wrote:
>
> For one thing, and by definition, the world needs only one
> pan-paradigmatic, syntax-agnostic language. Once there's one, there's
> no need for a second one.

One already exists: it's called Lisp.  You've just described Lisp.

> So then the question becomes: should Ruby
> take on that role? Or, to look at it another way: should the existence
> of the pan-paradigmatic language necessitate the death of an existing
> language? And if so, should the doomed language be Ruby?
> 
> Once you look at it that way, turning Ruby into language soup makes no
> sense at all.

Agreed.  Ruby should not turn itself into Lisp!

This begs a question, in my mind.  Has anyone tried to implement Ruby in 
Lisp?  (Though I know there are projects for the converse.)  It would be 
a neat thing to do: generate Lisp code which is the Ruby AST.  You 
automatically get N implementations of Ruby, from the N implementations 
of Lisp.  Choose the best one according to whatever criteria, and use 
that for the first implementation-specific classes such as sockets.

Claims that it would be too slow would need to be backed up with data. 
There is a near endless assortment of optimization techniques which may 
be used.  Given SBCL is faster or slower than Java depending on the 
benchmark, it could potentially be much faster.  The AST can be 
manipulated at run-time, in ways more far-reaching than the myopic 
hotspot algorithms.  Potentially.

David A. Black wrote:

> Once you look at it that way, turning Ruby into language soup makes no
> sense at all.

I read the article, David. I understand what the article tries to say:
"After you've heard Matz discuss how he thinks about these things, all 
the more do you realize that "to make C++ programmers feel more at home" 
just isn't in the ballpark."

My intention of syntax improvement on "END" is more like to make less 
typing and eye catching to find matching code, rather than to make ruby 
feel more like C/C++.

Maybe I didn't make myself clear completely.

I understand as a newbie, Robert and most others suggest me to use ruby 
more to see if I have different feeling about "END". But to make my 
point more explicit, the intention of my original post is rather than a 
syntax suggestion change, but more a support of ruby creator MATS's 
intention and experiment (already made) on alternative syntax of "END". 
Mats's this syntax experiment likely involved other ruby guru's support 
in ruby core team.  They are not newbies like me or just casually jumped 
in this decision, right?

I just additionally brought about some examples of candidates for the 
alternative of keyword "END".  I agreed with Robert that those 
candidates may not be realistic.  Mats has the final decision which I 
will support no matter he decide to change or not, or what the new 
syntax be like.

To make it short, I am on Mats side, who expressed and experimented a 
syntax alternative for "END", while it seems Robert, David and some 
others are on a different side with ruby's creator, Mats.  That's sounds 
a little interesting,  huh? :)   I apologize for my rush on my some 
inappropriate comments/reactions anyway.

On Fri, 10 Oct 2008, Frasier Mruby wrote:

> My intention of syntax improvement on "END" is more like to make less
> typing and eye catching to find matching code, rather than to make ruby
> feel more like C/C++.
>
> Maybe I didn't make myself clear completely.

For better or worse, I had drifted a bit from the original topic (as I
mentioned at the end of my post).

> alternative of keyword "END".  I agreed with Robert that those
> candidates may not be realistic.  Mats has the final decision which I
> will support no matter he decide to change or not, or what the new
> syntax be like.
>
> To make it short, I am on Mats side, who expressed and experimented a
> syntax alternative for "END", while it seems Robert, David and some
> others are on a different side with ruby's creator, Mats.  That's sounds
> a little interesting,  huh? :)

No, not interesting at all. I'm on a different side from Matz on lots
of proposed Ruby changes, and a few that make it in. I think everyone
is; no one just says "Great!" to every single feature of Ruby, and
Matz has never asked or expected us to. Please don't start playing
some kind of loyalty-to-Matz game. I'm sure he's seen this thread and
will take it under advisement.


David

On 09.10.2008 19:03, Frasier Mruby wrote:
> My intention of syntax improvement on "END" is more like to make less 
> typing and eye catching to find matching code, rather than to make ruby 
> feel more like C/C++.

Yet at the same time you make reading Ruby code harder for those used to
the existing syntax.  Plus, if that change became reality there was
potentially a lot of code that needed changing.

> I understand as a newbie, Robert and most others suggest me to use ruby 
> more to see if I have different feeling about "END". But to make my 
> point more explicit, the intention of my original post is rather than a 
> syntax suggestion change, but more a support of ruby creator MATS's 
> intention and experiment (already made) on alternative syntax of "END". 

So you no longer say "let's use Phython style indentation" but rather "I
support experimenting with the syntax of Ruby once in a while to find
out whether we benefit from that change".  That sounds quite different
and I am guessing that we would not have seen this discussion if you
stated it like this in the first place...

> To make it short, I am on Mats side, who expressed and experimented a 
> syntax alternative for "END", while it seems Robert, David and some 
> others are on a different side with ruby's creator, Mats.

I would not be so sure of that.  But even if it were true, what does it
matter?

>  That's sounds a little interesting,  huh? :)

Does it?  What do we learn from that other than that there is
disagreement in the Ruby community about this and that?  I for my part
get the impression that it is important for you to identify groups of
people with common opinions and locate yourself among those groups.

> Robert Klemme wrote:
>> > What about you?  How open is your mind?
> "Open", as my understanding, is allowing others to say something and not 
> forbid them.

I cannot remember having seen someone forbid you voicing your opinions -
it's not possible anyway.  "Open" also means to deal with the world as
it is - this includes programming languages. :-)

> I won't feel bad, impatient,or angry if other people brings 
> up suggestions which I don't agree, and won't use sarcastic tones to 
> reply newbie's messages.

That's a noble attitude.  Unfortunately not everybody adheres to it all
the time - especially in public electronic forums.  I am afraid, you
will have to deal with sarcastic comments - one way or the other. :-)

>   I apologize for my rush on my some 
> inappropriate comments/reactions anyway.

I did not feel offended.  Apology accepted - just in case. ;-)

Cheers

  robert

David A. Black wrote:
> No, not interesting at all. I'm on a different side from Matz on lots
> of proposed Ruby changes, and a few that make it in. I think everyone
> is; no one just says "Great!" to every single feature of Ruby, and
> Matz has never asked or expected us to. 

Understood. The taste of people are not always the same.  Discussions 
are unavoidable in some cases. I trust Matz and ruby core team (probably 
including you) are sensible gurus and can use their best judgements to 
further improve this already lovely language.

Robert Klemme wrote:
> So you no longer say "let's use Phython style indentation" 

I didn't intend to propose to Python style at the beginning. In my first 
post in this thread, I said:
>Posted by Frasier Mruby (fmruby) on 06.10.2008 19:37
>I understand and agree your comment that ruby had better to have 
>something to close the code block. 

My second post:
>James, thank you for you fast response.
>I didn't propose to get rid of the "END" like python does, but wondered 
>if there could be cleaner syntax to as an alternative for "END".

>but rather "I
> support experimenting with the syntax of Ruby once in a while to find
> out whether we benefit from that change".  

Exactly my intention and wish. Maybe the thread is getting too long to 
make people get lost to find out earlier posts.

Unlike many of rubists, I actually can see the value of python 
indentation.  But on the other hand, I have experienced most the 
drawbacks of python indentation as Matz pointed out.  I agree that 
adding something to end the code block is a must-have, especially in 
template webpage.

Have a nice weekend, all.