[ruby-core:103330] [Ruby master Feature#17786] Proposal: new "ends" keyword

[shevegen@gmail.com]

Issue #17786 has been updated by shevegen (Robert A. Heiler).


When I read the proposal I had to think about the "ennnnnd" proposal. :)

That one was linked in above:

https://bugs.ruby-lang.org/issues/5054

It's hard to say how serious people are, but I think "ennnnnnnd" was a joke,
while this here is probably not a joke.

The reason I think this suggestion is not a joke is because I can actually understand
SOME of the rationale behind it. Perhaps mame had a similar idea when he suggested
"endless method definition" - after all you can now omit some syntax, and since mame
is a known golfer, I am sure there is some golf-synergy too :P (although the suggestion
was cleverly made on a first april without being an april joke, so a hidden double
joke that was no joke!).

I also wanted a way to be able to omit "end", so from that point of view I can understand
jzakiya's basic idea behind the proposal.

The reason why I think being able to omit "end" may be useful (sometimes) is actually
somewhat similar as to what jzakiya wrote; he wrote this specifically:

**"The end statements themselves are merely for syntactic purposes."**

And, indeed, although I would not use the same description as he did, I can understand
what he means. Perhaps I can explain it with another example.

To me, personally, the "end" is not giving me a lot of **new information** .

Take a typical module and class definition:

    module Foo
      class Bar
        def hello_world
        end
      end
    end

I think most people may use a style like the above. So, if you look at it then perhaps
the first "end" is somewhat useful ... closes the method. But the second end is not so
much useful to you probably, as a writer of ruby code. You essentially only "close"
class Bar, although if you'd reach the end of the file, well ... that file is closed
already. So you kind of have to do an additional syntax cue. :P

And the very last "end" is actually quite annoying, even more so than the second one.
Because we don't really, in that example at least, use the toplevel module "namespace"
much at all. We just use it to make it easier to integrate code written by other
people too, for the most part - like define our "namespace", such as "module Foobar",
where the other classes and files reside.

When you write a lot of ruby code, this can indeed be tedious. And in some ways it
distracts a bit as well, especially in larger projects where there is a LOT of
nesting, LOTS of classes and lots of files.

My old idea was, however had, a bit different. Rather than this being a default
variant (to omit "end"), I thought whether it may be beneficial to define this on 
a per .rb basis instead. So, per file.

A bit like frozen strings, say in the toplevel comment, where we say "ruby, I will 
use mandatory indent now for this file, and omit all end as a consequence. You figure
out where the ends are or should be, based on that mandatory indent information".

Like a bit a "lazy-mode" AST-like handling of the code, where we as writers of ruby
code could simple omit "end".

A bit like how python works, with the mandatory indent or mandatory whitespace 
rather ... (although python also uses a ":" for method definitions and I never
fully  understood why it needed BOTH indent-information, and the ":" too ...
when I then also have to pass "self" explicit in python, I am quite annoying,
since ruby has the better way to handle the syntax here really, in my opinion)

Unfortunately, while it may be great to be able to omit "end", this most likely
creates a few new problems, trivial ones too, like ...

If you copy/paste ruby code, then you have to sort of figure that out, when other
people can not just copy/paste it as-is, since the "end" would be missing. Any
example on github where different syntax styles are allowed, may then either work
or not work - even more so when you want to integrate code into an existing code
base, and when there is lots of that code.

And, I was also never certain whether my idea in regards to being able to omit "end"
would be any good really (because  I myself really don't know ... I only have that
idea when I write a LOT of "end". When I use only a few "end"s, I don't quite
care about indent as much anymore :P )

Personally I think it may not really be worthwhile to implement the suggestion by
jzakiya. It may also create problems for newcomers, since they then may have to
understand when to use "end", and when not to use it. As much as "end" may not
be fun, it is at the least simple.

Note that "endall" is, from a syntax point of view, uglier than "end". The joke 
suggestion "ennnnnnd" has a similar problem. And nobody counts the "n", that
was clearly a joke. It takes me longer to count the "n" than the "end"s ... :P

I don't think "endall" is a joke ... but syntax-wise I think it's not good
either.

So my personal opinion is rather against that proposal, even though I think the rationale
is not completely without merit - "end" does not add as much useful information IMO.

One last comment:

I actually tend to use this style a lot:

    def foo(array)
      array.each {|entry|
      }
    end

So, I actually deliberately use the {} there, as a visual cue. I guess nobody else
does this really, since most prefer do/end in general, which I can understand. But
I liked it as visual cue simply.

----------------------------------------
Feature #17786: Proposal: new  "ends" keyword
https://bugs.ruby-lang.org/issues/17786#change-91421

* Author: jzakiya (Jabari Zakiya)
* Status: Open
* Priority: Normal
----------------------------------------
I'm submitting this in the same spirit that ``endless methods`` was, to promote and produce more concise and easier to write|read code.

**Proposal**
This is a proposal to introduce a new keyword ``ends`` (or ``endall``) as a terminal point to resolve the end of nested ``loops|conditionals``.

**Why**
It's a common code occurrence to have multiple levels of loops and/or conditionals, which require separate ``end`` keywords to designate their
termination points. The ``end`` statements themselves are merely for syntactic purposes.

It would be a benefit to programmers, and code readers, to be able to produce|read more concise code, by reducing the ``code noise`` of these
nested multiple ``end`` keywords with a shorter|cleaner syntax.

Thus, I propose creating the keyword ``ends`` as a shorter|cleaner syntax to replace having to write multiple ``end`` keywords.

**Example**

Below is an example of real code which performs nested loops. With "standard`` format it looks like this.

```
def render(scene, image, screenWidth, screenHeight)
  screenHeight.times do |y|
    screenWidth.times do |x|
      color = self.traceRay(....)
      r, g, b = Color.toDrawingColor(color)
      image.set(x, y, StumpyCore::RGBA.from_rgb(r, g, b))
    end 
  end 
end
```

However, from the point of view of the parser, these are all legal|equivalent.

```
def render(scene, image, screenWidth, screenHeight)
  screenHeight.times do |y|
    screenWidth.times do |x|
      color = self.traceRay(....)
      r, g, b = Color.toDrawingColor(color)
      image.set(x, y, StumpyCore::RGBA.from_rgb(r, g, b))
    end     end         end     end end end
  end         end       end
end             end     end
```

This proposal would allow this type of code to be writtn as:

```
def render(scene, image, screenWidth, screenHeight)
  screenHeight.times do |y|
    screenWidth.times do |x|
      color = self.traceRay(....)
      r, g, b = Color.toDrawingColor(color)
      image.set(x, y, StumpyCore::RGBA.from_rgb(r, g, b))
ends
```
**Pros**
1) code conciseness
2) better readability
3) no whitespace dependencies
4) no conflict with legacy code
5) attractice to people coming from Python|Nim, et al

**Cons**
No technical implementation restrictions I can think of.
Maybe alternative name (endall)?

Thanks for consideration.




-- 
https://bugs.ruby-lang.org/