Evaluating expressions left to right

Rails
1

class Proc
def apply(enum)
enum.map &self
end
alias | apply

def reduce(enum)
enum.inject &self
end
alias <= reduce

def compose(f)
if self.respond_to?(:arity) && self.arity == 1
lambda {|*args| self[f[*args]] }
else
lambda {|*args| self[*f[*args]] }
end
end
alias * compose

end

sum = lambda {|x,y| x+y } # A function to add two numbers
mean = (sum<=a)/a.size # Or sum.reduce(a) or a.inject(&sum)
deviation = lambda {|x| x-mean } # Function to compute difference from
mean
square = lambda {|x| xx } # Function to square a number
standardDeviation = Math.sqrt((sum<=squaredeviation|a)/(a.size-1))

Ok so now I have another example from this book which does not contain
parentheses around deviation|a. So then why is this part:

(sum<=square*deviation|a)

not evaluated from left to right.

Apparently, it evaluates this part:

deviation|a

first

and this part second:

square*deviation|a

and then finally:

sum<=

So it looks like it is evaluating from right to left. Even though it
should be evaluating from left to right…

2

If you think about it there is only one possible answer to that
question. How could it evaluate meth2(meth3) without evaluating meth3
first, in order to pass the result to meth2? Similarly how could it
call meth1 before it evaluated the parameter to pass to it?

Colin

3

meth3 -> (meth2) -> (meth1)

The logic is that meth3 has to return so that meth2 can accept,
process and return so that meth1 can accept, process and return.
Don’t read nested methods like you read a book, with nested methods
the last to be nested is the first to be executed.

4

ok, it didn’t look like nested methods. But I made to believe that
this:

sum<=square*deviation|a

is exactly the same as this:

sum<=(square*(deviation|(a)))

So if this is true, then still a question remains.

Here’s the original context again:

module Functional

def compose(f)
if self.respond_to?(:arity) && self.arity == 1
lambda { |*args| self[f[*args]] }
else
lambda {|*args| self[*f[*args]] }
end
end
alias * compose

def apply(enum)
enum.map &self
end
alias | apply

def reduce(enum)
enum.inject &self
end
alias <= reduce

end

class Proc
include Functional
end

#client code
a = [1,2,3]
sum = lambda { |x,y| x+y }
mean = (sum<=a)/a.size
deviation = lambda { |x| x-mean }
square = lambda { |x| xx }
standardDeviation = Math.sqrt((sum<=squaredeviation|a)/(a.size-1))

On the last line, this executes first:

deviation|a

this returns a new array of how far each of elements are from the
mean.

Then this array gets passed to * which is invoked on square (a lambda
object):

square*returned_array

That calls compose where f parameter is the returned array from above.
So then this line is returned by compose since the array object doesnt
respond to arity:

lambda {|*args| self[*f[*args]] }

So it appears the return value of compose is the lambda object. That
presents a problem because <= expects an enum argument.

sum<=this_should_be_an_enum

5

That was my hunch. Thanks for clarifying.

6

On Tuesday, 25 December 2012 20:13:16 UTC-5, John M. wrote:

So if this is true, then still a question remains.

That’s not how it parses, thanks to operator precedence - the same
reason
that 2+510+3 parses as 2.+((5.(10)).+(3)) and not 2.+(5.*(10.+(3))).

You can use a tool like Ripper
(Using Ripper to See How Ruby Is Parsing Your Code)
to see exactly how something is being parsed. Trying your expression
yields:

[:program,
[[:binary,
[:vcall, [:@ident, “sum”, [1, 0]]],
:<=,
[:binary,
[:binary,
[:vcall, [:@ident, “square”, [1, 5]]],
:*,
[:vcall, [:@ident, “deviation”, [1, 12]]]],
:|,
[:vcall, [:@ident, “a”, [1, 22]]]]]]]

Or, distilled back to a fully-parenthized code version:

sum <= ((square*deviation) | a)

With the method calls written out explicitly:

sum.<=((square.*(deviation)).|(a))

Essentially, this creates a function that calculates the squared
deviation
from the mean (square*deviation), applies it to the list a, and then
sums
the resulting values.

This sort of confusion is why most people recommend avoiding operator
overloading in most cases - there are a bunch of precedence rules built
into the language, and you’re essentially stuck with them.

–Matt J.