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

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Adba4396b604d8943d461b861c4a4345?d=identicon&s=25 Chris Dew (Guest)
on 2007-05-18 09:26
(Received via mailing list)
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.
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2007-05-18 09:38
(Received via mailing list)
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.
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2007-05-18 11:05
(Received via mailing list)
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
3131fcea0a711e5ad89c8d49cc9253b4?d=identicon&s=25 Julian Leviston (Guest)
on 2007-05-18 11:07
(Received via mailing list)
Actually,

Isn't end repeating yourself full stop?

Do we really need it?

Julian.

On Fri, 18 May 2007 16:25:03 +0900
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2007-05-18 11:09
(Received via mailing list)
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
0ac9ec73f8186f7f18f203e3620278d8?d=identicon&s=25 cies (Guest)
on 2007-05-18 12:50
(Received via mailing list)
* 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.
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2007-05-18 12:57
(Received via mailing list)
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...

MWUUAHAHAHA.

-- fxn
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (Guest)
on 2007-05-18 14:31
(Received via mailing list)
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)
Cf6d0868b2b4c69bac3e6f265a32b6a7?d=identicon&s=25 Daniel Martin (Guest)
on 2007-05-18 15:02
(Received via mailing list)
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.
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2007-05-18 15:37
(Received via mailing list)
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.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2007-05-18 16:00
(Received via mailing list)
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
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2007-05-18 16:04
(Received via mailing list)
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
6e68d0d2428a6366d12e91273a1b8788?d=identicon&s=25 S.Volkov (Guest)
on 2007-05-18 16:16
(Received via mailing list)
"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
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2007-05-18 16:26
(Received via mailing list)
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.
5f9c010866ed7b4ceff994510de2ef8c?d=identicon&s=25 Jaroslaw Zabiello (jzabiello)
on 2007-05-18 17:15
(Received via mailing list)
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?
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2007-05-18 17:20
(Received via mailing list)
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.
5f9c010866ed7b4ceff994510de2ef8c?d=identicon&s=25 Jaroslaw Zabiello (jzabiello)
on 2007-05-18 17:22
(Received via mailing list)
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.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-05-18 17:26
(Received via mailing list)
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.
F858265f411ebf3d4dc032ee3247148e?d=identicon&s=25 Filipe Fernandes (Guest)
on 2007-05-18 17:40
(Received via mailing list)
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
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2007-05-18 17:44
(Received via mailing list)
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
B8cfd5ec0f88bf5b5f2eedda7d1a0746?d=identicon&s=25 unknown (Guest)
on 2007-05-18 17:46
(Received via mailing list)
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
5f9c010866ed7b4ceff994510de2ef8c?d=identicon&s=25 Jaroslaw Zabiello (jzabiello)
on 2007-05-18 18:05
(Received via mailing list)
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? :)
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (austin)
on 2007-05-18 18:17
(Received via mailing list)
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
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2007-05-18 18:18
(Received via mailing list)
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.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (austin)
on 2007-05-18 18:20
(Received via mailing list)
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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (austin)
on 2007-05-18 18:22
(Received via mailing list)
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
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2007-05-18 18:26
(Received via mailing list)
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.
B8cfd5ec0f88bf5b5f2eedda7d1a0746?d=identicon&s=25 unknown (Guest)
on 2007-05-18 18:26
(Received via mailing list)
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
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2007-05-18 18:59
(Received via mailing list)
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).
B74f9ac58c7a0b80d877470198e1a472?d=identicon&s=25 gga (Guest)
on 2007-05-18 19:25
(Received via mailing list)
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.
15f985dc1d6a150767736a0c65e9ef35?d=identicon&s=25 Jeremy Henty (Guest)
on 2007-05-18 19:45
(Received via mailing list)
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
A131b672fdbd2a58dce12031ad78b121?d=identicon&s=25 Wolfgang Nádasi-Donner (wonado)
on 2007-05-18 20:13
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
6e68d0d2428a6366d12e91273a1b8788?d=identicon&s=25 S.Volkov (Guest)
on 2007-05-18 20:17
(Received via mailing list)
"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
Dcef09335767135acb26ecfebbc65198?d=identicon&s=25 Enrique Comba Riepenhausen (Guest)
on 2007-05-18 20:20
(Received via mailing list)
> *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
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2007-05-18 20:21
(Received via mailing list)
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.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (austin)
on 2007-05-18 20:51
(Received via mailing list)
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
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2007-05-18 23:18
(Received via mailing list)
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
59cdea7d8f8b9f4fbfa57304bb952c17?d=identicon&s=25 Sven Suska (Guest)
on 2007-05-18 23:23
(Received via mailing list)
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
59cdea7d8f8b9f4fbfa57304bb952c17?d=identicon&s=25 Sven Suska (Guest)
on 2007-05-18 23:26
(Received via mailing list)
Yukihiro Matsumoto schrieb:

>syntax it should be.
>
+1

Sven
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-05-19 00:42
(Received via mailing list)
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.
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2007-05-19 08:39
(Received via mailing list)
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
6e68d0d2428a6366d12e91273a1b8788?d=identicon&s=25 S.Volkov (Guest)
on 2007-05-19 10:31
(Received via mailing list)
"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
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-05-19 13:30
(Received via mailing list)
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.
B74f9ac58c7a0b80d877470198e1a472?d=identicon&s=25 gga (Guest)
on 2007-05-19 13:35
(Received via mailing list)
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).
64654003bb943d13f4ca44546aeee226?d=identicon&s=25 Brendan (Guest)
on 2007-05-19 17:05
(Received via mailing list)
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.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2007-05-19 20:03
(Received via mailing list)
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.
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2007-05-19 20:49
(Received via mailing list)
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.
59cdea7d8f8b9f4fbfa57304bb952c17?d=identicon&s=25 Sven Suska (Guest)
on 2007-05-19 21:46
(Received via mailing list)
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
3094bf04803916300ff86ef6c28c24a1?d=identicon&s=25 rocky.bernstein@gmail.com (Guest)
on 2007-05-20 04:50
(Received via mailing list)
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..)
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2007-05-20 09:46
(Received via mailing list)
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
7b4707f974af261f71943e1f2046c9ee?d=identicon&s=25 SonOfLilit (Guest)
on 2007-05-20 10:12
(Received via mailing list)
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
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 unknown (Guest)
on 2007-05-20 10:26
(Received via mailing list)
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.
A52b0e1c5d982f2512a03c5dbfd033d6?d=identicon&s=25 Dick Davies (Guest)
on 2007-05-20 10:36
(Received via mailing list)
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?
F62d0be4e8209c45a02d4f595014845a?d=identicon&s=25 Peter Marsh (killswitch)
on 2007-05-20 14:02
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
86e33dee4a89a8879a26487051c216a8?d=identicon&s=25 Michael Fellinger (Guest)
on 2007-05-20 14:39
(Received via mailing list)
On 5/20/07, Peter Marsh <evil_grunger@hotmail.com> wrote:
> >
> > T.
>     puts
>
Sorry, but how would you handle block_given? without parameters?
86e33dee4a89a8879a26487051c216a8?d=identicon&s=25 Michael Fellinger (Guest)
on 2007-05-20 14:43
(Received via mailing list)
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?
F62d0be4e8209c45a02d4f595014845a?d=identicon&s=25 Peter Marsh (killswitch)
on 2007-05-20 16:22
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?
A52b0e1c5d982f2512a03c5dbfd033d6?d=identicon&s=25 Dick Davies (Guest)
on 2007-05-20 16:50
(Received via mailing list)
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
86e33dee4a89a8879a26487051c216a8?d=identicon&s=25 Michael Fellinger (Guest)
on 2007-05-20 17:01
(Received via mailing list)
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
:)
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-05-20 17:03
(Received via mailing list)
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.
A84d51d60791f8e0fb6d27a8a8b2a96e?d=identicon&s=25 Neil Wilson (neilw)
on 2007-05-20 18:56
(Received via mailing list)
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.
74886c14aa167f34d39145d75c0b971c?d=identicon&s=25 Mushfeq Khan (Guest)
on 2007-05-20 19:27
(Received via mailing list)
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.
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2007-05-20 20:08
"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 :-) )
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2007-05-20 20:25
(Received via mailing list)
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.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-05-20 20:54
(Received via mailing list)
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.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2007-05-20 21:01
(Received via mailing list)
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.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2007-05-20 21:24
(Received via mailing list)
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.
582aeda5afc64739eeb5bf708f361587?d=identicon&s=25 David Carlton (Guest)
on 2007-05-21 01:35
(Received via mailing list)
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
Dfa9c5c24d16b812ff7e9d8b8b54dc55?d=identicon&s=25 Stian Haklev (houshuang)
on 2007-05-21 04:29
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
B74f9ac58c7a0b80d877470198e1a472?d=identicon&s=25 gga (Guest)
on 2007-05-21 05:51
(Received via mailing list)
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?
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2007-05-21 15:12
(Received via mailing list)
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!
Feee221f9eb7818d90625ea141bfd60c?d=identicon&s=25 bbiker (Guest)
on 2007-05-21 18:36
(Received via mailing list)
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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (austin)
on 2007-05-22 00:22
(Received via mailing list)
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
15a3e0ca3a90c53741c97b351d05ff6f?d=identicon&s=25 Benjamin Kudria (Guest)
on 2007-05-22 16:48
(Received via mailing list)
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
95ece3bc20c5dc43685302703a1e99bd?d=identicon&s=25 Erik Hollensbe (Guest)
on 2007-06-01 08:01
(Received via mailing list)
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.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2007-06-01 22:07
(Received via mailing list)
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/
B7d00e6bd04c81d1fd78554a3d0c38b7?d=identicon&s=25 Keith Fahlgren (Guest)
on 2007-06-01 22:36
(Received via mailing list)
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.htm...


HTH,
Keith
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2007-06-01 23:49
(Received via mailing list)
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.htm...

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/
28d387417e63282250381cd389bd9386?d=identicon&s=25 Jerry Blanco (Guest)
on 2007-06-02 20:22
(Received via mailing list)
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.p...).

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.
1da182c11b22f4674c78cfa22a029a4c?d=identicon&s=25 Jinjing Wang (jinjing)
on 2007-06-16 06:19
I love indentations too..

Check out my project for Ruby space convention :/

http://lazibi.rubyforge.org

It's code generation.
Cf8586cf56fec72eb20a52e6797fea31?d=identicon&s=25 Brad Phelan (Guest)
on 2007-09-25 23:07
(Received via mailing list)
> 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.
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-06 19:37
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
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2008-10-06 20:46
(Received via mailing list)
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
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-06 21:26
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.
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2008-10-06 21:59
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 :-)
134ea397777886d6f0aa992672a50eaa?d=identicon&s=25 Mark Thomas (Guest)
on 2008-10-06 22:40
(Received via mailing list)
> 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.
73ba5e17cf39ee5aa4ada6eefdb80177?d=identicon&s=25 Joe Wölfel (Guest)
on 2008-10-06 22:55
(Received via mailing list)
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/beauti...
73ba5e17cf39ee5aa4ada6eefdb80177?d=identicon&s=25 Joe Wölfel (Guest)
on 2008-10-06 23:13
(Received via mailing list)
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/beauti...
>
Sorry, here's a better link.
http://www.arachnoid.com/ruby/rubyBeautifier.html
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2008-10-06 23:14
(Received via mailing list)
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
6e366eb5a71be2bad7f383d42aeb4788?d=identicon&s=25 Justin Collins (Guest)
on 2008-10-07 00:57
(Received via mailing list)
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
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-07 03:20
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.
F7b23ca97e51ae89341a19548aa63467?d=identicon&s=25 Tom Reilly (Guest)
on 2008-10-07 03:23
(Received via mailing list)
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
Ae16cb4f6d78e485b04ce1e821592ae5?d=identicon&s=25 Martin DeMello (Guest)
on 2008-10-07 03:28
(Received via mailing list)
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
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-07 03:39
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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-10-07 03:53
(Received via mailing list)
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
Bee69cfed999cd13e3bff73d472a39ee?d=identicon&s=25 Hassan Schroeder (Guest)
on 2008-10-07 03:56
(Received via mailing list)
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,
58d1114fe29aab2d433231a722dd2034?d=identicon&s=25 Bilyk, Alex (Guest)
on 2008-10-07 04:13
(Received via mailing list)
+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
D3064ff1f45c83ccb4526275bbd6a918?d=identicon&s=25 Justin Stanczak (Guest)
on 2008-10-07 04:32
(Received via mailing list)
+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.
C40020a47c6b625af6422b5b1302abaf?d=identicon&s=25 Stefano Crocco (crocco)
on 2008-10-07 08:27
(Received via mailing list)
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
6e366eb5a71be2bad7f383d42aeb4788?d=identicon&s=25 Justin Collins (Guest)
on 2008-10-07 09:34
(Received via mailing list)
David A. Black wrote:
>
> David
>

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

-Justin
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2008-10-07 11:17
(Received via mailing list)
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'
D893e113b51a8f200d2abb3ed9e54143?d=identicon&s=25 Gaspard Bucher (gazoduc)
on 2008-10-07 11:53
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-10-07 12:03
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-10-07 12:10
(Received via mailing list)
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
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-07 15:35
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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-10-07 15:54
(Received via mailing list)
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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2008-10-07 17:31
(Received via mailing list)
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
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-07 18:25
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.
0ea7f61aec8fee539be0cf39b7bab77c?d=identicon&s=25 Benoit Daloze (Guest)
on 2008-10-07 18:32
(Received via mailing list)
"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
73ba5e17cf39ee5aa4ada6eefdb80177?d=identicon&s=25 Joe Wölfel (Guest)
on 2008-10-07 20:13
(Received via mailing list)
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.
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2008-10-07 21:27
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.
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2008-10-07 21:37
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.
E0c987f680cd640c14912ebfbf0f0f07?d=identicon&s=25 unknown (Guest)
on 2008-10-08 00:07
(Received via mailing list)
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?
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-08 06:23
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.
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2008-10-08 10:00
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.
Fa4c23dfa1fe9e5671bd89c8539f1522?d=identicon&s=25 Michael Shigorin (Guest)
on 2008-10-08 11:26
(Received via mailing list)
...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! :)
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-08 16:56
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.
6d3c187a8b3ef53b08e3e7e8572c4fea?d=identicon&s=25 Jeremy McAnally (Guest)
on 2008-10-08 17:42
(Received via mailing list)
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!)
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2008-10-08 19:39
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 :-)
F6a834b9e424a1e5b199db450462b6cd?d=identicon&s=25 Ron Fox (Guest)
on 2008-10-09 11:30
(Received via mailing list)
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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-10-09 12:34
(Received via mailing list)
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
Beb77c4602c3cac7a12149431366ed11?d=identicon&s=25 The Higgs bozo (higgsbozo)
on 2008-10-09 18:48
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.
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-09 19:06
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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-10-10 10:53
(Received via mailing list)
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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2008-10-10 11:50
(Received via mailing list)
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
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-11 03:30
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.
B6e154aa1b6afc260abfeec3ebe9c41d?d=identicon&s=25 Frasier Mruby (fmruby)
on 2008-10-11 03:43
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.
8b4cc7a474b3d7dd27487dcbb1a4b41c?d=identicon&s=25 Juha K. (juha_k)
on 2013-07-29 08:39
Why not go coffeescript style and create a preprocessor gem that
compiles indent-aware ruby into ruby? Shouldn't be too big effort.
87e61e351b823e19b4a62a896d2af0d4?d=identicon&s=25 Henry Maddocks (Guest)
on 2013-07-29 09:56
(Received via mailing list)
On 29/07/2013, at 6:39 PM, "Juha K." <lists@ruby-forum.com> wrote:

> Why not go coffeescript style and create a preprocessor gem that
> compiles indent-aware ruby into ruby? Shouldn't be too big effort.
>

Here's one for you...

https://github.com/jamesotron/Rubby

Henry
5a837592409354297424994e8d62f722?d=identicon&s=25 Ryan Davis (Guest)
on 2013-07-29 11:49
(Received via mailing list)
On Jul 28, 2013, at 23:39 , Juha K. <lists@ruby-forum.com> wrote:

> Why not go coffeescript style and create a preprocessor gem that
> compiles indent-aware ruby into ruby? Shouldn't be too big effort.

Perhaps because we'd hate it? Otherwise we'd already be coding in
python.
3853dd5371ac1e094fc45d6c2aa0e459?d=identicon&s=25 Carlo E. Prelz (Guest)
on 2013-07-29 13:41
(Received via mailing list)
Subject: Re: Why not adopt "Python Style" indentation for Ruby?
  Date: lun 29 lug 13 06:48:50 +0900

Quoting Ryan Davis (ryand-ruby@zenspider.com):

> > Why not go coffeescript style and create a preprocessor gem that
> > compiles indent-aware ruby into ruby? Shouldn't be too big effort.
>
> Perhaps because we'd hate it? Otherwise we'd already be coding in python.

+1

Carlo

PS I do not hate it, but I find it highly impractical...
4a8632084a26acb9c096afd674ad773d?d=identicon&s=25 Darryl Pierce (mcpierce)
on 2013-07-29 16:20
(Received via mailing list)
On Mon, Jul 29, 2013 at 03:39:02PM +0900, Juha K. wrote:
> Why not go coffeescript style and create a preprocessor gem that
> compiles indent-aware ruby into ruby? Shouldn't be too big effort.

To what advantage?
359432c3997195e0107cbad2811c6c35?d=identicon&s=25 Admin Tensor (tensor)
on 2013-07-29 16:55
Darryl Pierce wrote in post #1117018:
> On Mon, Jul 29, 2013 at 03:39:02PM +0900, Juha K. wrote:
>> Why not go coffeescript style and create a preprocessor gem that
>> compiles indent-aware ruby into ruby? Shouldn't be too big effort.
>
> To what advantage?

Well, the most obvious are less typing and very compact code.  We can
also think about Groovy and Java, and to different extent, Dart and
JavaScript.

Bill
F555402e879ef6ad937e41bbaedb465b?d=identicon&s=25 Brandon W. (brandon_w)
on 2013-07-29 17:21
(Received via mailing list)
If you want python style indents and python this and python that, then
pray
tell, why aren't you just using Python? Quit trying to program Ruby like
it's Python and you'll be a lot better off.

Code is plenty short when you learn anonymous functions, Blocks, Procs,
and
Lambdas. The more lisp you learn the faster that will become apparent.
Ruby
has the strength of some functional programming, and pushing that under
the
rug is a tragedy.

That being said it can be extended to do such things but it's completely
unnecessary if not borderline esoteric. Program Ruby like it's Ruby.
3267149ce23fb4f3757ea23abc635b82?d=identicon&s=25 Farhan Tanvir (Guest)
on 2013-07-29 17:34
(Received via mailing list)
proper indentation is good, but forcing indentation is really a stupid
idea, at least from Ruby point of view.
4a8632084a26acb9c096afd674ad773d?d=identicon&s=25 Darryl Pierce (mcpierce)
on 2013-07-29 17:36
(Received via mailing list)
On Mon, Jul 29, 2013 at 11:55:05PM +0900, Admin Tensor wrote:
> Darryl Pierce wrote in post #1117018:
> > On Mon, Jul 29, 2013 at 03:39:02PM +0900, Juha K. wrote:
> >> Why not go coffeescript style and create a preprocessor gem that
> >> compiles indent-aware ruby into ruby? Shouldn't be too big effort.
> >
> > To what advantage?
>
> Well, the most obvious are less typing and very compact code.

How does additional indentation rather than using braces make for less
typing or more compact code? It would seem to me to be the opposite,
using spaces to define a code block makes for longer source files. I'm
talking about the code that *I* write, as opposed to the code that's
generated by some code processor.

> We can
> also think about Groovy and Java, and to different extent, Dart and
> JavaScript.

Can you explain this part to me, please?
15000f55138ae94b0f362ed7c625461a?d=identicon&s=25 unknown (Guest)
on 2013-07-29 17:39
(Received via mailing list)
Am 29.07.2013 16:55, schrieb Admin Tensor:
> Darryl Pierce wrote in post #1117018:
>> On Mon, Jul 29, 2013 at 03:39:02PM +0900, Juha K. wrote:
>>> Why not go coffeescript style and create a preprocessor gem that
>>> compiles indent-aware ruby into ruby? Shouldn't be too big effort.
>>
>> To what advantage?

> Well, the most obvious are less typing and very compact code.

Actually, readability is more important to me. And "more compact"
doesn't necessarily mean "more readable". Also, I could easily
reduce typing effort by using one-letter variable names, but I don't.

> We can
> also think about Groovy and Java, and to different extent, Dart and
> JavaScript.

Those languages add much more, compared to simply replacing do...end
by indentation.

Regards,
Marcus
E61acb90c5de3adf117e41f10b699b0f?d=identicon&s=25 Richard Wilson (Guest)
on 2013-07-29 18:55
(Received via mailing list)
Traditional Ruby requires more writing? I don't think so. A large
portion
of text editors (Vim, ST2, TM) automatically plop an end every time you
type a def, begin, do, etc. So in terms of efficiency I don't see the
point. That and missing/improper indents could possibly break your code,
meaning that if you had a way of making it more readable, that consisted
of
adjusting the indentation, it could break your code.

I like python, a lot, it's just not ruby, and ruby is why I sleep well
at
night.


On Mon, Jul 29, 2013 at 8:39 AM, <sto.mar@web.de> wrote:

> Actually, readability is more important to me. And "more compact"
> Regards,
> Marcus
>
>
> --
> GitHub: https://github.com/stomar/
> PGP:    0x6B3A101A
>
>


--
*Richard Wilson*
Sechelt Innovations
Cell - (604) 842 5318
Skype - r.crawfordwilson
Email - r.crawfordwilson@gmail.com

*This email may contain confidential and/or privileged information. If
you
are not the intended recipient or have received this email in error,
please
notify the sender immediately and destroy this email. Any unauthorized
copying, disclosure or distribution of the information contained on this
email is prohibited.*
359432c3997195e0107cbad2811c6c35?d=identicon&s=25 Admin Tensor (tensor)
on 2013-07-29 21:24
Darryl Pierce wrote in post #1117038:
> How does additional indentation rather than using braces make for less
> typing or more compact code? It would seem to me to be the opposite,
> using spaces to define a code block makes for longer source files. I'm
> talking about the code that *I* write, as opposed to the code that's
> generated by some code processor.

Well, have you used haml before?  It is the same thing; instead of
writing all the HTML tags, you used some convention, and the convention
is based on indentation besides other things.  I think the proponents of
indentation (and the removal of "end" keyword) want a different way to
input the code, but the end result is the same.  Just like haml code
will be transformed to HTML code, the proponents want to be able to
write

  if condition
    exec1
    exec2
  exec3

and it will be transformed to

  if condition
    exec1
    exec2
  end
  exec3

Of course, the original syntax is still there, and a person can choose
which method to input the code, probably with different file suffix if
the end keyword is to be made optional.  I proposed this in 2002 and I
created for myself a simple translator.

>> We can
>> also think about Groovy and Java, and to different extent, Dart and
>> JavaScript.
>
> Can you explain this part to me, please?

Groovy and Java are fundamentally the same, because all Groovy code will
be compiled to JVM.  But in Groovy a lot of things are optional, such
as declaration of variables, so the code is more concise.  Similarly,
all Dart code will be translated to JavaScript code.  You can just
Google Groovy and Dart to get more information.

Best regards,

Bill
3df767279ce7d81db0a5bb30f5136863?d=identicon&s=25 Matthew Kerwin (mattyk)
on 2013-07-30 01:49
Ryan Davis wrote in post #1117005:
> On Jul 28, 2013, at 23:39 , Juha K. <lists@ruby-forum.com> wrote:
>
>> Why not go coffeescript style and create a preprocessor gem that
>> compiles indent-aware ruby into ruby? Shouldn't be too big effort.
>
> Perhaps because we'd hate it? Otherwise we'd already be coding in
> python.

Just so everyone's aware, Juha K. didn't just spring this suggestion out
of the blue.  The thread to which *e's replying dates back to 2007.

Have a browse through it some time, it's pretty interesting.
<https://www.ruby-forum.com/topic/108457>
A74a68807619459925cc1d8e1045c7bd?d=identicon&s=25 Tony Arcieri (Guest)
on 2013-07-30 03:25
(Received via mailing list)
There's something very important to understand about "Python style"
indentation: Python's approach is a subset of possible indent-sensitive
grammars. It's also incompatible with Ruby.

Before anything else, I'll say this: Haskell-style indent sensitivity
could
work with Ruby. So it's not that Ruby is incompatible with indent
sensitivity. It's just the way Python implements it that's incompatible
with Ruby.

Python's indent blocks are all *statements* (i.e. they don't return a
value). This means that you cannot embed anything indent sensitive
inside
any *expression* (which does return a value) This makes it impossible to
e.g. put an if statement inside of a Python lambda, since you can't
embed
statements inside expressions.

Ruby is a pure expression based language which doesn't have statements.
Because of this, Pythonic indent sensitivity simply won't work, since
it's
intractably tied to statements.

Again, to fix this, we'd need to use Haskell-style indent sensitivity.
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2013-11-30 11:38
What I dislike about indent is that you need to satisfy the parser in
order to make the program run.

It's like an additional control element, like ';'.

I do not think a language should care about indentation.

With that having said, I concur with the initial statement - "end" does
not give me, as a programmer, meaningful information. I only have to use
it to satisfy the ruby parser - in python, you can omit that, but you
(a) must then indent properly (which is, again, to satisfy the parser)
and (b) you have to use the strange ':', which is annoying.

What I would love to have, however, would be a per-file option that
would allow me to omit end for a given .rb file. Just like shebang or
encoding lines could be used.

I could then write specific classes in a single .rb file (one class per
file) and they would be more readable too.
9a45896e48a382fe5c656b8873e0dfcb?d=identicon&s=25 Stu (Guest)
on 2013-11-30 19:13
(Received via mailing list)
It's interesting the terminators in ruby which are end, }, ||, && are
all
basic syntax sugar for semi colon ;

The colon in python reveals that it's actually a syntax tree where the
colon probably saves the interpreter a single pass.

Both Ruby and Python have different philosophies. Pythonists enjoy the
concept of "one way" style which probably makes it easier to study other
programmers code simply because it looks the same as yours where
Rubyists
enjoy the various programming styles which lack such restriction i.e. it
can look like anything which opens up many contexts which can be useful.

OP if you like the concept of restriction within ruby you are correct it
wouldn't be difficult to make simply because it won't stop you from
doing
so but it may be difficult in getting your idea adopted simply because,
as
I mentioned, ruby programmers enjoy having a programmable programming
language over just a general purpose one.

FWIW I helped a friend once with a simple hack to allow them to write
python with 2 spaces. Also nothing more than a small quick one-line hack
to
make it work.
This topic is locked and can not be replied to.