a = b = c order of evaluation weird

[SpringFlowers AutumnMoon]

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?

 

[7stud --]

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

Or even simpler:

a = Array(1..6)

a[puts "hello"] = a[puts "world"] = nil

 

[David A. Black]

Hi --

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.
See http://www.rubypal.com for more info!

 

[David A. Black]

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.
See http://www.rubypal.com for more info!

 

[David A. Black]

Hi --

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.
See http://www.rubypal.com for more info!

 

[Chris Bailey]

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.

 

[Bertram Scharpf]

Hi,

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

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

 

[7stud --]

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.

 

[7stud --]

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

 

[Calamitas]

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

 

[Mariusz Pękala]

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

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

 

[David A. Black]

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

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.
See http://www.rubypal.com for more info!
--1926193751-378101879-1191331521=:14474--
--1926193751-378101879-1191331521=:14474--

 

[brabuhr]

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

 

[Bertram Scharpf]

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.

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

 

[David A. Black]

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

Hi,

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

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.
See http://www.rubypal.com for more info!
--1926193751-454653753-1191334354=:15525--
--1926193751-454653753-1191334354=:15525--

 

[7stud --]

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:

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.

 

[SpringFlowers AutumnMoon]

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?

 

[7stud --]

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?

 

[F. Senault]

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

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