*a = 9 # => [9]
a # => [9]
*a # => compile error
*b=*a # => [9]
*b = a # => [[9]]
b = a # => [9]
b = *a # => 9 ----- this is amazing ?
Hi –
On Thu, 15 Feb 2007, sur max wrote:
*a = 9 # => [9]
a # => [9]
*a # => compile error
*b=*a # => [9]
*b = a # => [[9]]
b = a # => [9]
b = *a # => 9 ----- this is amazing ?
It’s doing what it should, I think. *a means: the unarrayed version
of [9], which is 9.
David
On 2/15/07, sur max [email protected] wrote:
*a = 9 # => [9]
a # => [9]
*a # => compile error
*b=*a # => [9]
*b = a # => [[9]]
b = a # => [9]
b = *a # => 9 ----- this is amazing ?
Splat operator is amazing, but above behaviour can be explained using
this:
"If the last lvalue is preceded by an asterisk, all the remaining
rvalues will be collected and
assigned to that lvalue as an array. Similarly, if the last rvalue is
an array, you can
prefix it with an asterisk, which effectively expands it into its
constituent values in
place. (This is not necessary if the rvalue is the only thing on the
right side—the array
will be expanded automatically.)
"
See, nothing wierd out there. 
PS: Taken from PickAxe Verbatim.
Hi –
On Fri, 16 Feb 2007, hemant wrote:
See, nothing wierd out there.
Another way to look at it, which I think covers all of the above
cases, is:
*x equals [x] without the []
So:
*a = 9 # a without the [] is 9, so a == [9]
*b = a # b without the [] is [9], so b == [[9]]
b = *a # b == [9] without the [], so b == 9
That’s why I call it the “unary unarray” operator.
David
ok and its like …
*a = 9
a << 5
b = *a # => [9,5]
is there any relation in this n above ?
Thats pretty known.
And even this too…
a = 2,3,4,5,6 # => [2,3,4,5,6]
b, = a — now this is beauty
b # => 2
b,c = a
b # => 2
c # => 3
and so…
b,c,d = a
but still didnt get clear … is it like we can use *a for assigning
to
some other var ONLY ?
On 2/15/07, sur max [email protected] wrote:
ok and its like …
*a = 9
remember a would become an array here.because as explained above,if
lvalue is prefixed with asterisk, then rvalue is collected and
assigned to lvalue as an array.
a << 5
append 5 to a (which is an array)
b = *a # => [9,5]
is there any relation in this n above ?
Now, above is pretty standard ruby behaviour, it has nothing to do
with * operator, as usual * extracts the values from a(which was an
array).
For example:
irb(main):062:0> b = 9,5
[9, 5]
irb(main):063:0> b
[9, 5]
irb(main):064:0> b,c = 9,5
[9, 5]
irb(main):065:0> b
9
irb(main):066:0> c
5
On 2/15/07, sur max [email protected] wrote:
Thats pretty known.
And even this too…
Again, I am sorry to bore you with little known things.
but still didnt get clear … is it like we can use *a for assigning to
some other var ONLY ?
I would like to think so, thats why we got syntax error exception
tossed at our face when we do:
*a = 9
*a
I guess ruby interpretor is doing tough job of differentiating splat
from multiplication operator and it decided to not allow you to do
that.
However, you can very well do
a = 9
+a
++a
-a
Again, I might be stating the obvious.
On 2/15/07, [email protected] [email protected] wrote:
b = a # => [9]
place. (This is not necessary if the rvalue is the only thing on the
right side—the array
will be expanded automatically.)
"
See, nothing wierd out there.
Well I cannot speak for OP but what puzzles me is
a=[42] # sorry 9 is not the number
*a ==> error # gotta check with 1.9 an 2.0 at home
I would think that this expression can/could/should/might perfectly
evaluate to 42
look at this other oddity the following code is completely legal and
POLS(1)
def x *args
return *args
end
(1) in the sense that a,b,c = x 1,2,3 sets a to 1, b to 2 and c to 3
and x is a NOP
but return in the last statement is optional, or is it not I know
you are not falling into my trap !
I see no reason however why
def x *args
*args
end
should not be legal
> That's why I call it the "unary unarray" operator. Which is a good mnemonic idea! Very didactic I feel! > Cheers RobertAnother way to look at it, which I think covers all of the above
cases, is:*x equals [x] without the []
unless it causes an error, which is not really very sexy behavior IMHO.
def a *args
*args
end
is very much illegal … giving compile error
and with return keyword it works very fine.
I am still feeling that point(s) still lasts
Again i am repeating the same old story …
*a = 9 # i like this number 
b = *a # => 9 ------- mind it, it is Fixnum
here it seems true “*x equals [x] without the []”
a << 5
b = *a # => [9,5] ------- an Array
here it seems false “*x equals [x] without the []”
moreover
*a # => compile error
is it strange behavior ? or pretty digestible ?
Hi –
On Fri, 16 Feb 2007, sur max wrote:
*a = 9 # i like this number
b = *a # => 9 ------- mind it, it is Fixnum
here it seems true “*x equals [x] without the []”a << 5
b = *a # => [9,5] ------- an Array
here it seems false “*x equals [x] without the []”
But you have to consider this:
b = 9,5 # => [9,5]
so “[9,5] without a []”, on the rhs, gets turned into an array. I
know it sounds like I’m putting in an extra step… but it really is
consistent in terms of the behavior of * itself.
moreover
*a # => compile erroris it strange behavior ? or pretty digestible ?
What would that mean, though? Or, to put it another way, what could
you possibly do with *a on its own?
David
Hi –
On Fri, 16 Feb 2007, Robert D. wrote:
end
should not be legal
I can’t think of a case where you’d need it, since the arguments would
just get wrapped up in an array anyway. Also, *args is basically
equivalent to a bare list, and you can’t do:
def x
1,2,3
end
David
Hi –
On Fri, 16 Feb 2007, Jacob F. wrote:
and
b = 9, 5
Have the same effect. You were just forgetting to consider that b
would just slurp them back into an array.*a # => compile error
This seems to be the only remaining “anomaly”.
It isn’t, though:
irb#1(main):017:0> a = [9,5]
=> [9, 5]
irb#1(main):018:0> *a
SyntaxError: compile error
(irb#1):18: syntax error
from (irb#1):18
irb#1(main):019:0> 9,5
SyntaxError: compile error
(irb#1):19: syntax error
from (irb#1):19
David
On 2/15/07, sur max [email protected] wrote:
*a = 9 # i like this number
…
a << 5
b = *a # => [9,5] ------- an Array
here it seems false “*x equals [x] without the []”
Actually, the “rule” still applies, in that:
b = *a # where a = [9, 5]
and
b = 9, 5
Have the same effect. You were just forgetting to consider that b
would just slurp them back into an array.
*a # => compile error
This seems to be the only remaining “anomaly”.
Jacob F.
if we even consider it this way …
*a = 9
a << 5
i mean a = [9,5]
and now considering it as…
a # => [9,5]
*a # => 9,5 — (on assignment)
so the following should be true
b = a # => [9,5] ----- true
b = *a # => [9,5] ----- true , b is re-wrapping 9,5 as [9,5]
b = [a,6] # => [[9,5],6] ---- true, naturally
b = [*a,6] # => [9,5,6] ----- false, compile error
b = *a,6 # => [9,5,6] ----- false, compile error
Hi –
On Fri, 16 Feb 2007, sur max wrote:
so the following should be true
b = a # => [9,5] ----- true
b = *a # => [9,5] ----- true , b is re-wrapping 9,5 as [9,5]
b = [a,6] # => [[9,5],6] ---- true, naturally
b = [*a,6] # => [9,5,6] ----- false, compile error
b = *a,6 # => [9,5,6] ----- false, compile error
In Ruby 1.8 and earlier, you can only do the * at the end of an array.
That’s changing, though. This is from a November version of Ruby 1.9:
irb(main):001:0> a = [9,5]
=> [9, 5]
irb(main):002:0> b = 9,5,6
=> [9, 5, 6]
irb(main):003:0> b = *a, 6
=> [9, 5]
irb(main):004:0> b = [*a, 6]
=> [9, 5, 6]
I don’t really understand the third one. I would have expected it to
be the same as the second. I haven’t tried a more recent 1.9 version,
though – maybe it’s been changed.
David
On 2/15/07, [email protected] [email protected] wrote:
evaluate to 42 look at this other oddity the following code is
I see no reason however why
def x *args
*args
end
should not be legalI can’t think of a case where you’d need it, since the arguments would
just get wrapped up in an array anyway.
Agreed, but that was not my point
Also, *args is basically
equivalent to a bare list, and you can’t do:def x
1,2,3
end
def x
return 1,2,3
end
is legal it all is about consistency
1,2,3 vs. return 1,2,3
*rhs vs. lhs = *rhs
I have no idea if one could make it work without breaking a parsable
syntax, I just thought that OP was doing a good job at pointing to
this inconsistency.
We could forbid return *a but can we forbid lhs = *rhs?
I realize I am not smart enough to complain, - and too tired too 
-.
But I also feel that I did not really underline the inconsistency in
the syntax so far.
An inconsistency that is not really troubling me but which is here
nevertheless.
Well that is pretty much what I wanted to say.
Cheers
Robert
gr8…
sounds satisfactory !!
i will try it on 1.9
Thanks a lot to all !!
fr: sur max [mailto:[email protected]] :
b = [*a,6] # => [9,5,6] ----- false, compile error
b = *a,6 # => [9,5,6] ----- false, compile error
pls be careful. “*” op will splat. so here ruby is just telling/policing
you not too.
I always treat splat op as a black hole. this way i make less mistakes.
eg
so this is allowed,
irb(main):050:0> b,*a=1,2,3,4
=> [1, 2, 3, 4]
irb(main):052:0> a
=> [2, 3, 4]
this one is not,
irb(main):053:0> b,*a,c=1,2,3,4
SyntaxError: compile error
(irb):53: syntax error, unexpected ‘,’, expecting ‘=’ b,*a,c=1,2,3,4
irb(main):054:0>
ruby, is telling me that “*a” is a blackhole. The c does “not matter”.
so is this one,
irb(main):056:0> *a
SyntaxError: compile error
(irb):56: syntax error, unexpected ‘\n’, expecting ‘=’
that’s a blackhole without a hole or opening. feed it 
again, another stupid blackhole reasoning.
nonetheless, splat is a very sweet yet too powerful operator. I feel
that splat op digress oo-ness. But i believe it’s not oo for oo’s sake.
It’s solving problems and discovering brilliant solutions. Ruby does it
w ease and fun. Sometimes, i feel ruby will trend toward object and
method unification, wherein objects can be methods and vice versa.
arggh, like matter <==> energy. maybe, a superproc or superlamdba in
the future… i’ll stop now
drive w caution, (black)holes ahead.
sorry for the long post fr a nuby.
kind regards -botp
definitely, it seems so natural using
= *a,b
and this gives the feel of ruby.
isn’t it ?