From: "Michael T. Richter" Date: 2008-06-08T12:53:22+09:00 Subject: Re: Ruby wishlist --=-LK47QScKu+tRVwi4JGKg Content-Type: multipart/alternative; boundary="=-fPM5992YgX8w8Ygu30rl" --=-fPM5992YgX8w8Ygu30rl Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2008-06-08 at 12:18 +0900, jzakiya wrote: > n1, n2, n3, n4 =3D nil This is a trivial thing to do because the semantics can't really be anything else but the obvious: all variables are set to "nil". > But you can't do this: > n1, n2, n3, n4 =3D [something] The semantics here aren't so clear. They seem clear if you say: n1, n2, n3, n4 =3D 5 It seems to be saying "set all these variables to 5". But what about this?: n1, n2, n3, n4 =3D [1, 2, 3, 4] What should the variables be set to? Should n1 be 1 or [1,2,3,4]? Should n2 be 2 or [1,2,3,4]? Well maybe the answer is "clear" in that it should do what the system already does: n1=3D1, n2=3D2, etc. You can even then concoct a rule to explain this. "If the variable is a scalar type, copy it to all recipients on the LHS. If it is an array type, copy the array element by element as per the existing semantics." But then how would I set four variables to the same array? Problem, eh? I'd have to do something like this: n1 =3D n2 =3D n3 =3D n4 =3D [1, 2, 3, 4] But if I have to do that for one case and not any others, why not go for maximal consistency and do that for all cases? You know, like we currently do: n1 =3D n2 =3D n3 =3D n4 =3D 5 So really the problem isn't that you can't do multiple assignment the way you want, the problem is that nil is treated specially for no good reason given that you can just as easily do: n1 =3D n2 =3D n3 =3D n4 =3D nil. Now myself? I'd go on the side of reducing semantic complexity rather than increasing it. If anything I'd get rid of the behaviour n1, n2, n3, n4 =3D nil instead of expanding on it in a nightmarish increase of special cases. I mean really, it doesn't take that much extra typing (four spaces) to do the version with equal signs. > And you can't do this: > n1, n2, n3, n4 [+,-,*, etc]=3D [something] a,b,c,d =3D [1,2,3,4] a,b,c,d =3D [a,b,c,d].collect { |x| x + 5 } It's a bit ugly, but again not that much extra typing and certainly still readable to anybody who knows even the basics of Ruby. It would be uglier, again, to work out the semantics for the special cases you seem to want to throw in. What happens if "something" is a scalar type? An array type? A hash type? A user-defined type of some kind? A string? A ... How many special cases do you want in the semantics? Ruby already has way too many such for my tastes. Don't get me wrong. I like syntactic (and semantic) sugar -- but not to the point that it rots my mental teeth. --=20 Michael T. Richter (GoogleTalk: ttmrichter@gmail.com) Never, ever, ever let systems-level engineers do human interaction design unless they have displayed a proven secondary talent in that area. Their opinion of what represents good human-computer interaction tends to be a bit off-track. (Bruce Tognazzini) --=-fPM5992YgX8w8Ygu30rl Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, 2008-06-08 at 12:18 +0900, jzakiya wrote:

n1, n2, n3, n4 =3D nil

This is a trivial thing to do because the semantics can't really be anythin= g else but the obvious: all variables are set to "nil".

But you can't do this:
n1, n2, n3, n4 =3D [something]

The semantics here aren't so clear. They seem clear if you say:

n1, n2, n3, n4 =3D 5

It seems to be saying "set all these variables to 5". But w= hat about this?:

n1, n2, n3, n4 =3D [1, 2, 3, 4]

What should the variables be set to? Should n1 be 1 or [1,2,3,4]?&nbs= p; Should n2 be 2 or [1,2,3,4]? Well maybe the answer is "clear&= quot; in that it should do what the system already does: n1=3D1, n2=3D2, et= c. You can even then concoct a rule to explain this. "If t= he variable is a scalar type, copy it to all recipients on the LHS. I= f it is an array type, copy the array element by element as per the existin= g semantics."

But then how would I set four variables to the same array? Problem, e= h? I'd have to do something like this:

n1 =3D n2 =3D n3 =3D n4 =3D [1, 2, 3, 4]

But if I have to do that for one case and not any others, why not go for ma= ximal consistency and do that for all cases? You know, like we curren= tly do:

n1 =3D n2 =3D n3 =3D n4 =3D 5

So really the problem isn't that you can't do multiple assignment the way y= ou want, the problem is that nil is treated specially for no good reason gi= ven that you can just as easily do:

n1 =3D n2 =3D n3 =3D n4 =3D nil.

Now myself? I'd go on the side of reducing semantic complexity rather= than increasing it. If anything I'd get rid of the behaviour n1, n2,= n3, n4 =3D nil instead of expanding on it in a nightmarish increase of spe= cial cases. I mean really, it doesn't take that much extra typing (fo= ur spaces) to do the version with equal signs.

And you can't do this:
n1, n2, n3, n4  [+,-,*, etc]=3D [something]

a,b,c,d =3D [1,2,3,4]
a,b,c,d =3D [a,b,c,d].collect { |x| x + 5 }

It's a bit ugly, but again not that much extra typing and certainly still r= eadable to anybody who knows even the basics of Ruby. It would be ugl= ier, again, to work out the semantics for the special cases you seem to wan= t to throw in. What happens if "something" is a scalar type= ? An array type? A hash type? A user-defined type of some= kind? A string? A ... How many special cases do you want= in the semantics? Ruby already has way too many such for my tastes.<= BR>
Don't get me wrong. I like syntactic (and semantic) sugar -- but not = to the point that it rots my mental teeth.

--
Michael T. Richter <ttmri= chter@gmail.com> (GoogleTalk: ttmrichter@gmail.com)
Never, ever, ever let systems-level engineers do human interaction desig= n unless they have displayed a proven secondary talent in that area. Their = opinion of what represents good human-computer interaction tends to be a bi= t off-track. (Bruce Tognazzini)

--=-fPM5992YgX8w8Ygu30rl-- --=-LK47QScKu+tRVwi4JGKg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIS1fzLqyWkKVQ54QRAji5AKC5X83fF/KP5/pCD4IjUKnL2EowRACfetFa Bn4pI+Gqw2VKbQLXc1E7cfI= =Ikk4 -----END PGP SIGNATURE----- --=-LK47QScKu+tRVwi4JGKg--