A = b = c order of evaluation weird

i thought if it is

a = b = c

due to associativity rule, then it is

a = (b = c)

so (b = c) is evaluated first. and then now it will be a =
(evaluated_value)

now how come when

a = Array(1…100)

and to cut off the first 1/3 and last 1/3 of the array to get about 33
elements, shouldn’t we use

a[0…a.size/2] = a[a.size*2/3…-1] = nil

as after the last 1/3 is deleted, you got about 66 elements remaining
and we want the other half deleted, to get to 33 elements. However, it
won’t work and requires

a[0…a.size/3] = a[a.size*2/3…-1] = nil

why is that?

SpringFlowers AutumnMoon wrote:

why is that?

a = Array(1…6)
p a

puts “size: #{a.size/3}”
a[p(0…a.size/3)] = a[p(a.size*2/3…-1)] = nil

7stud – wrote:

SpringFlowers AutumnMoon wrote:

why is that?

Or even simpler:

a = Array(1…6)

a[puts “hello”] = a[puts “world”] = nil

On Tue, 2 Oct 2007, 7stud – wrote:

7stud – wrote:

SpringFlowers AutumnMoon wrote:

why is that?

Or even simpler:

a = Array(1…6)

a[puts “hello”] = a[puts “world”] = nil

puts returns nil, and you can’t index an array with nil.

David

Hi –

On Tue, 2 Oct 2007, 7stud – wrote:

SpringFlowers AutumnMoon wrote:

why is that?

a = Array(1…6)
p a

puts “size: #{a.size/3}”
a[p(0…a.size/3)] = a[p(a.size*2/3…-1)] = nil

Have you tried to run that? :slight_smile:

David

Hi –

On Tue, 2 Oct 2007, SpringFlowers AutumnMoon wrote:

and we want the other half deleted, to get to 33 elements. However, it
won’t work and requires

a[0…a.size/3] = a[a.size*2/3…-1] = nil

why is that?

Although the = associates to the right, the subscript expressions are
evaluated first. So you’re really doing:

a[0…50] = a[66…-1] = nil

David

I’m having a bit of a problem accessing variables in an instance of
GServer.
What I would like to do is make a hash that is effectively global to the
current thread.

-/Server.rb
require ‘gserver’
require ‘connect.rb’

class TestServer < GServer
def initialize(port = 4000, *args)
super(port, *args)
end
def serve( io )
@test_hash = Hash.new
connect(io) #Defined in connect.rb
loop do
str = io.gets
parser(str,io)
end
end
end

The way that I’m doing it doesn’t allow each thread to have it’s own
copy of
@test_hash and that’s my problem. I need each thread to be able to
change
the data stored in the hash without affecting the data stored in the
hash
for all threads. I’m sure that my understanding of scope and GServer
itself
is causing my problem, but I just don’t know what to do to fix it. I was
thinking that I could pass the hash as a parameter to the connect
function
but that would quickly become a problem as it would need to be passed to
several other functions after that and if possible I just don’t want to
have
to use that many extra parameters in my functions. Any help would be
appreciated.

Hi,

Am Dienstag, 02. Okt 2007, 19:25:07 +0900 schrieb Chris B.:

I’m having a bit of a problem […]

Please have a look where your message appears when you just
hit the “Reply” button:

http://news.gmane.org/gmane.comp.lang.ruby.general/cutoff=229420

Bertram

David A. Black wrote:

On Tue, 2 Oct 2007, 7stud – wrote:

7stud – wrote:

SpringFlowers AutumnMoon wrote:

why is that?

Or even simpler:

a = Array(1…6)

a[puts “hello”] = a[puts “world”] = nil

puts returns nil, and you can’t index an array with nil.

Yes, I know, but that isn’t the point of the example. The output
provides the answer to the question.

On 02/10/2007, 7stud – [email protected] wrote:

a = Array(1…6)

a[puts “hello”] = a[puts “world”] = nil

puts returns nil, and you can’t index an array with nil.

Yes, I know, but that isn’t the point of the example. The output
provides the answer to the question.

My impression was that the OP knew what the evaluation order is, but
not why it is like that.

But anyway, my take on this is that

a[0…a.size/2] = a[a.size*2/3…-1] = nil

is equivalent to:

a.[]=(0…a.size/2, a.[]=(a.size*2/3…-1, nil))

Arguments are evaluated left to right, completely explaining the
evaluation order the OP is seeing.

Peter

On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:

Arguments are evaluated left to right, completely explaining the
evaluation order the OP is seeing.

I guess it’s safer to say that the order of evaluating arguments is
undefined, unless it is stated somewhere.

Is it defined for ruby?

7stud – wrote:

a[puts “hello”] = a[puts “world”] = nil

puts returns nil, and you can’t index an array with nil.

How’s this:

a = Array(1…6)

a[(puts “hello”, 0…a.size/2;0…a.size/2)] = a[(puts “world”,
a.size2/3…1;a.size2/3…1)] = nil
p a

On 10/2/07, SpringFlowers AutumnMoon [email protected] wrote:

a = Array(1…100)

a[0…a.size/2] = a[a.size*2/3…-1] = nil

won’t work and requires

why is that?

a = Array(1…100)
a[0…a.size/2] = a[a.size*2/3…-1] = nil
p a

a = Array(1…100)

a.[]=(
0…(a.size)./(2),
a.[]=(
(((a.size).*(2))./(3))…-1, nil
)
)

p a

Hi,

Am Dienstag, 02. Okt 2007, 22:25:26 +0900 schrieb David A. Black:

Is it defined for ruby?

I believe that a subscript expression is always going to be evaluated
first:

I never found it’s good programming practice in any language
to rely on evaluation order of function/method arguments.
Understanding your own code will become unneccessarily hard.

Bertram

Hi –

On Tue, 2 Oct 2007, Bertram S. wrote:

I guess it’s safer to say that the order of evaluating arguments is
undefined, unless it is stated somewhere.

Is it defined for ruby?

I believe that a subscript expression is always going to be evaluated
first:

I never found it’s good programming practice in any language
to rely on evaluation order of function/method arguments.
Understanding your own code will become unneccessarily hard.

I wouldn’t go out of my way to do tricks involving evaluation order,
but I certainly advocate understanding what’s going to happen under
what circumstances.

David

David A. Black wrote:

I believe that a subscript expression is always going to be evaluated
first:

irb(main):001:0> a = [1,2,3,4,5]
=> [1, 2, 3, 4, 5]
irb(main):002:0> b = 1
=> 1
irb(main):003:0> a[b] = (b = 10)
=> 10
irb(main):004:0> a
=> [1, 10, 3, 4, 5]

I think you missed Mariusz PÄ™kala’s point:

Mariusz Pękala wrote:

On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:

Arguments are evaluated left to right, completely explaining the
evaluation order the OP is seeing.

I guess it’s safer to say that the order of evaluating arguments is
undefined, unless it is stated somewhere.

Is it defined for ruby?

In other words, I think Mariusz was pointing out that, yes the subscript
expressions are evaluated before the assignments, but does that
necessarily mean the subscript expressions are guaranteed to be
evaluated left to right. Since your example only has one subscript
expression, it doesn’t shed any light on that issue.

On Tue, 2007-10-02 at 23:25 +0900, 7stud – wrote:

Since your example only has one subscript
expression, it doesn’t shed any light on that issue.

It demonstrates, at least, that one subscript op is evaluated
left-to-right, thus we expect all of them to be so.

Hi –

On Tue, 2 Oct 2007, Mariusz PÄ~Ykala wrote:

a.[]=(0…a.size/2, a.[]=(a.size*2/3…-1, nil))

Arguments are evaluated left to right, completely explaining the
evaluation order the OP is seeing.

I guess it’s safer to say that the order of evaluating arguments is
undefined, unless it is stated somewhere.

Is it defined for ruby?

I believe that a subscript expression is always going to be evaluated
first:

irb(main):001:0> a = [1,2,3,4,5]
=> [1, 2, 3, 4, 5]
irb(main):002:0> b = 1
=> 1
irb(main):003:0> a[b] = (b = 10)
=> 10
irb(main):004:0> a
=> [1, 10, 3, 4, 5]

David

Arlen Christian Mart C. wrote:

and to cut off the first 1/3 and last 1/3 of the array to get about 33
elements, shouldn’t we use

a[0…a.size/2] = a[a.size*2/3…-1] = nil

Or, just do a.slice!(a.size/3…a.size*2/3)

there are so many people who are familiar with Ruby. Have been using
Ruby for a long time? Do you find after using Ruby, a work day becomes
a fun day?

Arlen Christian Mart C. wrote:

On Tue, 2007-10-02 at 23:25 +0900, 7stud – wrote:

Since your example only has one subscript
expression, it doesn’t shed any light on that issue.

It demonstrates, at least, that one subscript op is evaluated
left-to-right, thus we expect all of them to be so.

How do you know the subscript expression wasn’t evaluated from right to
left?