# a = b = c order of evaluation weird

Discussion in 'Ruby' started by SpringFlowers AutumnMoon, Oct 2, 2007.

1. ### SpringFlowers AutumnMoonGuest

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?
--
Posted via http://www.ruby-forum.com/.

SpringFlowers AutumnMoon, Oct 2, 2007

2. ### 7stud --Guest

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

--
Posted via http://www.ruby-forum.com/.

7stud --, Oct 2, 2007

3. ### 7stud --Guest

7stud -- wrote:
> SpringFlowers AutumnMoon wrote:
>>
>> why is that?

Or even simpler:

a = Array(1..6)

a[puts "hello"] = a[puts "world"] = nil
--
Posted via http://www.ruby-forum.com/.

7stud --, Oct 2, 2007
4. ### David A. BlackGuest

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?

David

--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.

David A. Black, Oct 2, 2007
5. ### David A. BlackGuest

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

--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.

David A. Black, Oct 2, 2007
6. ### David A. BlackGuest

Hi --

On Tue, 2 Oct 2007, SpringFlowers AutumnMoon wrote:

> 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?

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

--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.

David A. Black, Oct 2, 2007
7. ### Chris BaileyGuest

Variable scope in GServer

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

-/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.

Chris Bailey, Oct 2, 2007
8. ### Bertram ScharpfGuest

Re: Variable scope in GServer

Hi,

Am Dienstag, 02. Okt 2007, 19:25:07 +0900 schrieb Chris Bailey:
> I'm having a bit of a problem [...]

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

Bertram

--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de

Bertram Scharpf, Oct 2, 2007
9. ### 7stud --Guest

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.
--
Posted via http://www.ruby-forum.com/.

7stud --, Oct 2, 2007
10. ### 7stud --Guest

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.size*2/3..1;a.size*2/3..1)] = nil
p a

--
Posted via http://www.ruby-forum.com/.

7stud --, Oct 2, 2007
11. ### CalamitasGuest

Re: a = b = c order of evaluation weird

On 02/10/2007, 7stud -- <> wrote:
> 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.

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

Calamitas, Oct 2, 2007
12. ### Mariusz PÄ™kalaGuest

Re: a = b = c order of evaluation weird

--HLsZ5Z1opAQvdr2J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:
> My impression was that the OP knew what the evaluation order is, but
> not why it is like that.
>=20
> But anyway, my take on this is that
>=20
> a[0..a.size/2] =3D a[a.size*2/3..-1] =3D nil
>=20
> is equivalent to:
>=20
> a.[]=3D(0..a.size/2, a.[]=3D(a.size*2/3..-1, nil))
>=20
> 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?

--=20
A thousand words are worth a picture, and they load a heck of a lot faster.

--HLsZ5Z1opAQvdr2J
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7-ecc0.1.6 (GNU/Linux)

iD8DBQFHAjj+snU0scoWZKARAoc1AJ0RFUcxRWBIrLP/LJDIT6eCbjnOCwCfRFiJ
EZNHB9Dy1eJMU48QT7BFhZs=
=PoQK
-----END PGP SIGNATURE-----

--HLsZ5Z1opAQvdr2J--

Mariusz PÄ™kala, Oct 2, 2007
13. ### David A. BlackGuest

Re: a = b = c order of evaluation weird

--1926193751-378101879-1191331521=:14474
Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-378101879-1191331521=:14474"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--1926193751-378101879-1191331521=:14474
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

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

> On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:
>> 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] =3D a[a.size*2/3..-1] =3D nil
>>
>> is equivalent to:
>>
>> a.[]=3D(0..a.size/2, a.[]=3D(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 =3D [1,2,3,4,5]
=3D> [1, 2, 3, 4, 5]
irb(main):002:0> b =3D 1
=3D> 1
irb(main):003:0> a =3D (b =3D 10)
=3D> 10
irb(main):004:0> a
=3D> [1, 10, 3, 4, 5]

David

--=20
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
--1926193751-378101879-1191331521=:14474--
--1926193751-378101879-1191331521=:14474--

David A. Black, Oct 2, 2007
14. ### Guest

Re: a = b = c order of evaluation weird

On 10/2/07, SpringFlowers AutumnMoon <> 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

, Oct 2, 2007
15. ### Bertram ScharpfGuest

Re: a = b = c order of evaluation weird

Hi,

Am Dienstag, 02. Okt 2007, 22:25:26 +0900 schrieb David A. Black:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tool=

s.
> On Tue, 2 Oct 2007, Mariusz P=C4~Ykala wrote:
>> On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:
>>> My impression was that the OP knew what the evaluation order is, but
>>> not why it is like that.

>>
>> 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.

Bertram

--=20
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de

Bertram Scharpf, Oct 2, 2007
16. ### David A. BlackGuest

Re: a = b = c order of evaluation weird

--1926193751-454653753-1191334354=:15525
Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-454653753-1191334354=:15525"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--1926193751-454653753-1191334354=:15525
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

On Tue, 2 Oct 2007, Bertram Scharpf wrote:

> Hi,
>
> Am Dienstag, 02. Okt 2007, 22:25:26 +0900 schrieb David A. Black:
>> This message is in MIME format. The first part should be readable tex=

t,
>> while the remaining parts are likely unreadable without MIME-aware too=

ls.
>> On Tue, 2 Oct 2007, Mariusz P=C4~Ykala wrote:
>>> On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:
>>>> My impression was that the OP knew what the evaluation order is, but
>>>> not why it is like that.
>>>
>>> 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

--=20
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
--1926193751-454653753-1191334354=:15525--
--1926193751-454653753-1191334354=:15525--

David A. Black, Oct 2, 2007
17. ### 7stud --Guest

Re: a = b = c order of evaluation weird

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 = 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.

--
Posted via http://www.ruby-forum.com/.

7stud --, Oct 2, 2007
18. ### SpringFlowers AutumnMoonGuest

Arlen Christian Mart Cuss 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?

--
Posted via http://www.ruby-forum.com/.

SpringFlowers AutumnMoon, Oct 2, 2007
19. ### 7stud --Guest

Re: a = b = c order of evaluation weird

Arlen Christian Mart Cuss 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?
--
Posted via http://www.ruby-forum.com/.

7stud --, Oct 2, 2007
20. ### F. SenaultGuest

Re: a = b = c order of evaluation weird

Le 02 octobre à 18:23, 7stud -- a écrit :

> Arlen Christian Mart Cuss 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?

You can play with set_trace_func :

20:16 fred@vodka:~/ruby> cat toto.rb
#! /usr/local/bin/ruby

a = Array(1..100)

set_trace_func proc { |e,f,l,i,b,c|
printf "%8s %s:%-2d %10s %8s\n",e,f,l,i,c if e == 'c-call'
}

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

20:16 fred@vodka:~/ruby> ruby toto.rb
c-call toto.rb:9 size Array
c-call toto.rb:9 / Fixnum
c-call toto.rb:11 size Array
c-call toto.rb:11 * Fixnum
c-call toto.rb:11 / Fixnum
c-call toto.rb:12 []= Array
c-call toto.rb:10 []= Array

(I didn't expect the real line numbers, by the way. Cooool !)

Fred
--
Now that I think about it, having a (dense) group of Marketeers and
Salesweasels play russian roulette with, say, an 88 Flak would be better
than handing one of them an M1911 and convincing them that their odds
are better than with a revolver. (Matt Olson in ATSR)

F. Senault, Oct 2, 2007