Should multiple assignment work for the
syntax-sugar “reflexive” operators?
x, y, z = 1, 2, 3
x, y, z += 5 # 6, 7, 8
It’s a philosophical question… obviously
it doesn’t work at the present time.
Maybe there’s a good reason this is not
implemented?
Hal
Hal E. Fulton wrote:
Should multiple assignment work for the
syntax-sugar “reflexive” operators?x, y, z = 1, 2, 3
x, y, z += 5 # 6, 7, 8It’s a philosophical question… obviously
it doesn’t work at the present time.Maybe there’s a good reason this is not
implemented?Hal
Where do you propose we draw the line?
x, y, z = 1, 2, 3
x, y, z += 5 # 6, 7, 8
x, y, z = , ,
x, y, z << nil # [nil], [nil], [nil]
x, y, z == [nil] # [true, true, true]
(x, y, z).method(arg) # hmm…
Hi,
In message “Should this work?” on 02/08/04, “Hal E. Fulton” hal9000@hypermetrics.com writes:
Should multiple assignment work for the
syntax-sugar “reflexive” operators?x, y, z = 1, 2, 3
x, y, z += 5 # 6, 7, 8It’s a philosophical question… obviously
it doesn’t work at the present time.Maybe there’s a good reason this is not
implemented?
It makes Ruby’s syntax more complex. I don’t have any other positive
nor negative attitude about this.
matz.
Hi –
Should multiple assignment work for the
syntax-sugar “reflexive” operators?x, y, z = 1, 2, 3
x, y, z += 5 # 6, 7, 8
It’s too magic for my taste. I’ve always thought of
x += n
as exactly swappable for
x = x + n
(which I think is actually what’s going on underneath…?) and this
would make it pretty impossible to view it that way.
Also, #+ means different things to different objects… so you might
really be calling three entirely different methods. The same thing is
true if you iterate through them explicitly, of course, but for me
personally doing it implicitly is too, ummmm, implicit.
David
On Sun, 4 Aug 2002, Hal E. Fulton wrote:
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav
Should multiple assignment work for the
syntax-sugar “reflexive” operators?x, y, z = 1, 2, 3
x, y, z += 5 # 6, 7, 8
Where do you propose we draw the line?
x, y, z = 1, 2, 3
x, y, z += 5 # 6, 7, 8x, y, z = , ,
x, y, z << nil # [nil], [nil], [nil]x, y, z == [nil] # [true, true, true]
(x, y, z).method(arg) # hmm…
Well, = and += are both considered
assignment operations. That’s enough
rationale (for me) to draw the line
with +=, -=, and the others.
Truthfully, though, some of your constructs
above look almost tempting.
I would not go for ==, but for << and
.method I might be persuaded.
Hal
----- Original Message -----
From: “George Ogata” g_ogata@optushome.com.au
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, August 03, 2002 6:56 PM
Subject: Re: Should this work?
ever felt like that was backward? my first inclination was:
x =+ n.
just an aside.
i have to agree though. never been big on multiple-assignments. they’re
just not as clear (are they faster in anyway?)
On Sun, 2002-08-04 at 06:16, David Alan Black wrote:
It’s too magic for my taste. I’ve always thought of
x += n
as exactly swappable for
x = x + n
–
~transami
From: “George Ogata” g_ogata@optushome.com.au
x, y, z = 1, 2, 3
x, y, z += 5 # 6, 7, 8
Well, = and += are both considered
assignment operations. That’s enough
rationale (for me) to draw the line
with +=, -=, and the others.
There’s a problem: x,y,z=5 assumes 5,nil,nil instead of 5,5,5. So the
other assignment operators would be inconsistent in this regard. IMHO,
“x,y,z += 5,5,5” would be okay, but I will make no effort to push it.
I would not go for ==, but for << and
.method I might be persuaded.
#== and #<< are plain methods. You shouldn’t use method names
to discriminate that kind of behaviour.
[Discussion about += etc. snipped as it’s deallt with by other posts.]
x, y, z = , ,
x, y, z << nil # [nil], [nil], [nil]x, y, z == [nil] # [true, true, true]
(x, y, z).method(arg) # hmm…
Well, = and += are both considered
assignment operations. That’s enough
rationale (for me) to draw the line
with +=, -=, and the others.Truthfully, though, some of your constructs
above look almost tempting.I would not go for ==, but for << and
.method I might be persuaded.Hal
The “almost tempting” options are only a “map” away (I prefer :map over
:collect, but don’t see much code using it…).
[x, y, z].map { |arr| arr << nil } # Can also use :each
[x, y, z].map { |arr| arr == [nil] }
[x, y, z].map { |obj| obj.method(arg) }
Now, I love the “map” method, but sometimes its use is more verbose than it
could be. It “would be nice” if one could do the following things:
names = %w(john mary adam jacky)
names.map { capitalize } # → [“John”, “Mary”, “Adam”, “Jacky”]
x, y, z = , ,
[x, y, z].map { $_ << [nil] } # → [nil, nil, nil]
[x, y, z].map { $_ == [nil] } # → [true, true, true]
Obviously there are limits, but I think that there could be a way to do this
without exposing the language to ambiguity, contradiction, slothfulness or
confused identity (!) The “capitalize” example may be stretching it a bit
far, but surely the other two examples are good?
What do people think?
–Gavin
----- Original Message -----
From: “Hal E. Fulton” hal9000@hypermetrics.com
It’s too magic for my taste. I’ve always thought of
x += n
as exactly swappable for
x = x + n
ever felt like that was backward? my first inclination was:
x =+ n.
just an aside.
That’s the syntax for the original C operators, actually. It was
changed because it was horribly ambiguous. For example, does “x=-x”
mean “x = 0 - x” or “x = x - x”?
On Sun, 2002-08-04 at 06:16, David Alan Black wrote:
i have to agree though. never been big on multiple-assignments. they’re
just not as clear (are they faster in anyway?)–
~transami
–
Paul Duncan pabs@pablotron.org pabs in #gah (OPN IRC)
http://www.pablotron.org/ OpenPGP Key ID: 0x82C29562
There’s a problem: x,y,z=5 assumes 5,nil,nil instead of 5,5,5. So the
other assignment operators would be inconsistent in this regard. IMHO,
“x,y,z += 5,5,5” would be okay, but I will make no effort to push it.
The nil case alone is reason enough to avoid it.
I would not go for ==, but for << and
.method I might be persuaded.#== and #<< are plain methods. You shouldn’t use method names
to discriminate that kind of behaviour.
Good point again.
Hal
----- Original Message -----
From: “Mathieu Bouchard” matju@sympatico.ca
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, August 03, 2002 8:17 PM
Subject: Re: Should this work?
names.map { capitalize } # -> ["John", "Mary", "Adam", "Jacky"]
[x, y, z].map { $_ << [nil] } # -> [nil, nil, nil]
[...]
What do people think?
Have you used a P language ? 
Guy Decoux
What about the following? It’s not quite the same, but less verbose
than map itself:
module Enumerable
def mapsend( method, *args )
map { | target | target.send( method, *args ) }
end
end
names = %w(john mary adam jacky)
names.mapsend( :capitalize ) # → [“John”, “Mary”, “Adam”,
“Jacky”]
x, y, z = , ,
[x, y, z].mapsend( :<<, nil ) # → [[nil], [nil], [nil]]
[x, y, z].mapsend( :==, [nil] ) # → [true, true, true]
Regards,
Pit
On 4 Aug 2002, at 22:31, Gavin Sinclair wrote:
(…)
Now, I love the “map” method, but sometimes its use is more verbose
than it could be. It “would be nice” if one could do the following
things:names = %w(john mary adam jacky)
names.map { capitalize } # → [“John”, “Mary”, “Adam”,
“Jacky”]x, y, z = , ,
[x, y, z].map { $_ << [nil] } # → [nil, nil, nil]
[x, y, z].map { $_ == [nil] } # → [true, true, true]Obviously there are limits, but I think that there could be a way to
do this without exposing the language to ambiguity, contradiction,
slothfulness or confused identity (!) The “capitalize” example may be
stretching it a bit far, but surely the other two examples are good?What do people think?
You can add something like that yourself:
module Enumerable
def map(a=nil,&b)
r=
each(&(if a
then proc {|v| r << (v.send a) }
else proc {|v| r << (b.call v) } end))
r end end
names = %w(john mary adam jacky)
names.map :capitalize #==> [“John”, “Mary”, “Adam”, “Jacky”]
Here’s something else for you:
class Many
def initialize(*a)
@a=a end
def method_missing(*m,&b)
@a.each {|e| e.send(*m,&b) } end end
def M(*a)
Many.new(*a) end
M(a=,b=[42]) << “hello”
p a #==> [“hello”]
p b #==> [42,“hello”]
On Sun, 4 Aug 2002, Gavin Sinclair wrote:
Now, I love the “map” method, but sometimes its use is more verbose than it
could be. It “would be nice” if one could do the following things:
names = %w(john mary adam jacky)
names.map { capitalize } # → [“John”, “Mary”, “Adam”, “Jacky”]
Mathieu Bouchard http://artengine.ca/matju
A “Perl” language? Yes. I’m not very proficient, because it seems
practically impossible to do anything in Perl and remain sane. However, it
is a very clever, creative, quirky and interesting language. Some of the
solutions in “The Perl Cookbook” are remarkable for their elegance.
However, that elegance is “read-only”. Mere mortals cannot usually know
what magic Perl interpreter will accept.
In short, I love Perl, but never use it.
Anyway, despite all that, my affection for the
[x, y, z].map { $_ << [nil] } # → [nil, nil, nil]
construct is based not on Perl (despite the $_), but on Miranda (similar to
Haskell). For example:
fib n = # Definition of Fibonacci sequence
map fib [1…10] # → [1, 1, 2, 3, 5, 8, 13, 21, 34, 55]
In Ruby, since :map/:collect most commonly takes only one parameter in the
block, it could be unambiguously shortcut using a magic local variable. I
definitely think my “capitalize” example was overdoing it, as it relies on
dodgy Perl $_ overuse, rather than plain old functional programming.
–Gavin
----- Original Message -----
From: “ts” decoux@moulon.inra.fr
[x, y, z].map { $_ << [nil] } # → [nil, nil, nil]
[…]
What do people think?
Have you used a P language ?
Guy Decoux
Hi –
On Sun, 4 Aug 2002, Pit Capitain wrote:
What about the following? It’s not quite the same, but less verbose
than map itself:module Enumerable
def mapsend( method, *args )
map { | target | target.send( method, *args ) }
end
endnames = %w(john mary adam jacky)
names.mapsend( :capitalize ) # → [“John”, “Mary”, “Adam”,
“Jacky”]x, y, z = , ,
[x, y, z].mapsend( :<<, nil ) # → [[nil], [nil], [nil]]
[x, y, z].mapsend( :==, [nil] ) # → [true, true, true]
This is similar to (rejected) RCR 50. Which doesn’t mean you
shouldn’t write and use it if you want I just wanted to point out
that there’s some possibly useful discussion of it at Ruby Garden:
http://www.rubygarden.org/article.php?sid=127.
David
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav
Interesting, thanks.
Gavin
----- Original Message -----
From: “Mathieu Bouchard” matju@sympatico.ca
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Monday, August 05, 2002 1:47 AM
Subject: Re: Should this work?
On Sun, 4 Aug 2002, Gavin Sinclair wrote:
Now, I love the “map” method, but sometimes its use is more verbose than
it
could be. It “would be nice” if one could do the following things:
names = %w(john mary adam jacky)
names.map { capitalize } # → [“John”, “Mary”, “Adam”, “Jacky”]You can add something like that yourself:
module Enumerable
def map(a=nil,&b)
r=
each(&(if a
then proc {|v| r << (v.send a) }
else proc {|v| r << (b.call v) } end))
r end endnames = %w(john mary adam jacky)
names.map :capitalize #==> [“John”, “Mary”, “Adam”, “Jacky”]Here’s something else for you:
class Many
def initialize(*a)
@a=a end
def method_missing(*m,&b)
@a.each {|e| e.send(*m,&b) } end end
def M(*a)
Many.new(*a) endM(a=,b=[42]) << “hello”
p a #==> [“hello”]
p b #==> [42,“hello”]
Mathieu Bouchard http://artengine.ca/matju
In Ruby, since :map/:collect most commonly takes only one parameter in the
block, it could be unambiguously shortcut using a magic local variable.
#collect is a method of Enumerable and call #each, for example
pigeon% ruby -e 'a = {1 => 2}; a.collect {|x, y| p x, y}'
1
2
pigeon%
Apparently you want a "magic" local variable for the block do ... end and
not for #collect
Guy Decoux