From: finch.parker@... Date: 2020-07-30T19:16:49+00:00 Subject: [ruby-core:99404] [Ruby master Feature#17016] Enumerable#scan_left Issue #17016 has been updated by parker (Parker Finch). I'd like to sum up where we're at with this discussion. Let me know if you disagree with my interpretation here! 1. There is some support for the idea of adding this method. 2. We should avoid changing the behavior of `#inject` on lazy enumerables, since it would be confusing for the lazy version of a method to have different behavior than the strict version. 3. There is concern around the name of this method. Possibilities that have been discussed are: * `#scan`: This name is not very intuitive for the operation and also has other meanings. However, it is used in many other programming languages. * `#accumulate`: This would have my vote at the moment. It suggests that something is accumulated throughout the iteration of the collection. However, it is still a very generic term. * `#reflect`, `#project`, `#interject`: These end in `-ect` as many Ruby/Smalltalk methods on collections do. However, they have little meaning related to the operation at hand. I agree that it would be good to show the duality between `#inject` and this operation, but I'm concerned about using an unrelated word. I think the next steps here are to get confirmation from @matz as to whether or not he thinks this would be a good method to add to Ruby (I described some use cases in #note-18) and to decide on a name. Does that make sense? ---------------------------------------- Feature #17016: Enumerable#scan_left https://bugs.ruby-lang.org/issues/17016#change-86852 * 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: