Ruby doesn't implement x++ for Fixnum's because ???

[Robert Klemme]

Wouldn't it be cool if ruby had macros?

No.

 

[Gavin Sinclair]

There's really no reason it shouldn't be added [...]

There's no reason it _should_ be added. That's the reason it
shouldn't be.

I have seen no convincing argument as to why ++ is not supported in Ruby.

You've got the onus the wrong way around.

And adding C-like operators based on a partiular assembly language to
any 21st century language, especially a high-level one, just seems
absurd!

Extra documentation so we can save three characters (a++ instead of a
+= 1) in a rare use case? No thanks!

 

[David A. Black]

Hi --

Of course I had to jump in here.

Yes, a++ and ++a could easily be rewritten by the parser into the
appropriate increment+set of a and the expression either returns the
incremented value or the non-incremented value. And I would like to
see that added. It doesn't fundamentally change the expectations of
the programmer, and it provides a one-character-shorter version of
a+=1. There's really no reason it shouldn't be added, because even in
Java or C, you are *never* modifying arbitrary references to that
value...you are *always* re-assigning the value a given variable
points to.

This example:

a = 1
b = a
a++

Would cause exactly the same results in every language I've worked
with...b would be 1 and a would be 2. The ++ operator never modifies a
value, it modifies what value the variable has assigned to it. If it
were modifying a value, then using ++ to bump a pointer through memory
offsets would have horrible side effects for anyone else assigned that
pointer value.

I have seen no convincing argument as to why ++ is not supported in Ruby.

It would, I think, be quite anomalous, since it would be the only case
(that I can think of anyway) of an assignment expression that didn't
look and feel like an assignment expression.

I'm also not sure what problem it would be solving, other than adding
to the "make <language> users feel at home in Ruby" effect. But I tend
to think that Ruby should move away from, not towards, doing things
for exclusively that reason.


David

--
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Robert Klemme]

Hi --



It would, I think, be quite anomalous, since it would be the only case
(that I can think of anyway) of an assignment expression that didn't
look and feel like an assignment expression.

I'm also not sure what problem it would be solving, other than adding
to the "make <language> users feel at home in Ruby" effect. But I tend
to think that Ruby should move away from, not towards, doing things
for exclusively that reason.

+2 (Thanks for the well formulated reasoning, David!)

Kind regards

robert

 

[Rick DeNatale]

Of course I had to jump in here.

Yes, a++ and ++a could easily be rewritten by the parser into the
appropriate increment+set of a and the expression either returns the
incremented value or the non-incremented value. And I would like to
see that added. It doesn't fundamentally change the expectations of
the programmer, and it provides a one-character-shorter version of
a+=1. There's really no reason it shouldn't be added, because even in
Java or C, you are *never* modifying arbitrary references to that
value...you are *always* re-assigning the value a given variable
points to.

This example:

a = 1
b = a
a++

Would cause exactly the same results in every language I've worked
with...b would be 1 and a would be 2. The ++ operator never modifies a
value, it modifies what value the variable has assigned to it. If it
were modifying a value, then using ++ to bump a pointer through memory
offsets would have horrible side effects for anyone else assigned that
pointer value.

I have seen no convincing argument as to why ++ is not supported in Ruby.

Certainly it could be implemented in an extension to the language as
syntactic sugar much as += and it's family.

But I maintain, that it can't be implemented as a method, any more
than += or ||= could be.

If Matz deigned to do such a language change, I'd certainly feel free
to ignore it. <G>

I can't help but think of Alan Perlis' quip that "syntactic sugar
causes cancer of the semicolons"

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Marnen Laibow-Koser]

Rick Denatale wrote:
[...]

Certainly it could be implemented in an extension to the language as
syntactic sugar much as += and it's family.

But I maintain, that it can't be implemented as a method, any more
than += or ||= could be.

I believe you are quite wrong. If a destructive function like gsub! can
be implemented as a method, then I see no reason that +=, |=, or postfix
++ couldn't be.

If Matz deigned to do such a language change, I'd certainly feel free
to ignore it. <G>

Well, as others have pointed out, Ruby's preference for iterators rather
than loops makes ++ a lot less useful. I use it a lot in PHP, but I
really haven't missed it in Ruby.

I can't help but think of Alan Perlis' quip that "syntactic sugar
causes cancer of the semicolons"

Cute. Of course, at some level, every programming language is syntactic
sugar...

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

Best,

 

[Seebs]

I believe you are quite wrong. If a destructive function like gsub! can
be implemented as a method, then I see no reason that +=, |=, or postfix
++ couldn't be.

gsub! is implemented as a method on objects which contain data. ++ would
have to be implemented as a method on objects which ARE their data -- which
have no distinction between the object and its "contents".

gsub! can work because somewhere inside the object there is a hunk of storage
which is separate from the object itself. Fixnum has no such storage to
refer to.

-s

 

[lith]

gsub! can work because somewhere inside the object there is a hunk of sto=
rage

which is separate from the object itself. =A0Fixnum has no such storage t= o
refer to.

I don't think ruby makes the distinction between native types &
objects =E0 la java. I don't know the ruby source but from a glance at
numeric.c[1], I'd say it is handled as VALUE/ruby object like any
other object. All those numeric methods seem to convert the VALUE to c
numbers, do what they are supposed to do and then convert them back
again. Please correct me if I'm wrong and if you know the ruby source
code.

I don't think ruby is in need of such an operator but I don't see why
ruby shouldn't have macros to let people fake such a thing if they
deem it necessary.


[1] http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/numeric.c?view=3Dmark=
up

 

[Seebs]

I don't think ruby makes the distinction between native types &
objects à la java.

Everything is an object.

Not every object contains separate storage.

When you write "a = 1; b = 1;", a and b do not refer to two separate objects
which happen to have the same numeric value; they refer to a single object
which has an immutable numeric value. You can't increment that value.

-s

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

You've got the onus the wrong way around.

And adding C-like operators based on a partiular assembly language to
any 21st century language, especially a high-level one, just seems
absurd!

Extra documentation so we can save three characters (a++ instead of a
+= 1) in a rare use case? No thanks!

I think you're missing why ++ could be useful, and it's precisely because
Ruby is a "21st century language"

The ++ operator, far more than just being syntactic sugar for +=1, would
allow you to send an "increment" message to any object, which would change
its value in place, i.e.

def ++
incrementing_logic_goes_here
end

I could see this as being handy

 

[Martin DeMello]

The ++ operator, far more than just being syntactic sugar for +=1, would
allow you to send an "increment" message to any object, which would change
its value in place, i.e.

And how exactly would you change the value of 1 in place?

martin

 

[RichardOnRails]

Hi --










It would, I think, be quite anomalous, since it would be the only case
(that I can think of anyway) of an assignment expression that didn't
look and feel like an assignment expression.

I'm also not sure what problem it would be solving, other than adding
to the "make <language> users feel at home in Ruby" effect. But I tend
to think that Ruby should move away from, not towards, doing things
for exclusively that reason.

David

--
The          Ruby training with D. Black, G. Brown, J.McAnally
Compleat     Jan 22-23, 2010, Tampa, FL
Rubyist      http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

Hi --










It would, I think, be quite anomalous, since it would be the only case
(that I can think of anyway) of an assignment expression that didn't
look and feel like an assignment expression.

I'm also not sure what problem it would be solving, other than adding
to the "make <language> users feel at home in Ruby" effect. But I tend
to think that Ruby should move away from, not towards, doing things
for exclusively that reason.

David

Hi David,

First, Thank you for The Well-Grounded Rubyist. I study like other
pour over scriptures or the Koran. Your topics are well chose,
beautifully explicated. And Manning adding typesetting that enhanced
the your work.

I started this thread because some of your comments on page 54, e.g.
"The un-reference ..." were a blemish among your excellent analyses.
The fact that Robert Klemme, whom I also respect highly as a Rubyist,
agrees with you gives me pause.

But nevertheless, I maintain that my corrected post of today refutes
such claims as "... any object that's represented as an immediate
value is always the same object." Russel & Whitehead dealt with this
kind of issue perhaps a century ago when the defined the first Natural
Number, 1, as "the set of all sets that are in one-to-one
correspondence with the set containing the Null Set." Plato dealt with
this in The Parable of the Caves" with the claim that allegedly
concrete things were merely reflections of the "real" objects.

I'm not clamoring for a Ruby implementation. I only posted my
analysis on this issue to get other people's opinions. And I find it
hard compose a mistake free exposition, e.g. the last code lines in
yesterday evening's post:

a = 2**30-1; show (a) => Got 1073741823; class = Fixnum; object_id
= 2147483647; v >> 1 = 1073741823
a = 2**30; show (a) => Got 1073741824; class = Bignum; object_id =
22737670; v >> 1 = 11368835

should have read:

a = 2**30-1; show (a) => Got 1073741823; class = Fixnum; object_id
= 2147483647; v >> 1 = 1073741823
show(a.pp) => Got 1073741824; class = Bignum; object_id =
22738520; v >> 1 = 11369260 # Of course, "v >> 1" is irrelevant
here

to make the point that "pp" crossed the Fixnum/Bignum boundary
smoothly.

Bottom line: Please keep up you great work! I appreciate it very
much!

Best wishes,
Richard

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

And how exactly would you change the value of 1 in place?

You don't. Are you insinuating the behavior of Fixnums isn't already
special cased to begin with?

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

And how exactly would you change the value of 1 in place?

Another way to look at it: does Fixnum#+ change the value of its receiver?

 

[Paul Smith]

You don't. =A0Are you insinuating the behavior of Fixnums isn't already
special cased to begin with?

a =3D 1

a.class #Fixnum

a++ # a is now 2

1.class #Fixnum

1++ # Illegal

So although a is a Fixnum, and 1 is a Fixnum, they respond to ++ differentl=
y?



--=20
Paul Smith
http://www.nomadicfun.co.uk

(e-mail address removed)

 

[RichardOnRails]

gsub! is implemented as a method on objects which contain data.  ++ would
have to be implemented as a method on objects which ARE their data -- which
have no distinction between the object and its "contents".

gsub! can work because somewhere inside the object there is a hunk of storage
which is separate from the object itself.  Fixnum has no such storage to
refer to.

-s

Not true. Check out the following, step by step:

def show(v)
"Got #{v}, class = #{v.class}, object_id = #{v.object_id}
(v.object_id-1)/2 = #{(v.object_id-1)/2 }"
end

class Fixnum
def pp # We can’t define ++ because of a compiler restriction.
self + 1
end
end

These lines show that a & b values are stored in there object_ids held
in the symbol table.
Don’t believe it? Read more.
a = 1; show (a) => Got 1; class = Fixnum; object_id = 3; v >>1
= 1
b = 1; show (b) => Got 1; class = Fixnum; object_id = 3; v >>1
= 1
a == b => true

Appending these lines shows that a & b values are distinct.
That is, after incrementing, a =2, b is unchanged; b is not
impacted by a’s change
a += 1; show (a) => Got 2; class = Fixnum; object_id = 5; v >> 1
= 2
show (b) => Got 1; class = Fixnum; object_id = 3; v >> 1 = 1

Appending these lines shows the ++’s alias pp works just find
a=1; show(a.pp) => Got 2; class = Fixnum; object_id = 5; v >>1
= 2
show(b) => Got 1; class = Fixnum; object_id = 3; v >> 1 = 1

Appending these lines show that ++ crosses the Fixnum/Bignum boundary
a = 2**30-1; show (a) => Got 1073741823; class = Fixnum; object_id
= 2147483647; v >> 1 = 1073741823
show(a.pp) => Got 1073741824; class = Bignum; object_id =
22738520; v >> 1 = 11369260 # “v >> 1” is irrelevant, of course.

Do you agree?

Best wishes,
Richard

 

[Seebs]

class Fixnum
def pp # We can?t define ++ because of a compiler restriction.
self + 1
end
end

This doesn't seem to do the right thing.

a = 1
a.pp

Is a now 2? If not, you haven't implemented an increment operator.

Appending these lines shows that a & b values are distinct.
That is, after incrementing, a =2, b is unchanged; b is not
impacted by a?s change
a += 1; show (a) => Got 2; class = Fixnum; object_id = 5; v >> 1
= 2
show (b) => Got 1; class = Fixnum; object_id = 3; v >> 1 = 1

Right. You've changed which object a refers to, because you've reassigned
a.

Appending these lines shows the ++?s alias pp works just find
a=1; show(a.pp) => Got 2; class = Fixnum; object_id = 5; v >> 1
= 2
show(b) => Got 1; class = Fixnum; object_id = 3; v >> 1 = 1

Not the same. The key is that, after "a += 1", not only do you get 2,
but a is now 2.

Do you agree?

No.

For "a.pp" to be the same as a++ in other languages, you'd have to do:

a = 1; a.pp; show(a) => Got 2



If you don't get a "2" by using a.pp, it's not an increment, just a "one
more than".

Consider a loop:

a = 1
while ((a += 1) < 10) do
puts a
end

Now, try:

a = 1
while (a.pp < 10) do
puts a
end

Doesn't do the same thing.

-s

 

[Walton Hoops]

-----Original Message-----

From: (e-mail address removed) [mailto:[email protected]] On Behalf Of Tony
Arcieri
wrote:
I think you're missing why ++ could be useful, and it's precisely
because
Ruby is a "21st century language"

The ++ operator, far more than just being syntactic sugar for +=1,
would
allow you to send an "increment" message to any object, which would
change
its value in place, i.e.

def ++
incrementing_logic_goes_here
end

I could see this as being handy

But you already can with the mechanics of the language that are already
present!

irb(main):003:0> i=15
=> 15
irb(main):004:0> i=i.succ
=> 16
irb(main):005:0> i="15"
=> "15"
irb(main):006:0> i=i.succ
=> "16"
irb(main):007:0> i=1.2
=> 1.2
irb(main):008:0> i=i.succ
NoMethodError: undefined method `succ' for 1.2:Float
from (irb):8
from /usr/local/bin/irb:12:in `<main>'

In an object that it makes sense to increment, define the #succ method!
It's that easy!

 

[Martin DeMello]

You don't. =A0Are you insinuating the behavior of Fixnums isn't already
special cased to begin with?

yes, i see your point, but consider:

a =3D Foo.new()
b =3D a
c =3D 42
d =3D c
a++
p b
c++
p d

martin

 

[Aldric Giacomoni]

BTW, I'm not advocating x++ for Ruby. I'm just trying to understand
whether Ruby would literally change 1 to 2 as opposed to change a
variable that contains 1 to subsequently contain 2.

I am confused.
irb(main):001:0> 1.succ
=> 2
irb(main):002:0> 1.object_id
=> 3
irb(main):003:0> 1.succ.object_id
=> 5
irb(main):004:0>

Is that good enough? If not, I'd recommend taking a look at...
irb(main):004:0> 1.class
=> Fixnum

Fixnum .. Fixed number?