[#61171] Re: [ruby-changes:33145] normal:r45224 (trunk): gc.c: fix build for testing w/o RGenGC — SASADA Koichi <ko1@...>
(2014/03/01 16:15), normal wrote:
3 messages
2014/03/01
[#61243] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — normalperson@...
Issue #9425 has been updated by Eric Wong.
4 messages
2014/03/03
[#61359] [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs — normalperson@...
Issue #9609 has been reported by Eric Wong.
5 messages
2014/03/07
[#61360] Re: [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs
— SASADA Koichi <ko1@...>
2014/03/07
(2014/03/07 19:09), [email protected] wrote:
[#61362] Re: [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs
— Eric Wong <normalperson@...>
2014/03/07
SASADA Koichi <[email protected]> wrote:
[#61424] [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals — Eric Wong <normalperson@...>
I'm unsure about this. I _hate_ the extra branches this adds;
13 messages
2014/03/12
[#61466] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/13
Hi Eric,
[#61471] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— Eric Wong <normalperson@...>
2014/03/13
SASADA Koichi <[email protected]> wrote:
[#61508] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/15
(2014/03/14 2:12), Eric Wong wrote:
[#61509] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— Eric Wong <normalperson@...>
2014/03/15
SASADA Koichi <[email protected]> wrote:
[#61510] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/15
(2014/03/15 17:34), Eric Wong wrote:
[#61452] [ruby-trunk - Feature #9632] [Open] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been reported by Eric Wong.
3 messages
2014/03/13
[#61496] [ruby-trunk - Feature #9638] [Open] [PATCH] limit IDs to 32-bits on 64-bit systems — normalperson@...
Issue #9638 has been reported by Eric Wong.
4 messages
2014/03/14
[#61568] hash function for global method cache — Eric Wong <normalperson@...>
I came upon this because I noticed existing st numtable worked poorly
7 messages
2014/03/17
[#61605] Re: hash function for global method cache
— SASADA Koichi <ko1@...>
2014/03/20
(2014/03/18 8:03), Eric Wong wrote:
[#61606] Re: hash function for global method cache
— Eric Wong <normalperson@...>
2014/03/20
SASADA Koichi <[email protected]> wrote:
[#61631] Re: hash function for global method cache
— =?KOI8-R?B?4NLJyiDzz8vPzM/X?= <funny.falcon@...>
2014/03/22
what's the profit from using binary tree in place of hash?
[#61632] Re: hash function for global method cache
— Eric Wong <normalperson@...>
2014/03/22
Юрий Соколов <[email protected]> wrote:
[#61687] [ruby-trunk - Bug #9606] Ocassional SIGSEGV inTestException#test_machine_stackoverflow on OpenBSD — normalperson@...
Issue #9606 has been updated by Eric Wong.
3 messages
2014/03/26
[#61760] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been updated by Eric Wong.
3 messages
2014/03/30
[ruby-core:61226] [ruby-trunk - Feature #9076] New one-argument block syntax: &.
From:
matthew@...
Date:
2014-03-02 16:11:33 UTC
List:
ruby-core #61226
Issue #9076 has been updated by Matthew Kerwin.
I share concerns that have been voiced earlier in the thread.
This code snippet: `foo &.bar` *looks* like you're either passing `&.bar` as the first positional parameter to foo, or casting `.bar` to a Proc and passing it as the block parameter. You might argue that that *is* what you're doing, but it's not; `.bar` isn't a thing that can be #to_proc'd, and `&` isn't an object you can send method calls. What we end up doing is confusing the syntax, adding a third option which looks like a hybrid of the others, but is something else again.
I think the ampex gem better captures the intent here by both using the `&` sigil/operator to clearly indicate that Proc->block magic is happening, and by providing an explicit object to receive the method calls. Of course it could never be promoted to core, because the name 'X' is far too valuable and I doubt anyone could come up with a better one, but personally I'm happy enough that the gem exists and can be used by those to whom it would be of benefit.
And if it's too slow for you, write out the full code, even if that means creating a throw-away variable in your block. We like variables, they show us what our code is doing. I doubt it's a goal of the language to remove them.
----------------------------------------
Feature #9076: New one-argument block syntax: &.
https://bugs.ruby-lang.org/issues/9076#change-45574
* Author: Ary Borenszweig
* Status: Feedback
* Priority: Low
* Assignee:
* Category: core
* Target version: Next Major
----------------------------------------
Hello,
I'd like to introduce a new syntax for blocks that have one argument.
Currently you can do this:
[1, 2, 3].map &:to_s
With the proposed syntax this will be written as:
[1, 2, 3].map &.to_s
Instead of ":" we use a ".".
The idea is that this new syntax is just syntax sugar that is expanded by the parser to this:
[1, 2, 3].map { |arg| arg.to_s }
This new syntax allows passing arguments:
[1, 2, 3, 4].map &.to_s(2) #=> ["1", "10", "11", "100"]
It also allows chaining calls:
[1, 10, 100].map &.to_s.length #=> [1, 2, 3]
You can also use another block:
[[1, -2], [-3, -4]].map &.map &.abs #=> [[1, 2], [3, 4]]
Pros:
- Doesn't conflict with any existing syntax, because that now gives a syntax error, so it is available.
- Allows passing arguments and chaining calls
- It's *fast*: it's just syntax sugar. The "&:to_s" is slower because the to_proc method is invoked, you have a cache of procs, etc.
- It looks ok (in my opinion) and allows very nice functional code (like the last example).
Cons:
- Only supports one (implicit) argument. But this is the same limitation of "&:to_s". If you want more than one argument, use the traditional block syntax.
- It's a new syntax, so users need to learn it. But to defend this point, users right now need to understand the &:to_s syntax, which is hard to explain (this calls the "to_proc" method of Symbol, which creates a block... vs. "it's just syntax sugar for")
What do you think?
We are using this syntax in a new language we are doing, Crystal, which has a syntax very similar to Ruby, and so far we think it's nice, simple and powerful. You can read more about it here: http://crystal-lang.org/2013/09/15/to-proc.html
--
http://bugs.ruby-lang.org/