From: Matthew Kerwin Date: 2014-03-03T11:00:19+10:00 Subject: [ruby-core:61239] Re: [ruby-trunk - Feature #9076] New one-argument block syntax: &. --001a11c12386b5f52a04f3a94f1f Content-Type: text/plain; charset=ISO-8859-1 On 3 March 2014 08:37, wrote: > Issue #9076 has been updated by So Wieso. > > > Matthew Kerwin wrote: > > 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. > > You are totally right, this is yet another use for &. But if you take the > new rule, it is not really confusing, just parse it like explained when you > see & followed by a dot. I think it's pretty confusing, and some of the conversation upthread seems to agree. I don't like having to carefully read and parse code to see if it's & or . or &. -- I'm not a computer, I don't read that way. > 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. > > I agree, X is a no-go. Wouldn't any symbol (in ascii) be possible? (`map > &@.to_s`, or even `map @.to_s`) > It may be possible, but I don't like Perl's sigil-heavy and magic-variable-creating voodoo, and I'd much prefer Ruby to keep it limited to what it already has. I think X is perfectly apt for the gem; there's a very strong convention that 'i' is the index in a loop and 'x' is the item, so having a globally defined X is sensible, it's just a bit too broad of a brush for the core. And @ (and @@) are class scoping sigils, so they're not appropriate here. > > 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. > > I disagree here. The usual one-letter-variables in real code do not show > anything. This implementation would still force us to give them a name if > we want to use them more than once, which is a compromise on a good level. > They show us several things: precisely where the variable comes from (again, I can't stand Perl's $_ just appearing -- or worse, changing -- in random places), precisely where and how it's used, and if it's called "x" it also strongly suggests that it's the item in an iteration that doesn't have an particular meaning outside the context of the iteration (unless we're doing something with coordinates, in which case context should be enough to inform the difference). > > What if we do it like this? > `[1,2,3,4].map{.to_s(2)}.reverse > => ["100", "11", "10", "1"]` > When there is no receiver for a method-call (can only be the first > method-call in a block), send the message to yielded argument. > I think this has been proposed before. You'd have to clearly enumerate edge cases (e.g.: `def each() yield; yield 1, 2; end`), and it still doesn't look great. To summarise my opinion: I agree that there's a lot of value in being able to brain-dump the equivalent of `foo.map{|x|x.to_s(2)}` without having to break your train of thought, but I don't think `&.` is the right way. -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c12386b5f52a04f3a94f1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
= On 3 March 2014 08:37, <sowieso@dukun.de> wrote:
Issue #9076 has been updated by So Wieso.


Matthew Kerwin wrote:
> I share concerns that have been voiced earlier in the thread.
>
> This code snippet: `foo &.bar` *looks* like you're either pass= ing `&.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 tha= t can be #to_proc'd, and `&` isn't an object you can send metho= d calls. What we end up doing is confusing the syntax, adding a third optio= n which looks like a hybrid of the others, but is something else again.

You are totally right, this is yet another use for &. But if you = take the new rule, it is not really confusing, just parse it like explained= when you see & followed by a dot.=A0

I think it's pretty confusing, and some of the conversation up= thread seems to agree. I don't like having to carefully read and parse = code to see if it's & or . or &. -- I'm not a computer, I d= on't read that way.

> I think the ampex gem better captures the intent here by both using th= e `&` sigil/operator to clearly indicate that Proc->block magic is h= appening, 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 tho= se to whom it would be of benefit.

I agree, X is a no-go. Wouldn't any symbol (in ascii) be possible= ? (`map &@.to_s`, or even `map @.to_s`)

=
It may be possible, but I don't like Perl's sigil-heavy and magic-v= ariable-creating voodoo, and I'd much prefer Ruby to keep it limited to= what it already has. I think X is perfectly apt for the gem; there's a= very strong convention that 'i' is the index in a loop and 'x&= #39; is the item, so having a globally defined X is sensible, it's just= a bit too broad of a brush for the core.

And @ (and @@) are class scoping sigils, so the= y're not appropriate here.
=A0
> And if it's too slow for you, write out the full code, even if tha= t means creating a throw-away variable in your block. We like variables, th= ey show us what our code is doing. I doubt it's a goal of the language = to remove them.

I disagree here. The usual one-letter-variables in real code do not s= how anything. This implementation would still force us to give them a name = if we want to use them more than once, which is a compromise on a good leve= l.

They show us several things: prec= isely where the variable comes from (again, I can't stand Perl's $_= just appearing -- or worse, changing -- in random places), precisely where= and how it's used, and if it's called "x" it also strong= ly suggests that it's the item in an iteration that doesn't have an= particular meaning outside the context of the iteration (unless we're = doing something with coordinates, in which case context should be enough to= inform the difference).
=A0

What if we do it like this?
`[1,2,3,4].map{.to_s(2)}.reverse
=3D> ["100", "11", "10", "1"]` When there is no receiver for a method-call (can only be the first method-c= all in a block), send the message to yielded argument.

I think this has been proposed before. You'd have to clearly enumerate = edge cases (e.g.: `def each() yield; yield 1, 2; end`), and it still doesn&= #39;t look great.

To summarise my opinion: I agree that there's a lot = of value in being able to brain-dump the equivalent of `foo.map{|x|x.to_s(2= )}` without having to break your train of thought, but I don't think `&= amp;.` is the right way.

--
=A0 Matthew Kerwin
=A0 = http://matthew.= kerwin.net.au/
--001a11c12386b5f52a04f3a94f1f--