Compound Parallel Operators

(I didn’t see an RCR for this, and my lazy 60s of searching didn’t find
any discussion about it. If it’s been discussed before, just say so and
I’ll go hunt for the discussion properly.)

Ruby allows parallel assignment:
a,b,c = x,y,z

Ruby interprets compound operators:
a *= x
as
a = a * x

Wouldn’t it be nice if all compound operators worked with parallel
assignment?
a,b,c *= x,y,z
would thus be interpreted as
a *= x
b *= y
c *= z

I think it’d be nice, anyhow. It simplifies a small subset of code, but
it seems like a simple logical extension. (And, it’s currently a syntax
error, so there’s no backwards compat issues, right?)

a,b,c += *vals
versus
a,b,c = [a,b,c].zip( vals ).map{ |a,b| a+b }
or
a += vals[0]
b += vals[1]
c += vals[2]

I think it looks like a good idea. It doesn’t seem to be a huge leap,
but it may make code hard to read for some. I started out as a c
programmer and it shocked me the first time I ran into a,b,c=x,y,z. I
was completely confused.

Gavin K. wrote:

a = a * x

Wouldn’t it be nice if all compound operators worked with parallel
assignment?
a,b,c *= x,y,z
would thus be interpreted as
a *= x
b *= y
c *= z

I brought this up once… but there was some Good Reason it didn’t
work that way.

Hal

Martin C. wrote:

You know, time taken to type out expressions is not the limiting
factor in a programmer’s efficiency.
+1

And removing white space does not make your program run faster.

Timothy H. wrote:

Martin C. wrote:

You know, time taken to type out expressions is not the limiting
factor in a programmer’s efficiency.
+1

And removing white space does not make your program run faster.

It does if the program is printing all that whitespace to a 110-baud
teletype. :slight_smile:

On Fri, 6 Oct 2006, M. Edward (Ed) Borasky wrote:

It does if the program is printing all that whitespace to a 110-baud
teletype. :slight_smile:

or sending over the network to a browser :wink:

-a

Wouldn’t it be nice if all compound operators worked with parallel
assignment?
a,b,c *= x,y,z
would thus be interpreted as
a *= x
b *= y
c *= z

That’s a scary bit of perlish implicitness. They call it “Do What I
Mean”, when actually it’s “Attempt to Do What You Think I Mean Getting
it Right 60% of The Time”.

You know, time taken to type out expressions is not the limiting
factor in a programmer’s efficiency.

Martin

M. Edward (Ed) Borasky wrote:

It does if the program is printing all that whitespace to a 110-baud
teletype. :slight_smile:

(Slaps forehead) Of course! And I bet it would save money on all those
mostly-blank rolls of yellow paper, too! :slight_smile:

It does if the program is printing all that whitespace to a 110-baud
teletype. :slight_smile:

I hate my job.

Martin

Phrogz wrote:
[…]

Now, I would consider it a valid argument to say “Let’s not codify a
particular interpetation of some syntax that conflicts with another
reasonable interpretation, because it will be surprising to a notable
percentage of programmers.” Would anyone say that they personally have
a different expectation for what “a,b += x,y” might mean?

“The same as
a,b = a,b + x,y
but with a,b evaluated only once”?

(?)

Martin C. wrote:

it Right 60% of The Time".
Where do you draw the line? By that rationale, Isn’t “a *= b” or “a,b =
x,y” DWIM?

I would say DWIM only becomes a problem when the interpretation of a
particular syntax varies based on the context. In this case (and a*=b
and a,b=x,y) the language has one and only one clear interpretation.

Now, I would consider it a valid argument to say “Let’s not codify a
particular interpetation of some syntax that conflicts with another
reasonable interpretation, because it will be surprising to a notable
percentage of programmers.” Would anyone say that they personally have
a different expectation for what “a,b += x,y” might mean?

You know, time taken to type out expressions is not the limiting
factor in a programmer’s efficiency.

No, but it certainly contributes. I don’t write ‘block’-based functions
in JavaScript because it is prohibitively annoying to type an anonymous
function:

myArray.each( function( a ){ alert( a ) } );

I’m not going to say that terser is always better, but one of Ruby’s
strong suits is its ability to succinctly express what you mean.

Death by a thousand paper cuts is still death, and every little bit of
polish helps. IMO.

Martin C. wrote:

“The same as
a,b = a,b + x,y
but with a,b evaluated only once”?

Well quite, which is a syntax error, obviously, because there are
three rvalues and only two lvalues.

It doesn’t matter ( a,b = 1,2,3; p a,b #=> 1\n2 ). But unless
(a,b) OP (c,d)
does
a OP c; b OP d
(it currently doesn’t and it’s a syntax error) we lose a nice, simple
and general explanation of what
x OP= y
does.

On 10/6/06, Carlos [email protected] wrote:

but with a,b evaluated only once"?

Well quite, which is a syntax error, obviously, because there are
three rvalues and only two lvalues.

Which kind of demonstrates how the Law of Unintended Consequences can
flummox even the most sickly of synactic sugars.

Martin

Brian M. wrote:

var = :red
var, var[:ruby] = {}, var

Ouch…my brain hurts. I really would have expected that to fail
(trying to call :red#[]).

Is that* a guaranteed feature of compound assignment (per some notional
Ruby spec that we don’t have), or is that a by-product of the current
implementation?

(* Specifically that the R1->L1 assignment happens before the second
assignment is evaluated.)

Timothy H. wrote:

(Slaps forehead) Of course! And I bet it would save money on all those
mostly-blank rolls of yellow paper, too! :slight_smile:

Hey, you can write abusive notes on those and stick them to your
colleagues’ backs! Those yellow paper leftovers are essential for office
survival.

David V.
(Don’t Ask)

On 10/6/06, Carlos [email protected] wrote:

but with a,b evaluated only once"?
An example of how we already have behavior that most don’t realize:

var = :red
var, var[:ruby] = {}, var

Note that this will actually work which means you have to decompose to
a much more complex structure… one with things like temp vars:

Right

one = {}
two = var

Left

var = one
var[:ruby] = two

Or course we could optimize that to:

Temps

two = var

Left

var = {}
var[:ruby] = two

… but that is about all the complexity we need. It gets ever more
confusing with parallel operators.

Now it gets confusing because the time things get referred to is all
messed up:

Not real code!

var = ‘ruby’
var, var += var, var.reverse

one = var
two = var.reverse
var += one #=> ruby + ruby
var += two #=> (ruby + ruby) + ybur

Confusing enough for me. I’m not sure I would really use parallel
operators. I do use, parallel assignment quite a bit (nice for
argument handling and just avoiding temp vars in general).

With all of that said, I am not sure if I am really against the
concept either. It just isn’t really important to me.

Brian.

On 10/6/06, [email protected] [email protected] wrote:

in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. – wei wu wei

Nowadays there are even more appropriate protocols available
http://en.wikipedia.org/wiki/IP_over_Avian_Carriers
completely OT, but hillarious.

Cheers
Robert


Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.

  • Albert Einstein

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs