Order of evaluation and precedence

[Seebs]

In _The Ruby Programming Language_, it is asserted that order of evaluation
is controlled by precedence.

However, this is often asserted in books about C, where it's definitely
not true. Is it actually true in Ruby?

In other words:

def a
puts "a"
1
end
def b
puts "b"
1
end
def c
puts "c"
1
end
x = a + (b + c)

Is it actually guaranteed that the output will have "a" after "b" and "c"?
In C, it wouldn't be. (Compilers are free to evaluate the operands in any
order whatsoever, then feed them into operators, all that precedence and
grouping controls is which operands go to which operators.)

-s

 

[Rick DeNatale]

In _The Ruby Programming Language_, it is asserted that order of evaluati= on
is controlled by precedence.

However, this is often asserted in books about C, where it's definitely
not true. =A0Is it actually true in Ruby?

In other words:

=A0 =A0 =A0 =A0def a
=A0 =A0 =A0 =A0 =A0puts "a"
=A0 =A0 =A0 =A0 =A01
=A0 =A0 =A0 =A0end
=A0 =A0 =A0 =A0def b
=A0 =A0 =A0 =A0 =A0puts "b"
=A0 =A0 =A0 =A0 =A01
=A0 =A0 =A0 =A0end
=A0 =A0 =A0 =A0def c
=A0 =A0 =A0 =A0 =A0puts "c"
=A0 =A0 =A0 =A0 =A01
=A0 =A0 =A0 =A0end
=A0 =A0 =A0 =A0x =3D a + (b + c)

Is it actually guaranteed that the output will have "a" after "b" and "c"= ?
In C, it wouldn't be. =A0(Compilers are free to evaluate the operands in = any
order whatsoever, then feed them into operators, all that precedence and
grouping controls is which operands go to which operators.)

I think you are confusing precedence ordering with evaluation strategy.

Precedence determines the order in which the
operators/functions/methods are performed. so in

a + b * c

the * is performed before the +

But the timing of when the argument expressions is evaiuated is a
different issue.

Ruby like most other languages uses what is called applicative
ordering, which means that the arguments to a function are evaluated
before the function is called (or applied). They don't need to be
evaluated JUST before the function is applied, just BEFORE it is.

Consider this Ruby program and its output:

class NoisyNum

def initialize(name)
@name =3D name
puts "#{name} created"
end

def to_s
@name.to_s
end

def +(other)
NoisyNum.new("#{self}+#{other}")
end

def *(other)
NoisyNum.new("#{self}*#{other}")
end

end

def N(name)
NoisyNum.new(name)
end

x =3D Na) + Nb) * Nc)

a created
b created
c created
b*c created
a+b*c created

A few languages use what is called Normal order (strange since it's
not the normal strategy used) in which the evaluation of the arguments
is delayed until they are needed by a function. Some languages like
Lisp/Scheme normally use applicative order, but have what are called
special forms which use normal order.

This allows special forms to be used to define control flow like
if/then/else to be implemented with a function with the condition, and
the two alternatives.

In Ruby you could think of the expression a || b as a special form in
that the b expression is not evaluated unless a is not truthy.

HTH

--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Seebs]

I think you are confusing precedence ordering with evaluation strategy.

I am not.

Precedence determines the order in which the
operators/functions/methods are performed.

Right. But the book says that the expressions are evaluated in
that order...

But the timing of when the argument expressions is evaiuated is a
different issue.

The reason I asked is not that I'm generally unaware of this, but
rather, that many people believe that this means that everything inside ()
has to be performed before anything outside of (), for instance.

I was trying to figure out whether the statement that precedence affects
order of evaluation meant that it controlled the order in which subexpressions
were evaluated, or just the grouping and ordering of operators.

Ruby like most other languages uses what is called applicative
ordering, which means that the arguments to a function are evaluated
before the function is called (or applied). They don't need to be
evaluated JUST before the function is applied, just BEFORE it is.

Right. That was what I was expecting. But now I am confused, because
I thought I asked that and Matz said that it did control the order of
evaluation, but now I think he said it doesn't.

Which I'm guessing means that evaluation of operators follows precedence order
(or at least, everything looks as though it did).

-s