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

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.

- Charlie

Yes, a++ and ++a could easily be rewritten by the parser into the
appropriate increment+set of a and the expression

Wouldn't it be cool if ruby had macros?

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!

···

On Nov 4, 5:58 pm, Charles Oliver Nutter <head...@headius.com> wrote:

--
Gavin Sinclair

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

···

On Wed, 4 Nov 2009, Charles Oliver Nutter wrote:

--
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)

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"

···

On Wed, Nov 4, 2009 at 1:58 AM, Charles Oliver Nutter <headius@headius.com> wrote:

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.

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

No.

···

2009/11/4 lith <minilith@gmail.com>:

Yes, a++ and ++a could easily be rewritten by the parser into the
appropriate increment+set of a and the expression

Wouldn't it be cool if ruby had macros?

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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

Kind regards

robert

···

2009/11/4 David A. Black <dblack@rubypal.com>:

Hi --

On Wed, 4 Nov 2009, Charles Oliver Nutter wrote:

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.

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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,

···

--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
--
Posted via http://www.ruby-forum.com/\.

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

···

On Wed, Nov 4, 2009 at 3:55 AM, Gavin Sinclair <gsinclair@gmail.com> wrote:

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!

--
Tony Arcieri
Medioh/Nagravision

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

···

On Nov 4, 7:14 am, "David A. Black" <dbl...@rubypal.com> wrote:

Hi --

On Wed, 4 Nov 2009, Charles Oliver Nutter wrote:
> 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)

On Nov 4, 7:14 am, "David A. Black" <dbl...@rubypal.com> wrote:

Hi --

On Wed, 4 Nov 2009, Charles Oliver Nutter wrote:
> 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

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

···

On 2009-11-04, Marnen Laibow-Koser <marnen@marnen.org> wrote:

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.

--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
| Seebs.Net <-- lawsuits, religion, and funny pictures
Fair game (Scientology) - Wikipedia <-- get educated!

Hi,

···

In message "Re: Ruby doesn't implement x++ for Fixnum's because ???" on Wed, 4 Nov 2009 23:31:46 +0900, Marnen Laibow-Koser <marnen@marnen.org> writes:

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.

Only if you accept the language that can change the value of 1 to 2.
I don't.

              matz.

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

martin

···

On Wed, Nov 4, 2009 at 10:41 PM, Tony Arcieri <tony@medioh.com> wrote:

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.

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!

···

-----Original Message-----
From: bascule@gmail.com [mailto:bascule@gmail.com] 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

What's wrong with

  def inc
    incrementing_logic_goes_here
  end

How is that any different?

···

On Nov 5, 4:11 am, Tony Arcieri <t...@medioh.com> 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

It can be done, if you are willing to make your numbers mutable:

class MutableNum
   def initialize n
     @n = n
   end

   def pp
     @n += 1
     @n - 1
   end

   def method_missing symbol, *args
     @n.method(symbol).call(*args)
   end

   def to_s
     @n.to_s
   end
end

a = MutableNum.new 1
puts a.pp #=> 1
puts a #=> 2

Having said that, I agree with others that the post-increment operator is not needed in Ruby at all.

···

On 05/11/2009, at 1:31 AM, Marnen Laibow-Koser wrote:

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.

--
Tobias Cohen

Hi --

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.

Thanks!

I started this thread because some of your comments on page 54, e.g.
"The un-reference ..." were a blemish among your excellent analyses.

Oh dear -- the whole thread is my fault? :slight_smile:

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."

I'm afraid I don't see the refutation, but as per my previous post,
the immediate value thing is only part of the picture.

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.

Well... any given system of symbolic representation may or may not
take a Platonic view of things. Plato's allegory is of course of great
importance in the history of thought, but it doesn't really dictate
that 2000+ years later, there can't be a computer language with
identifiers housing immediate values :slight_smile:

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.

You'll see a lot of people cutting-and-pasting entire shell sessions,
like this:

$ cat myfile.rb
... code here ...

$ ruby myfile.rb
... output here ...

which is a good way to ensure that your output is from your input. I
rely a lot (depending on the example) on pasting things in and out of
irb.

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

I'll do me best :slight_smile:

David

···

On Thu, 5 Nov 2009, RichardOnRails wrote:

--
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)

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.

I don't think ruby makes the distinction between native types &
objects à 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=markup

Hmph. Fortran can change constants, why's Ruby so much less powerful?

:slight_smile:

-s
p.s.: Thanks much for providing such an enjoyable language.

···

On 2009-11-04, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

In message "Re: Ruby doesn't implement x++ for Fixnum's because ???" > on Wed, 4 Nov 2009 23:31:46 +0900, Marnen Laibow-Koser <marnen@marnen.org> writes:

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.

Only if you accept the language that can change the value of 1 to 2.
I don't.

--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
| Seebs.Net <-- lawsuits, religion, and funny pictures
Fair game (Scientology) - Wikipedia <-- get educated!

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

···

On Wed, Nov 4, 2009 at 10:23 AM, Martin DeMello <martindemello@gmail.com>wrote:

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

--
Tony Arcieri
Medioh/Nagravision