[#99856] [Ruby master Feature#17143] Improve support for warning categories — merch-redmine@...

Issue #17143 has been reported by jeremyevans0 (Jeremy Evans).

16 messages 2020/09/03

[#99868] [Ruby master Bug#17144] Tempfile.open { ... } does not unlink the file — eregontp@...

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

15 messages 2020/09/03

[#99885] [Ruby master Feature#17145] Ractor-aware `Object#deep_freeze` — marcandre-ruby-core@...

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

32 messages 2020/09/03

[#99903] [Ruby master Bug#17146] Queue operations are allowed after it is frozen — eregontp@...

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

16 messages 2020/09/03

[#100016] [Ruby master Feature#17171] Why is the visibility of constants not affected by `private`? — marcandre-ruby-core@...

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

10 messages 2020/09/15

[#100024] [Ruby master Bug#17175] Ruby 2.5: OpenSSL related test failures — jaruga@...

Issue #17175 has been reported by jaruga (Jun Aruga).

10 messages 2020/09/16

[#100025] [Ruby master Feature#17176] GC.enable_autocompact / GC.disable_autocompact — tenderlove@...

Issue #17176 has been reported by tenderlovemaking (Aaron Patterson).

11 messages 2020/09/16

[#100099] [Ruby master Bug#17184] No stdlib function to perform simple string replacement — sheerun@...

Issue #17184 has been reported by sheerun (Adam Stankiewicz).

18 messages 2020/09/24

[#100192] [Ruby master Bug#17197] Some Hash methods still have arity 2 instead of 1 — marcandre-ruby-core@...

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

14 messages 2020/09/28

[#100200] [Ruby master Misc#17199] id outputed by inspect and to_s output does not allow to find actual object_id and vice-versa — baptiste.courtois@...

Issue #17199 has been reported by Annih (Baptiste Courtois).

7 messages 2020/09/28

[#100206] [Ruby master Misc#17200] DevelopersMeeting20201026Japan — mame@...

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

18 messages 2020/09/28

[#100239] [Ruby master Feature#17206] Introduce new Regexp option to avoid MatchData allocation — fatkodima123@...

Issue #17206 has been reported by fatkodima (Dima Fatko).

8 messages 2020/09/30

[ruby-core:99880] [Ruby master Feature#17016] Enumerable#scan_left

From: finch.parker@...
Date: 2020-09-03 14:57:18 UTC
List: ruby-core #99880
Issue #17016 has been updated by parker (Parker Finch).


Dan0042 (Daniel DeLorme) wrote in #note-33:
> ... what about `#cumulative` ? 

Oh that's interesting! I had leapt straight to verbs since that tends to be the pattern for methods that transform enumerables, but the examples of `[1,2,3].cumulative.some_other_method` are compelling and make sense in a "it returns a cumulative enumerator" way.

I don't think it fits quite as well when a block is passed though; `[1,2,3].cumulative(0, &:+)` doesn't read as naturally to me as the imperative `#accumulate`.

I think either option is good -- although since there's a pattern of enumerable methods being named imperatively (e.g. `#map`, `#select`, `#inject`, `#drop`) I still slightly lean toward the `#accumulate` option.


----------------------------------------
Feature #17016: Enumerable#scan_left
https://bugs.ruby-lang.org/issues/17016#change-87407

* Author: parker (Parker Finch)
* Status: Open
* Priority: Normal
----------------------------------------
## Proposal

Add a `#scan_left` method to `Enumerable`.

(The name "scan_left" is based on Scala's scanLeft and Haskell's scanl. It seems like "scan_left" would be a ruby-ish name for  this concept, but I'm curious if there are other thoughts on naming here!)

## Background

`#scan_left` is similar to `#inject`, but it accumulates the partial results that are computed. As a comparison:
```
[1, 2, 3].inject(0, &:+) => 6
[1, 2, 3].scan_left(0, &:+) => [0, 1, 3, 6]
```

Notably, the `scan_left` operation can be done lazily since it doesn't require processing the entire collection before computing a value.

I recently described `#scan_left`, and its relationship to `#inject`, more thoroughly in [this blog post](https://medium.com/building-panorama-education/scan-left-a-lazy-incremental-alternative-to-inject-f6e946f74c00).

## Reasoning
We heavily rely on the scan operation. We use an [event-sourcing](https://martinfowler.com/eaaDev/EventSourcing.html) pattern, which means that we are scanning over individual "events" and building up the corresponding state. We rely on the history of states and need to do this lazily (we stream events because they cannot fit in memory). Thus the scan operation is much more applicable than the inject operation.

We suspect that there are many applications that could leverage the scan operation. [This question](https://stackoverflow.com/questions/1475808/cumulative-array-sum-in-ruby) would be more easily answered by `#scan_left`. It is a natural fit for any application that needs to store the incrementally-computed values of an `#inject`, and a requirement for an application that needs to use `#inject` while maintaining laziness.

## Implementation
There is a Ruby implementation of this functionality [here](https://github.com/panorama-ed/scan_left/) and an implementation in C [here](https://github.com/ruby/ruby/pull/3078).

## Counterarguments
Introducing a new public method is committing to maintenance going forward and expands the size of the Ruby codebase -- it should not be done lightly. I think that providing the functionality here is worth the tradeoff, but I understand any hesitation to add yet more to Ruby!

---Files--------------------------------
scan_left_example.rb (2.93 KB)


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