[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Compound Parallel Operators

Martin Coxall

10/6/2006 8:54:00 AM

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

Tim Hunter

10/6/2006 11:46:00 AM

0

Martin Coxall 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.

M. Edward (Ed) Borasky

10/6/2006 1:33:00 PM

0

Timothy Hunter wrote:
> Martin Coxall 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. :)

Ara.T.Howard

10/6/2006 1:37:00 PM

0

Martin Coxall

10/6/2006 1:38:00 PM

0

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

I hate my job.

Martin

Tim Hunter

10/6/2006 1:38:00 PM

0

M. Edward (Ed) Borasky wrote:
> Timothy Hunter wrote:
>
>> Martin Coxall 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. :)
>
>
(Slaps forehead) Of course! And I bet it would save money on all those
mostly-blank rolls of yellow paper, too! :)

Gavin Kistner

10/6/2006 1:47:00 PM

0

Martin Coxall wrote:
> > 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".

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.

Carlos

10/6/2006 2:12:00 PM

0

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 Coxall

10/6/2006 2:20:00 PM

0

On 10/6/06, Carlos <angus@quovadis.com.ar> wrote:
> 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"?
>

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

Carlos

10/6/2006 2:34:00 PM

0

Martin Coxall wrote:

> On 10/6/06, Carlos <angus@quovadis.com.ar> wrote:
>
>> 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"?
>>
>
> 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.

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

--



Brian Mitchell

10/6/2006 2:47:00 PM

0

On 10/6/06, Carlos <angus@quovadis.com.ar> wrote:
> 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"?

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.