[#103135] [Ruby master Feature#17768] Proposal: Downward assignments — mame@...

Issue #17768 has been reported by mame (Yusuke Endoh).

10 messages 2021/04/01

[#103162] [Ruby master Feature#17773] Alias `Numeric#zero?` and `Float#zero?` as `Numeric#empty?` and `Float#empty?` — sawadatsuyoshi@...

Issue #17773 has been reported by sawa (Tsuyoshi Sawada).

9 messages 2021/04/02

[#103241] [Ruby master Bug#17777] 2.6.7 fails to build on macOS: implicit declaration of function 'rb_native_mutex_destroy' is invalid in C99 — eregontp@...

Issue #17777 has been reported by Eregon (Benoit Daloze).

17 messages 2021/04/05

[#103280] [Ruby master Bug#17781] Resolv::DNS RequestID table allocations are never freed, causing DNS lookups to eventually hang — supermathie@...

Issue #17781 has been reported by supermathie (Michael Brown).

9 messages 2021/04/07

[#103305] [Ruby master Feature#17785] Allow named parameters to be keywords — marcandre-ruby-core@...

Issue #17785 has been reported by marcandre (Marc-Andre Lafortune).

21 messages 2021/04/08

[#103310] [Ruby master Feature#17786] Proposal: new "ends" keyword — jzakiya@...

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

13 messages 2021/04/08

[#103317] [Ruby master Bug#17787] Four AIX build issues with xlc compiler and ruby-3.0.1 — lamont@...

Issue #17787 has been reported by lamont (Lamont Granquist).

9 messages 2021/04/08

[#103342] [Ruby master Feature#17790] Have a way to clear a String without resetting its capacity — jean.boussier@...

Issue #17790 has been reported by byroot (Jean Boussier).

14 messages 2021/04/09

[#103386] [Ruby master Bug#17793] `shorten-64-to-32` error for 32-bit Android due to `struct stat` definition — xtkoba+ruby@...

Issue #17793 has been reported by xtkoba (Tee KOBAYASHI).

8 messages 2021/04/11

[#103400] [Ruby master Feature#17795] `before_fork` and `after_fork` callback API — jean.boussier@...

Issue #17795 has been reported by byroot (Jean Boussier).

42 messages 2021/04/12

[#103434] [Ruby master Bug#17799] Seg fault in rb_class_clear_method_cache — stanhu@...

Issue #17799 has been reported by stanhu (Stan Hu).

14 messages 2021/04/13

[#103481] [Ruby master Feature#17808] Feature Request: JS like splat of Object properties as named method parameters — brad.krane@...

Issue #17808 has been reported by Lithium (Brad Krane).

8 messages 2021/04/16

[#103556] [Ruby master Bug#17820] `Errno::EINVAL` from `Process.kill` with available signal on Windows — alex.wayfer@...

Issue #17820 has been reported by AlexWayfer (Alexander Popov).

9 messages 2021/04/22

[#103591] [Ruby master Bug#17827] Monitor is not fiber safe — samuel@...

Issue #17827 has been reported by ioquatix (Samuel Williams).

11 messages 2021/04/25

[#103593] [Ruby master Misc#17828] Deprecate use of master and slave — yyoshida.at.work@...

Issue #17828 has been reported by yyoshida.at.work@gmail.com (Yasuhiro Yoshida).

10 messages 2021/04/26

[#103596] [Ruby master Feature#17830] Add Integer#previous and Integer#prev — rafasoaresms@...

Issue #17830 has been reported by rafasoares (Rafael Soares).

9 messages 2021/04/26

[#103631] [Ruby master Feature#17837] Add support for Regexp timeouts — sam.saffron@...

Issue #17837 has been reported by sam.saffron (Sam Saffron).

45 messages 2021/04/27

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

From: jzakiya@...
Date: 2021-04-08 20:09:08 UTC
List: ruby-core #103315
Issue #17786 has been updated by jzakiya (Jabari Zakiya).


The process to implement this proposal are actually much simpler than you make it out to be.

This would be perfectly syntactically legal code.

```
A.class_eval do
  define_method :b do
    c do
      d do
        e
  ends

  def c
  end
end
```
It would be expanded to

```
A.class_eval do
  define_method :b do
    c do
      d do
        e
      end
    end
  end

  def c
  end
end
```

So in your code example, starting at the beginning (outer most layer) the parser starts counting how many ``things`` (module|class|method names, loops, conditionals, etc) are currently open (haven’t been resolved as terminated). At some point, it counts the last thing that needs to be resolved. When it encounters the first ``end`` it tries to resolve it with the last (highest count) ``thing`` that’s still open. It then continues backing up the tree count, until all the unresolved ``things`` count is zero.

So now the source code AST is fully resolved, and w|should look just like normal. This is what is then feed to the compiler. But there has to be a way to know how many things need to be terminated and how many are still open.

I would assume for Ruby, the parsing stage is separate from compilation. You have to go through some process to turn raw source code, through whatever number of stages of processing, to format it into runtime code.

So in my mind, all the parser has to do is account for all open ``things``, and start resolving them from the most inner layer ``things`` back out to the outer layers, until every ``thing`` is resolved.

This should be a much simpler|easier process to do than what Python does, because it has whitespace dependencies, whereas Ruby doesn't care. All Ruby would have to do is go down, and back up, the parsing tree.

So in the big picture, you don't have to care much about what the ``thing`` is, you just have to keep track of how many there are, because all you're going to first do is put the source code in equivalent standard format with expanded out ``end`` statements, which can then be processed as usual.

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

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

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread