ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: jzakiya@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:103374] [Ruby master Feature#17786] Proposal: new "ends" keyword
Date: Sat, 10 Apr 2021 15:43:04 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-91467.20210410154304.11075@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-17786.20210408163810.11075@ruby-lang.org

Issue #17786 has been updated by jzakiya (Jabari Zakiya).


The examples I provided show the intent of what its use is for, which is to provide one termination point for a string of consecutive ``end`` statements, and nothing more.

Python|Nim show they can do this, using whitespace|indentation. This makes code much more concise, easier to read|write, and easier to understand. Those string of ``end``s are merely for the benefit of the parser, and not humans.

Please focus on the intent and purpose, and not semantics.

Also, there are no backwards incompatibility issues because there are no issues with parsing old code, just as there are no backwards incompatibilities with ``endless methods``. If a programmer doesn't write code to use it, there is no issue going forward, or backward. Obviously, if one wants code to run on pre 3.0 systems, one doesn't use ``endless methods``, but old code will run on 3.0. This feature would create the same options for programmers to assess using, or not.

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

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

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

```ruby
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 written as:

```ruby
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/

  parent reply	other threads:[~2021-04-10 15:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-08 16:38 [ruby-core:103310] [Ruby master Feature#17786] Proposal: new "ends" keyword jzakiya
2021-04-08 16:55 ` [ruby-core:103311] " chris
2021-04-08 17:03 ` [ruby-core:103313] " merch-redmine
2021-04-08 20:09 ` [ruby-core:103315] " jzakiya
2021-04-08 21:43 ` [ruby-core:103318] " marcandre-ruby-core
2021-04-08 23:36 ` [ruby-core:103324] " duerst
2021-04-09  2:43 ` [ruby-core:103328] " mame
2021-04-09  3:52 ` [ruby-core:103330] " shevegen
2021-04-09  6:25 ` [ruby-core:103333] " duerst
2021-04-09  7:12 ` [ruby-core:103334] " nobu
2021-04-10 15:43 ` jzakiya [this message]
2021-04-10 15:55 ` [ruby-core:103375] " chris
2021-04-11  1:40 ` [ruby-core:103383] " duerst

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-91467.20210410154304.11075@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).