Implicit local variables for do...end blocks

ruby-talk
1

In the thread “Should this work?”, I proposed that :collect should be able
to operate without an explicit block parameter. For example:

[“john”, “mary”].map { |name| name.capitalize }
CAN BE EXPRESSED AS
[“john”, “mary”].map { $_.capitalize } # -> [“john”, “mary”]

[1, 2, 3, 4].map { |i| i ** 2 } # -> [1, 4, 9, 16]
CAN BE EXPRESSED AS
[1, 2, 3, 4].map { $_ ** 2 } # -> [1, 4, 9, 16]

Guy Decoux pointed out that the blocks are independent of the method calling
them, so the above could only be done by allowing implicit assignment of the
local variable $_ in every “do … end” block.

Is this agreeable?

I would usually continue to name my parameters explicitly, just to make it
clear what’s being operated on (useful in a dynaically typed language!).
However, the motivation for my proposal is very simple cases like the
following:

input = ARGV.map { |s| s.to_i }

And, of course, this whole discussion was prompted by such constructs as:

[x, y, z].each { |arr| arr << nil }
[x, z, z].map { |arr| arr == [nil] }

The above three examples would be more concisely written as:

input = ARGV.map { $_.to_i }

[x, y, z].each { $_ << nil }

[x, y, z].map { $_ == [nil] }

Whether this terseness is useful is for discussion.

Cheers,
Gavin

···

–
Gavin Sinclair Software Engineer
Sydney, Australia Soyabean Software Pty Ltd

2

   [x, y, z].map { $_ == [nil] }

Well, you have in the ToDo

   * discourage use of symbol variable (e.g. $/, etc.) in manual
   * discourage use of Perlish features by giving warnings.

Seems not really compatible, for me

Guy Decoux

3

you know, if your going to do this, then just go all the away and spare
us further confusions. i.e the earlier example with capitalize makes
more sense to me than this perlishness. :slight_smile:

[“john”, “mary”].map { capitalize }

this would thus represent the simple deafulting to a single parameter
and the receiverless mehtods acting on that deafult parameter. although
i suspect there may be some issues with the self default here.

anyhow, that’s my opinion. please no more perls.

~transami

···

On Sun, 2002-08-04 at 09:20, Gavin Sinclair wrote:

In the thread “Should this work?”, I proposed that :collect should be able
to operate without an explicit block parameter. For example:

[“john”, “mary”].map { |name| name.capitalize }
CAN BE EXPRESSED AS
[“john”, “mary”].map { $_.capitalize } # → [“john”, “mary”]

[1, 2, 3, 4].map { |i| i ** 2 } # → [1, 4, 9, 16]
CAN BE EXPRESSED AS
[1, 2, 3, 4].map { $_ ** 2 } # → [1, 4, 9, 16]

Guy Decoux pointed out that the blocks are independent of the method calling
them, so the above could only be done by allowing implicit assignment of the
local variable $_ in every “do … end” block.

Is this agreeable?

I would usually continue to name my parameters explicitly, just to make it
clear what’s being operated on (useful in a dynaically typed language!).
However, the motivation for my proposal is very simple cases like the
following:

input = ARGV.map { |s| s.to_i }

And, of course, this whole discussion was prompted by such constructs as:

[x, y, z].each { |arr| arr << nil }
[x, z, z].map { |arr| arr == [nil] }

The above three examples would be more concisely written as:

input = ARGV.map { $_.to_i }

[x, y, z].each { $_ << nil }

[x, y, z].map { $_ == [nil] }

Whether this terseness is useful is for discussion.

Cheers,
Gavin

–
Gavin Sinclair Software Engineer
Sydney, Australia Soyabean Software Pty Ltd

–
~transami

4

Hmmmm… fair point. I rarely use Perlish features in Ruby; this just
seems a useful shortcut (I really like Ruby’s terseness without sacrificing
clarity). In particular, “array.map { |e| e.to_i }” just seems too verbose
for what it does.

Anyway, I can see how such a shortcut could lead to unreadable code when
people neglect to name complex parameters.

I also note the RCR David referred to in a related post.

–Gavin

···

----- Original Message -----
From: “ts” decoux@moulon.inra.fr

[x, y, z].map { $_ == [nil] }

Well, you have in the ToDo

  • discourage use of symbol variable (e.g. $/, etc.) in manual
  • discourage use of Perlish features by giving warnings.

Seems not really compatible, for me