«

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...by-talk/166828

Thoughts?

Hi --

On Fri, 25 May 2007, Greg Fodor wrote:

> 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...by-talk/166828
>
> Thoughts?

I think something like 99% of all suggestions for changes to Ruby
involve new punctuation -- which means that only a very tiny number of
them can be accepted before Ruby turns into complete line noise. So
I'd not advocate the pipes version. Maybe you could do:

return v + 1 if its < 10

which of course is missing an apostrophe, speaking of punctuation
But something like that, maybe.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

On 5/24/07, <> wrote:
> Hi --
>
> On Fri, 25 May 2007, Greg Fodor wrote:
>
> > 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...by-talk/166828
> >
> > Thoughts?
>
> I think something like 99% of all suggestions for changes to Ruby
> involve new punctuation -- which means that only a very tiny number of
> them can be accepted before Ruby turns into complete line noise. So
> I'd not advocate the pipes version. Maybe you could do:
>
> return v + 1 if its < 10
>
> which of course is missing an apostrophe, speaking of punctuation
> But something like that, maybe.
>

Well, you fixed the thing that was bothering me. In the original
proposal, 'it' appeared too early, leaving me wonder what 'it' was.
It makes sense for 'it' to follow what 'it' is referring to.

You could solve the apostrophe problem with the longer 'it_is'.

Overall, I like the idea. It solves the lazy programmer problem which
leads to double evaluation of the same expression Those who take the
effort to assign it to a temp variable, can now be lazy, and do it
with one line.

> David
>
> --
> Q. What is THE Ruby book for Rails developers?
> A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
> (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
> Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
> A. Ruby Power and Light, LLC (http://www.rubypal.com)
>
>


--
Bill Guindon (aka aGorilla)
The best answer to most questions is "it depends".

Greg Fodor wrote:
> return it if |v + 1| < 10

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

> Maybe you could do:
>
> return v + 1 if its < 10
>
> -- snip
>
> return v + 1 if < 10

Unfortunately this seems much more difficult and ambiguous
for a number of reasons. First, it is impossible to know
that our implied "it" should be "v + 1" without making
assumptions about the intent. (Why don't we include the
result of the return expression itself? What if it's more
complex?)

More importantly, semantics of order of evaluation become
confusing. Despite v + 1 being evaluated during the
if conditional, it syntactically appears in the return
statement. My approach preserves all current ruby semantics
and is more intentional, I feel. It basically transforms
this:

tmp = m(x)
h(tmp) if g(tmp)

into just

h(it) if g(it = m(x))

The it keyword is essential for one reason and nice for
a few others. It is essential because of the ruby semantics
for determining identifiers vs. methods, referenced in my
original post.

It is nice because we no longer have to come up with the
name "tmp,"ruby provides a consistent intentional name.
It is also nice because it is less code. It is also nice
because it provides correct scope semantics so it will be
GCed at the optimal time.

> No need for it to be such a special built-in construct.

Depends on what you mean by "need." For an optimal solution,
I feel it does. "Optimal" means:

- It only evaluates m(x) once (yours does this)
- It is the most terse representation of intent (subjective)
- It introduces the correct scope (yours does not)
- It releases memory upon GC after the statement (yours doesn't)
- It avoids side effects (yours changes global space)

Its hard to think of a solution to this implemented in ruby
that fits these parameters without introducing a new
language level construct.

Greg Fodor wrote:
>> Maybe you could do:
>>
>> return v + 1 if its < 10
>>
>> -- snip
>>
>> return v + 1 if < 10
>
> Unfortunately this seems much more difficult and ambiguous
> for a number of reasons. First, it is impossible to know
> that our implied "it" should be "v + 1" without making
> assumptions about the intent. (Why don't we include the
> result of the return expression itself? What if it's more
> complex?)
>
> More importantly, semantics of order of evaluation become
> confusing. Despite v + 1 being evaluated during the
> if conditional, it syntactically appears in the return
> statement. My approach preserves all current ruby semantics
> and is more intentional, I feel. It basically transforms
> this:
>
> tmp = m(x)
> h(tmp) if g(tmp)
>
> into just
>
> h(it) if g(it = m(x))
>
> The it keyword is essential for one reason and nice for
> a few others. It is essential because of the ruby semantics
> for determining identifiers vs. methods, referenced in my
> original post.
>
> It is nice because we no longer have to come up with the
> name "tmp,"ruby provides a consistent intentional name.
> It is also nice because it is less code. It is also nice
> because it provides correct scope semantics so it will be
> GCed at the optimal time.
>
>> No need for it to be such a special built-in construct.
>
> Depends on what you mean by "need." For an optimal solution,
> I feel it does. "Optimal" means:
>
> - It only evaluates m(x) once (yours does this)
> - It is the most terse representation of intent (subjective)
> - It introduces the correct scope (yours does not)
> - It releases memory upon GC after the statement (yours doesn't)
> - It avoids side effects (yours changes global space)
>
> Its hard to think of a solution to this implemented in ruby
> that fits these parameters without introducing a new
> language level construct.
>

How about something like: return $1 if (v + 1) < 10 if you wanted to
return v + 1? If you wanted to return v you could use: return $2 if
((v) +1) < 10. Improvements would be using some of the regular
expression flags to control what $1, $2, etc. refer to.

> How about something like: return $1 if (v + 1) < 10 if you wanted to
> return v + 1? If you wanted to return v you could use: return $2 if
> ((v) +1) < 10. Improvements would be using some of the regular
> expression flags to control what $1, $2, etc. refer to.
I like this better than def it() since it seems more intentional,
but it too results in side effects into global space and prevents
GCing early.

Another problem is that you run into problems mixing the
meaning of parenthesis, since within a given expression in your
example you may not want to set aside storage space for all
parenthesized expressions, despite the fact you may need to enforce
order of operations.

For example:

puts $2 if (x + y) * (a - b) < 10

will copy the result of x + y in RAM even if your parentheses are
there to simply make the add happen first. Having it be something
new in this context like pipes separates concerns and avoids these
technical consequences.

FYI, this would be:

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

We just get temp storage for a - b and preserve a single meaning
of parentheses.

Actually, this example:

puts $2 if (x + y) * (a - b) < 10

Could avoid storing (x + y) by analyzing the AST
of the puts expression, noting that $1 does not appear.
Recall a similar optimization happens with the proposed it
keyword if it is not used on the left hand side.

So, that point about RAM I made above is partially wrong,
except for the fact that analyzing the AST for the presence
of a keyword for optimization reasons seems less kludgy than
analyzing it for references to global variables $1, $2..
(since they are in the runtime's name space as opposed to the
language syntax itself.)

Greg Fodor wrote:
>> How about something like: return $1 if (v + 1) < 10 if you wanted to
>> return v + 1? If you wanted to return v you could use: return $2 if
>> ((v) +1) < 10. Improvements would be using some of the regular
>> expression flags to control what $1, $2, etc. refer to.
> I like this better than def it() since it seems more intentional,
> but it too results in side effects into global space and prevents
> GCing early.
>
> Another problem is that you run into problems mixing the
> meaning of parenthesis, since within a given expression in your
> example you may not want to set aside storage space for all
> parenthesized expressions, despite the fact you may need to enforce
> order of operations.
>
> For example:
>
> puts $2 if (x + y) * (a - b) < 10
>
> will copy the result of x + y in RAM even if your parentheses are
> there to simply make the add happen first. Having it be something
> new in this context like pipes separates concerns and avoids these
> technical consequences.
>

That was why I had put in the comment about using flags from regular
expressions to control whether something was added to the global
variables. I am still reading about regular expressions and don't
remember the flags in question. This would also prevent extraneous data
being placed in the global variables which was another of your concerns.

> FYI, this would be:
>
> puts it if (x + y) * |(a - b)| < 10
>

My problem, and probably that of a lot of other people, is that it is
almost impossible to scan over a line like that and figure out what is
going on. If I am trying to debug a program I want the code to be as
clear as possible. I can see right away that something is placed on the
screen if the expression evaluates to < 10, but what? Now I have to
stop and try and remember how this is evaluated. Is it the information
in the first set of parentheses or between the pipes or something else?
This break in concentration can be a real killer in finding obscure bugs.
My proposal also suffers from some of this problem but as it is
"inherited" from regular expressions it may be easier to figure out.

> We just get temp storage for a - b and preserve a single meaning
> of parentheses.
>
>

> This break in concentration can be a real killer in finding obscure bugs.
> My proposal also suffers from some of this problem but as it is
> "inherited" from regular expressions it may be easier to figure out.
>
I understand these concerns. The pipes are just sugar, it seems like
it
would be a small learning curve to me, but here are a few other ideas:

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

It's not quite convincing that having an explicit relationship between
it => pipes, once learned, is more difficult to read/parse in your
head than scanning parentheses to figure out which are being used
as storage and which are not. (And if you said $8, which one is
actually
$8 and not $7! )

When I first learned Ruby, reading:

return x if x < 5

Was really counterintuitive at first cause my brain was used to
thinking
"if I see 'return', it's going to return if I got to that line in the
code." I had to unlearn that assumption, and read the full line
checking
for the trailing condition.

I see that mental leap as being many times more difficult to learn
than
associating an expression wrapped in pipes (or other sugar) with the
'it'
keyword.

Although, I'll grant that if there is a solution that functionally
meets
my list that uses idioms from another domain like regular expressions
it
might be a good contender. Maybe you can explain more about the flags
thing with an example to see how it feels vs. the pipes approach?