[#90399] [Ruby trunk Feature#14813] [PATCH] gc.c: make gc_enter+gc_exit pairs dtrace probes, too — ko1@...
Issue #14813 has been updated by ko1 (Koichi Sasada).
3 messages
2018/12/10
[#90417] [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD — naruse@...
Issue #15398 has been reported by naruse (Yui NARUSE).
4 messages
2018/12/11
[#90423] Re: [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD
— Eric Wong <normalperson@...>
2018/12/11
naruse@airemix.jp wrote:
[#90519] Spoofing warnings for mail from bugs.ruby-lang.org — Charles Oliver Nutter <headius@...>
I'm getting a spoofing warning for emails sent from bugs.ruby-lang.org when
4 messages
2018/12/13
[#90522] Re: Spoofing warnings for mail from bugs.ruby-lang.org
— Eric Wong <normalperson@...>
2018/12/13
Charles Oliver Nutter <headius@headius.com> wrote:
[#90533] [Ruby trunk Feature#15413] unmarkable C stack (3rd stack) — normalperson@...
Issue #15413 has been reported by normalperson (Eric Wong).
3 messages
2018/12/14
[#90581] [Ruby trunk Bug#15424] Ruby 2.6.0rc1 & 2.6.0rc2 mutex exception — mat999@...
Issue #15424 has been reported by splitice (Mathew Heard).
3 messages
2018/12/17
[#90595] [Ruby trunk Bug#15430] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been reported by hsbt (Hiroshi SHIBATA).
3 messages
2018/12/18
[#90614] [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been updated by hsbt (Hiroshi SHIBATA).
4 messages
2018/12/19
[#90630] Re: [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI
— Eric Wong <normalperson@...>
2018/12/20
> It still exists. https://rubyci.org/logs/rubyci.s3.amazonaws.com/centos7/ruby-trunk/log/20181218T230003Z.fail.html.gz
[#90820] Re: [ruby-cvs:73697] k0kubun:r66593 (trunk): accept_nonblock_spec.rb: skip spurious failure — Eric Wong <normalperson@...>
k0kubun@ruby-lang.org wrote:
3 messages
2018/12/30
[ruby-core:90590] [Ruby trunk Feature#15301] Symbol#call, returning method bound with arguments
From:
sean.m.huber@...
Date:
2018-12-17 17:16:37 UTC
List:
ruby-core #90590
Issue #15301 has been updated by shuber (Sean Huber).
@zverok wrote:
> I don't believe it is possible at all (both from the technical and organizational points of view).
Ah ok bummer if true! Can you please clarify what you meant by `organizational` above?
Note to future self (or other interested parties) - poke around `compile.c`, `parse.y`, `node.c`, and `node.h` to see what something like this would take.
> If you do, probably you should create another ticket, not turning this one, pretty short and focused on _one particular proposal_ into the "who could invent 10 new syntaxes in one comment" challenge.
Lol just trying to suggest some alternatives since Matz doesn't seem to be into the `Symbol#call` suggestion. I do very much like this shorthand concept of applying arguments to blocks/procs like you're proposing and I hope we get to see some implementation of it. Thank you for your feedback!
----------------------------------------
Feature #15301: Symbol#call, returning method bound with arguments
https://bugs.ruby-lang.org/issues/15301#change-75744
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
In one Reddit discussion I've got stuck with this simple, yet seemingly powerful idea, not sure if it was discussed anytime previously (can't find on the bug tracker, but maybe I am just bad at searching):
```ruby
class Symbol
def call(*args, &block)
proc { |x| x.send(self, *args, &block) }
end
end
[10, 20, 30].map &:modulo.(3) # => [1, 2, 0]
[[1, -2], [-3, -4]].map(&:map.(&:abs)) # => [[1, 2], [3, 4]]
[1, 2, 3, 4].map &:**.(2) # => [1, 4, 9, 16]
```
I understand and respect core team's reluctance for adding new methods to core classes, but from the top of my head I can't invent _incredibly_ bad consequences (there, of course, could be some codebases that defined their own `Symbol#call` in a different way, but I don't estimate the probability as super-high; and the same could be said almost for any new method).
On the other hand, resulting code seems pretty nice, "Rubyish", explainable and mostly unambiguous.
Would like to hear other's opinions.
PS: One obvious objection could be that it is almost a de-facto standard to have any object's `#to_proc` to return proc doing exactly the same what the `#call` does (if the object happen to have both). It is unfortunate, but I believe the people will use to it, considering the possible gains. And, anyway, that's only "de-facto" rule, not the language standard :)
--
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>