[#37730] [Ruby 1.9 - Bug #4962][Open] come back gem_prelude! — Yusuke Endoh <mame@...>

24 messages 2011/07/02

[#37840] [Ruby 1.9 - Feature #4985][Open] Add %S[] support for making a list of symbols — Aaron Patterson <aaron@...>

23 messages 2011/07/07

[#37866] [Backport87 - Feature #4996][Open] About 1.8.7 EOL — Shyouhei Urabe <shyouhei@...>

22 messages 2011/07/08

[#37913] [Ruby 1.9 - Bug #5003][Open] Enumerator#next segfaults in OS X Lion (10.7) — Ganesh Gunasegaran <ganesh.gunas@...>

16 messages 2011/07/09

[#37917] [Ruby 1.9 - Feature #5005][Open] Provide convenient access to original methods — Lazaridis Ilias <ilias@...>

13 messages 2011/07/09

[#37932] [Ruby 1.9 - Feature #5008][Open] Equal rights for Hash (like Array, String, Integer, Float) — Suraj Kurapati <sunaku@...>

31 messages 2011/07/09

[#37936] [Ruby 1.9 - Feature #5010][Open] Add Slop(-like) in stdlib and deprecate current OptionParser API — Rodrigo Rosenfeld Rosas <rr.rosas@...>

29 messages 2011/07/09

[#37968] [Ruby 1.9 - Bug #5015][Open] method_added" is called in addition to "method_undefined — Lazaridis Ilias <ilias@...>

14 messages 2011/07/10

[#38096] [Ruby 1.9 - Feature #5033][Open] PATCH: 1.9: gc_mark_children: Avoid gc_mark() tail recursion, use goto again. — Kurt Stephens <ks.ruby@...>

14 messages 2011/07/16

[#38109] [Ruby 1.9 - Bug #5034][Open] C Source Code formatting — Lazaridis Ilias <ilias@...>

18 messages 2011/07/16

[#38171] [Ruby 1.9 - Bug #5047][Open] Segfault (most likely involving require) — Jack Christensen <jack@...>

21 messages 2011/07/18

[#38182] [Ruby 1.9 - Feature #5054][Open] Compress a sequence of ends — ANDO Yasushi ANDO <andyjpn@...>

68 messages 2011/07/19

[#38197] [Ruby 1.9 - Feature #5056][Open] About 1.9 EOL — Shyouhei Urabe <shyouhei@...>

39 messages 2011/07/19
[#38900] [Ruby 1.9 - Feature #5056] About 1.9 EOL — Shota Fukumori <sorah@...> 2011/08/10

[#38902] Re: [Ruby 1.9 - Feature #5056] About 1.9 EOL — Yukihiro Matsumoto <matz@...> 2011/08/10

Hi,

[#39048] Re: [Ruby 1.9 - Feature #5056] About 1.9 EOL — SASADA Koichi <ko1@...> 2011/08/22

Hi,

[#39055] Re: [Ruby 1.9 - Feature #5056] About 1.9 EOL — Lucas Nussbaum <lucas@...> 2011/08/23

On 23/08/11 at 06:50 +0900, SASADA Koichi wrote:

[#38295] [Ruby 1.9 - Feature #5064][Open] HTTP user-agent class — Eric Hodel <drbrain@...7.net>

15 messages 2011/07/21

[#38391] [Ruby 1.9 - Bug #5076][Open] Mac OS X Lion Support — Yui NARUSE <naruse@...>

17 messages 2011/07/22

[#38503] [Ruby 1.9 - Feature #5096][Open] offer Logger-compatibility for ext — Eric Wong <normalperson@...>

16 messages 2011/07/25

[#38510] [Ruby 1.9 - Feature #5097][Assigned] Supported platforms of Ruby 1.9.3 — Yui NARUSE <naruse@...>

42 messages 2011/07/26

[#38526] [Backport92 - Backport #5099][Open] Backport r31875 load path performance problem — Aaron Patterson <aaron@...>

19 messages 2011/07/26

[#38538] [Ruby 1.9 - Feature #5101][Open] allow optional timeout for TCPSocket.new — Eric Wong <normalperson@...>

15 messages 2011/07/27

[#38610] [Ruby 1.9 - Feature #5120][Open] String#split needs to be logical — Alexey Muranov <muranov@...>

18 messages 2011/07/30

[#38623] [Ruby 1.9 - Feature #5123][Open] Alias Hash 1.9 as OrderedHash — Alexey Muranov <muranov@...>

14 messages 2011/07/31

[ruby-core:38255] [Ruby 1.9 - Feature #5054] Compress a sequence of ends

From: Ralph Corderoy <redmine@...>
Date: 2011-07-20 11:41:19 UTC
List: ruby-core #38255
Issue #5054 has been updated by Ralph Corderoy.


Yasushi ANDO wrote:
> Ralph Corderoy wrote:
> > My suggestion is to introduce end{if,while,def,...} as keywords;
>
> Really great idea, but I'd like to avoid 'endif endif endif.' How
> about introducing ennnndif?

"endif endif endif" would be uncommon.  Normally a single "endwhile" or
whatever wrapped the nested if-statements would suffice.  When it
couldn't, an extra begin...endbegin could be used.

    # Current syntax.
    while a
        if b then
            c()
            if d then
                e()
                    if f then
                        g()
                        h() while i
                    end
                end
            end
        end
    end

    # Those "end"s can be replaced with a single endwhile.
    while a
        if b then
            c()
            if d then
                e()
                    if f then
                        g()
                        h() while i
    endwhile

    # Current syntax, more awkward example;  j() added.
    while a
        if b then
            c()
            if d then
                e()
                    if f then
                        g()
                        h() while i
                    end
                end
            end
            j()
        end
    end

    # Introducing a begin...end avoids the need for multiple "endif"s.
    while a
        if b then
            c()
            begin
                if d then
                    e()
                        if f then
                            g()
                            h() while i
            endbegin
            j()
    endwhile

"ennnndif" is poor because it makes the human count, and we're
inconsistent at that;  it would cause more bugs to be introduced.
Especially a sequence of characters all the same, but "en5d" isn't much
better because I'm now having to count outwards five blocks.  Make the
computer count;  they're good at it!  :-)

Kurt Stephens wrote:
>     module MyModule
>       class MyClass
>         def my_method
>           10.times do
>             if rand < 0.5
>               p :small
>             end; end; end; end; end
>
> it is similar to this common style:
>
>     (define (foo arg)
>       (if foo
>         (cons foo 'that)))

I agree the "end"s on the same line works, though I'd probably align
with the outermost block being closed, i.e. "module".  But when it's
used in Lisp you'll find programmers tap away at ")" with the editor
showing the matching "(" until they've entered enough.  They don't
particularly count how many to enter.

With the current style, I don't have to count the "end"s either.
There's one per line and I just keep outdenting until I'm in alignment
with the opening while/do/etc.  But having to enter them on one line
means I'm back to counting again, I feel.  I could do the old style and
then join all the lines with ";" but that's a bit long-winded.  :-)

If Ruby had labels, e.g. to allow "break" to break out of more than one
block, then we could label the start of the block and have an "endlabel
A" syntax to avoid all the in between "end"s, but it doesn't.
begin...endbegin suffices most of the time.

So, it seems my key point for a solution is it mustn't require the
programmer to count because he'll get it wrong some of the time and
readers won't bother to check most of the time.  So a means of pairing
up the opening of the block and the end is required.  The type of block
is often unique enough to suffice, e.g. the reader readily confirms the
"endwhile" matches the "while" with which it's aligned and there are no
"while"s started within.

----------------------------------------
Feature #5054: Compress a sequence of ends
http://redmine.ruby-lang.org/issues/5054

Author: Yasushi ANDO
Status: Assigned
Priority: Normal
Assignee: Yasushi ANDO
Category: Joke
Target version: 


Though as matz said at rubykaigi2011 ruby is a quite good language, many people hate a long sequence of `end' like this:

module MyModule
  class MyClass
    def my_method
      10.times do
        if rand < 0.5 
          p :small
        end 
      end 
    end 
  end 
end

So, I'd like to propose introducing a special keyword, en(n+)d. Using this keyword, we can rewrite the above example like this:

module MyModule
  class MyClass
    def my_method
      10.times do
        if rand < 0.5 
          p :small
        ennnnnd 

I know matz's already rejected a python-style block. He wrote:

> it works badly with
>   * tab/space mixture
>   * templates, e.g. eRuby
>   * expression with code chunk, e.g lambdas and blocks
http://www.ruby-forum.com/topic/108457

These bad things won't occur by introducing en(n+)d.

Some implementations already exists.

JRuby
- https://gist.github.com/1088363

CRuby
- http://www.atdot.net/sp/raw/kn9iol
- http://d.hatena.ne.jp/ku-ma-me/20110718/p1

Thanks for your consideration.


-- 
http://redmine.ruby-lang.org

In This Thread