Introducing the "it" keyword

[Ola Bini]

Hi,

At Fri, 25 May 2007 12:55:09 +0900,
Greg Fodor wrote in [ruby-talk:252899]:

But this would be cool:

my_strings.map { pluralize it }.filter { it =~ /tests/ }.each { p it }

p *my_strings.mappluralize).grep(/tests/)

p *my_strings.map(&luralize).grep(/tests/)

works better. =)

--
Ola Bini (http://ola-bini.blogspot.com)
JvYAML, RbYAML, JRuby and Jatha contributor
System Developer, Karolinska Institutet (http://www.ki.se)
OLogix Consulting (http://www.ologix.com)

"Yields falsehood when quined" yields falsehood when quined.

 

[Brad Phelan]

A common pattern seen in a lot of ruby code is:

g(m(x)) if/unless/while/until h(m(x))

for example,

puts "User: #{opts[:user]}" if opts[:user]
in this case, g(x) = puts "User: #{x}", h(x) = x, and m(x) =
opts[:user]

or

return v+1 if v +1 < 10
In this case, g(x) = x, h(x) = x < 10, and m(x) = v + 1

This is obviously suboptimal code, as is, because it results in the
evaluation of m(x) twice. I propose a new keyword is added, "it",
which may appear within the statement to the left of the decorator.
So, the previous statements become:

puts "User: #{it}" if opts[:user]

and

return it if |v + 1| < 10

Hasn't 'it' effectively been reserved as a keyword by the RSpec team

# bowling_spec.rb
require 'bowling'

describe Bowling do
beforeeach) do
@bowling = Bowling.new
end

it "should score 0 for gutter game" do
20.times { @bowling.hit(0) }
@bowling.score.should == 0
end
end

 

[Ronald Fischer]

This is obviously suboptimal code, as is, because it results in the
evaluation of m(x) twice. I propose a new keyword is added, "it",
which may appear within the statement to the left of the decorator.
So, the previous statements become:
=20
puts "User: #{it}" if opts[:user]
=20
and
=20
return it if |v + 1| < 10

IMO, this is a special case of the more general idea that within a
certain
piece of code, the value of an expression needs to be refered to more
offen.

Looking at how others do this, the functional programming / Scheme
people
usually handle it with a 'let' construct:

let v =3D opts[:user] in=20
puts "User: #{v}" if v

Of course this has the disadvantage that we *have* to invent a new name
(v).
But assuming that such a substition is only done locally, we could as
well
use placeholders. 'it' would be such a placeholder, kind of:

let opts[:user] in puts "User: #{it}" if it

but this would restrict us to have only one binding at any time. A more
general
solution could be like this:

let a+b+c in
let foo=3Dd*e in
let x/y in
puts ($1+foo)*($1-$2)-$2/($1-foo)

Here, $1 would be bound to x/y (innermost unnamed let binding), $2 would
be bound
to a+b+c (second innermost unnamed let binding). This is similar to the
binding of
parameters in the DeBrujin Lambda calculus, if my rusty memory is right
(any FP
people here who can comment on this?).

Of course it does not mean that the notation $n is really good here (as
it is
already taken by a different usage), but one could equally well think of
other
ways to denote this, such as _1 or \1 or whatever it is seen practical.

Ronald
--=20
Ronald Fischer <[email protected]>
Phone: +49-89-452133-162
=20

 

[Robert Klemme]

No need for it to be such a special built-in construct.
Maybe you could do it like this:

def it(*args)
$it = args unless args.empty?
return *$it
end
puts it if it(v+1) < 10


Daniel

Not thread safe.

robert

 

[Robert Klemme]

A common pattern seen in a lot of ruby code is:

g(m(x)) if/unless/while/until h(m(x))

for example,

puts "User: #{opts[:user]}" if opts[:user]
in this case, g(x) = puts "User: #{x}", h(x) = x, and m(x) =
opts[:user]

or

return v+1 if v +1 < 10
In this case, g(x) = x, h(x) = x < 10, and m(x) = v + 1

This is obviously suboptimal code, as is, because it results in the
evaluation of m(x) twice. I propose a new keyword is added, "it",
which may appear within the statement to the left of the decorator.
So, the previous statements become:

puts "User: #{it}" if opts[:user]

and

return it if |v + 1| < 10

If and only if "it" is seen on the left hand side, the ruby
interpreter should store the expression result on the conditional into
a temporary storage and evaluate that as "it". It falls out of scope
after the statement. The use of pipes can designate a subexpression to
use for "it" instead (I don't have my heart set on pipes, but you get
the idea.)

This keyword allows better DRY in ruby for this g(m(x)) op h(m(x))
pattern and also provides a nice optimization since your average lazy
programmer will usually evaluate m(x) twice instead of putting it into
temporary local storage themselves. By promoting it to a keyword, you
also prevent the problems seen here: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/166828

Thoughts?

I don't understand why you want to change the language where you can
easily do

it = v+1
return it if it < 10

This is efficient and very readable. I consider variants like

return it if (it = v+1) < 10

as degenerate because the nested assignment does neither improve
readability nor efficiency nor is it semantically necessary. (The only
places where an assignment in a conditional can make code significantly
simpler and less redundant are loops.)

And don't tell me that this is too much typing for you.

Regards

robert

 

[Greg Fodor]

$_ releases after the method.
Ah. This works today:

return $_ if $_ = opts[:user]

But it's still hard to read

And don't forget:

$_ = "foo"
puts $_ if ($_ = "bob" && chomp)

will print "foo"! (I feel like I'm back writing Perl again)

p *my_strings.mappluralize).grep(/tests/)

Ah, yes, my ruby-fu is lacking, but it was a contrived
example Here's another contrived one.. the gist is
that you may need to use "it" more than just as a passthrough:

my_strings.map { it.substring(it.maxlen) }.filter { it.size > 5 }.each
{ p "#{it}: #{it.size}" }

def it
@it = block_given? ? yield : @it
end

p it if it{ 'bar' }

Neat. Instance variable could leak, but still neat!

And Re: Rspec, well, if the powers that be (not me) like 'it',
then I guess they'll have to move out of the way

 

[Greg Fodor]

And don't tell me that this is too much typing for you.
Well, it is kinda, but that's not as bad as the fact that
'it' will be un Gc-able till the end of the block unless
we do:

it = v+1
return it if it < 10
it = nil

It's reminiscent of the all too common ruby memory 'leak':
(http://whytheluckystiff.net/articles/theFullyUpturnedBin.html)

x = [1, 2, 3]
loop do
# add some crap to x and use it
end

slow_method_that_doesnt_use_x()

This problem is even trickier w/ closures grabbing x into their
binding too AFAIK. "it" needs to show "it"self to the door
when "it"'s no longer wanted. (It's late)

 

[Robert Klemme]

And don't tell me that this is too much typing for you.

Well, it is kinda, but that's not as bad as the fact that
'it' will be un Gc-able till the end of the block unless
we do:

it = v+1
return it if it < 10
it = nil

It's reminiscent of the all too common ruby memory 'leak':
(http://whytheluckystiff.net/articles/theFullyUpturnedBin.html)

x = [1, 2, 3]
loop do
# add some crap to x and use it
end

slow_method_that_doesnt_use_x()

This problem is even trickier w/ closures grabbing x into their
binding too AFAIK. "it" needs to show "it"self to the door
when "it"'s no longer wanted. (It's late)

I see your point. I do wonder though how relevant this is in practice.
If you write 100+ lines methods then you have other problems than a
few objects that are kept around longer than needed. Even with short
methods that exhibit the behavior you described above it is only an
issue if the object kept around keeps a lot of memory from being
reclaimed (which is not the case for the example above) or if the method
is active multiple times. After all the cost of changing the language
should be smaller than the cost incurred by this missing feature.

Kind regards

robert

 

[Chad Perrin]

return v + 1 if its < 10

I'm not really clear on how that's any better than this:

return v + 1 if v < 10

In fact, I think the "its" version is a bit more ambiguous, and thus
probably worse. Am I missing something?

 

[Chad Perrin]

puts "User: #{opts[:user]}" if opts[:user]

I'm a little groggy, and about to go to bed, so I'm long on vague ideas
and short on specifics -- but can't that be done with something like
this bit of pseudocode?:

opts[:user].something do {|v| make stuff happen}

 

[Jenda Krynicky]

puts "User: #{it}" if (it=opts[:user]).

AFAIK this doesn't work because it will be assumed to
be a method call. That's the crux of the linked post
above.

That's what you get for not using a sigil. You never know what's a
method call and what's a local variable. Especially since you can't
declare variables in Ruby.

Jenda

 

[Jenda Krynicky]

$_ releases after the method.

Ah. This works today:

return $_ if $_ = opts[:user]

But it's still hard to read

At least in one case I know what's the variable here. For $_ that is,
opts might be anything.

And don't forget:

$_ = "foo"
puts $_ if ($_ = "bob" && chomp)

will print "foo"!

Which has nothing to do with $_ or chomp using $_ behind the scenes.
It's a problem with operator precedence.

It works as if you've written

$_ = "foo"
puts $_ if ($_ = ("bob" && chomp))

Which means you could get the same confusion if you tried

x = 'foo'
puts x if (x = 'bob' && 1 > 0)

Though there's a chance that the "true" you get in this case would
suggest better what's the problem.

(I feel like I'm back writing Perl again)

I wish I was.

And actually talking about Perl and $_, the way you'd "remember a
subexpression to use it several times" would be

for (<the expression goes here>) {
return $_ if $_ > 45 and f($_) and whatever( 'with', $_)
}

the difference from

$_ = <the expression goes here>);
return $_ if $_ > 45 and f($_) and whatever( 'with', $_)

being that the for(){} localizes the change of $_. That is, $_ only gets
the new value within the "loop". Which is something the proposed "it"
would have to provide as well.

Jenda

 

[Jenda Krynicky]

I'm not really clear on how that's any better than this:

return v + 1 if v < 10

In fact, I think the "its" version is a bit more ambiguous, and thus
probably worse. Am I missing something?

Yep, the fact that he wanted to be able to shorten something like

return f(x, y) + 47*Pi/y if f(x, y) + 47*Pi/y > 0

and make sure the expression is only evaluated once. Though I do think
at least in Ruby the most sensible solution is

tmp = f(x, y) + 47*Pi/y
return tmp if tmp > 0

Jenda

 

[Yossef Mendelssohn]

Greg Fodor wrote:

Hasn't 'it' effectively been reserved as a keyword by the RSpec team

# bowling_spec.rb
require 'bowling'

describe Bowling do
beforeeach) do
@bowling = Bowling.new
end

it "should score 0 for gutter game" do
20.times { @bowling.hit(0) }
@bowling.score.should == 0
end
end

When I first heard about the change from context/specify to describe/
it, I thought it was completely bone-headed. A quick glance at an
example changed my mind, but I still don't feel good about 'it'.
Considering the number of specifications that will start with
'should', why not use --- oh I don't know, 'should'?


describe Bowling do
beforeeach) do
@bowling = Bowling.new
end

should "score 0 for gutter game" do
20.times { @bowling.hit(0) }
@bowling.score.should == 0
end
end

 

[Sebastian Hungerecker]

but here are a few other ideas:

puts it if (x + y) * (it = (a - b)) < 10

This one already works. No changes to ruby needed.

 

[Trans]

Wow. Yes! Only issue I see is nested blocks though.
(Which it is "it?" ) Spose it could through a warning if 'it'
comes into scope twice.

But this would be cool:

my_strings.map { pluralize it }.filter { it =~ /tests/ }.each { p it }

The less silly variable names we have to come up with, the better!

I would say that it would always belong to the current block. If you
need "it" from the parent block it's easy enough to assign a variable
to it.

However, I wasn't intending that 'it' reference the block arguments,
but the iteration itself, with useful methods about the state of
iteration, eg. it.first?, it.last?, it.even?, it.odd?, it.index. Of
course this could also include it.value.

T.

 

[Greg Fodor]

$_ = "foo"

Which has nothing to do with $_ or chomp using $_ behind the scenes.
It's a problem with operator precedence.

I disagree. Using 'it' here would avoid worries about side-effects.

Anyway, I thought ruby was moving away from these implicit magic $*
variables? Using pipes, the assignment to it would be explicit and
safe from side effects.

for (<the expression goes here>) {
return $_ if $_ > 45 and f($_) and whatever( 'with', $_)
}

the difference from

$_ = <the expression goes here>);
return $_ if $_ > 45 and f($_) and whatever( 'with', $_)

being that the for(){} localizes the change of $_.

Right, this is kinda sorta the pattern I am trying to kill
with "it", except it is less verbose. In addition, you still
have side effects on $_ as above, you'd generally have to
grab $_ into a local (with a name) if you were going to use
methods that *could* change it.

This one already works. No changes to ruby needed.

NameError: undefined local variable or method `x' for main:Object

One thing to mention. Coming up with examples that come close
to the semantics of 'it' (without exact semantics) is missing
the point. If these other solutions were optimal people would
be using them already, but as far as I've seen lots of ruby
code has the pattern implemented lazily.

There are really two genuine criticisms to 'it' I can see
based upon this thread:

- The syntax is too confusing
- It is not worth polluting the language over, despite its utility

Upon reflection, unless I am mistaken, there *is* something close
with correct semantics, a la the references to 'let' and
'for' in Scheme and Perl. It seems kind of odd nobody has given
this one before, since it is pretty simple and I feel dumb for
not mentioning it until now.

def with(x)
yield x
end

with (v + 1) { |it| return it if it < 5 }

Personally, I think this is the closest we can get in Ruby, and
can serve as a concrete starting point for what we gain by
introducing a keyword. Based upon this 'it' now officially
gains sugar and performance, since this above example can match
the same semantics and side effects.

Why it is good sugar:
- Less code. The value for 'it' moves much closer to its usage.

- Less explicit naming. If 'it' becomes the default name for the
block parameter and also is set during end of line conditionals,
ruby code will be less polluted with throwaway user variable names.
(This is a pet peeve of mine, why do I have to keep saying x,y,z
and my co-worker says a,b,c? If we just use 'it', its consistent.)

- It will result in ruby idioms that are clean and correct. If the
above example works go great, why aren't people using it? Probably
because it's a lot of extra typing for perceived little gain, even
though it is the most 'correct' implementation. I feel like this
common pattern should be supported in the most terse form possible.

Why it is good for performance:
- We save a full block invocation and binding opposed to the above,
I think. I don't know enough about the interpreter to be sure of
this, though.

Also, even if 'it' was just added as the default first name, you
could get:

def with (x); yield x; end;

with (v + 1) { puts it if it < 5 }

This might be a good compromise!

 

[Gregory Seidman]

This is obviously suboptimal code, as is, because it results in the
evaluation of m(x) twice. I propose a new keyword is added, "it",
which may appear within the statement to the left of the decorator.
So, the previous statements become:

puts "User: #{it}" if opts[:user]

and

return it if |v + 1| < 10

IMO, this is a special case of the more general idea that within a
certain piece of code, the value of an expression needs to be refered to
more offen.

Looking at how others do this, the functional programming / Scheme people
usually handle it with a 'let' construct:

let v = opts[:user] in
puts "User: #{v}" if v

Of course this has the disadvantage that we *have* to invent a new name
(v). But assuming that such a substition is only done locally, we could
as well use placeholders. 'it' would be such a placeholder, kind of:

let opts[:user] in puts "User: #{it}" if it

but this would restrict us to have only one binding at any time. A more
general solution could be like this:

let a+b+c in
let foo=d*e in
let x/y in
puts ($1+foo)*($1-$2)-$2/($1-foo)

Here, $1 would be bound to x/y (innermost unnamed let binding), $2 would
be bound to a+b+c (second innermost unnamed let binding). This is similar
to the binding of parameters in the DeBrujin Lambda calculus, if my rusty
memory is right (any FP people here who can comment on this?).

[...]

You're working too hard:

def let(*args)
yield *args
end

def use_let(a,b,c)
let a+b+c do |it|
return it if it < 10
end
end

use_let(1,2,3) # 6
use_let(4,5,6) # nil

No need for additional keywords or even global variables, just a little
method named let.

Ronald

--Greg

 

[Robert Dober]

You're working too hard: So are you.

def let(*args)
yield *args
end

def use_let(a,b,c)
let a+b+c do |it|
return it if it < 10
end
end

use_let(1,2,3) # 6
use_let(4,5,6) # nil

returning nil would not be what OP wanted right?
What is wrong with what already works?

return sum if (sum = 1 + 2 + 3) < 10

This has been pointed out already in this thread.


Cheers
Robert

 

[Greg Fodor]

This has been pointed out already in this thread.
This has also been pointed out as *not* working Unless
sum is previously defined it will not, and if it is, it will
hold sum too long.

I also realized this case sucks:
puts it if true || |my_string|

Either it doesn't get defined or ruby has to bind it pipes
higher than ||. I consider these both somewhat borked.

I still want that 'it' default first name though!

let 1+2+3 { puts it if it < 4 }

Nice.