Re: Ruby wishlist

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 <[e-mail]> (GoogleTalk:
[e-mail])
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)