[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...
Issue #14723 has been updated by ko1 (Koichi Sasada).
13 messages
2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
ko1@atdot.net wrote:
[#86791] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:18, Eric Wong wrote:
[#86792] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <ko1@atdot.net> wrote:
[#86793] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:47, Eric Wong wrote:
[#86794] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <ko1@atdot.net> wrote:
[#86814] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
[#86815] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/02
Koichi Sasada <ko1@atdot.net> wrote:
[#86816] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
On 2018/05/02 11:49, Eric Wong wrote:
[#86847] [Ruby trunk Bug#14732] CGI.unescape returns different instance between Ruby 2.3 and 2.4 — me@...
Issue #14732 has been reported by jnchito (Junichi Ito).
3 messages
2018/05/02
[#86860] [Ruby trunk Feature#14723] [WIP] sleepy GC — sam.saffron@...
Issue #14723 has been updated by sam.saffron (Sam Saffron).
6 messages
2018/05/03
[#86862] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/03
sam.saffron@gmail.com wrote:
[#86935] [Ruby trunk Bug#14742] Deadlock when autoloading different constants in the same file from multiple threads — elkenny@...
Issue #14742 has been reported by eugeneius (Eugene Kenny).
5 messages
2018/05/08
[#87030] [Ruby trunk Feature#14757] [PATCH] thread_pthread.c: enable thread caceh by default — normalperson@...
Issue #14757 has been reported by normalperson (Eric Wong).
4 messages
2018/05/15
[#87093] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
3 messages
2018/05/17
[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
9 messages
2018/05/17
[#87096] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/17
ko1@atdot.net wrote:
[#87166] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/18
Eric Wong <normalperson@yhbt.net> wrote:
[#87486] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/06/13
I wrote:
[ruby-core:87134] [Ruby trunk Feature#14390] UnboundMethod#to_proc
From:
zverok.offline@...
Date:
2018-05-17 11:46:20 UTC
List:
ruby-core #87134
Issue #14390 has been updated by zverok (Victor Shepelev).
@shyouhei the point is in gradual enchancing Ruby's approach to functional/declarative chaining.
Let's look at this example:
```ruby
(1..3).each(&method(:print))
(1..3).each { |i| print i }
```
The second, in fact, is _shorter_, but (at least for me) the first somehow feels more "right" even in this case: for example, because it is more DRY (no "define i → immediately use i"); but also, it forces to structure code flow clearly (e.g. instead of hairballs of large blocks chained, I tend to think about code structuring in "processed by this method, then processed by that method").
Now, when the basic usability of `&method(...)` is aknowledged by some, when it would be shortened (I hope), it will be an awesome tool of writing short and clean code.
Also, I believe that some room of optimization is present here, e.g. if some proc "knows" (and, at C level, it knows) it is just a Method, then it can be passed and called with less overflow.
Closer to the topic of current issue:
The baseline is this:
```ruby
map{|i| i.dig(:foo :bar, :baz) }
```
And looking at things like `map(&:size)`, lot of people invent things like:
```ruby
.map(&:dig(:foo, :bar, :baz))
# or
.map(&:dig.(:foo, :bar, :baz))
```
...which is interesting but somehow "spheric in a vacuum": what is this syntax? whose responsibility is to maintain it? How should it be read and parsed?
So, what I am trying to think about, is not the necessary _shorter_ code, but conceptually more clean. If the concepts are there, it can be shortened to a special syntax later (like `&method(:foo)` → `&.:foo` is planned currently).
So, my idea was (I am not sure about it, but I believe that at least introduction of `UnboundMethod#to_proc` would not _harm_ anybody or anything) that
```ruby
map(&Hash.instance_method(:dig).rcurry[:foo :bar, :baz])
```
...is not a _better_ way of doing things, just a way that _can_ be made available, to see what optimization and code style techniques can emerge.
It is somehow "logical" to say that `.map(&:dig.(:foo, :bar, :baz))` is "rendered" as "call instance method with thouse arguments bound to it".
----------------------------------------
Feature #14390: UnboundMethod#to_proc
https://bugs.ruby-lang.org/issues/14390#change-72121
* Author: zverok (Victor Shepelev)
* Status: Feedback
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
I believe that it could be somewhat useful to have UnboundMethod converted to proc (accepting the object to bind to, as a first argument).
Practical(ish) example, paired with [Proc#rcurry](https://bugs.ruby-lang.org/issues/11161) proposal:
```ruby
URLS.
map(&Faraday.method(:get).rcurry[some_get_param: 'value']).
map(&JSON.method(:parse).rcurry[symbolize_names: true]).
map(&Hash.instance_method(:dig).rcurry[:foo :bar, :baz])
```
It is somewhat more verbose than a lot of alternative proposals for "shorthand of &method call with arguments", yet requires no changes in parser or language design. With some future shortcuts/operators for `#method` and `#instance_method` it can even become pretty short and look like an "idiom".
PS: For the reference, shorthand that was proposed and rejected several times (see #6483, #4146):
```ruby
...map(&:dig(:foo :bar, :baz))
```
As it is indeed looks much shorter than my proposal, it raises a lot of question about what is that `:dig(:foo :bar, :baz)` and how it should be parsed and whether it can appear outside of `&`-calls.
--
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>