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

Ruby
21

On Tue, Nov 3, 2009 at 10:30 PM, Michael W. Ryder
[email protected]wrote:

Maybe I am missing something

Yes, maybe you’re missing that I support a unary ++ operator :slight_smile:

I can see the wisdom in not having it there to begin with though. I see
the
++ operator as something almost inextricably tied to for loops in C.
Ruby
provides better looping mechanisms, like the various Enumerable methods
that
take blocks! Perhaps Matz didn’t include a unary ++ operator as
encouragement to use better looping constructs in your code. If that’s
the
case, I think he certainly succeeded.

22

On Nov 4, 5:58 pm, Charles Oliver N. [email protected] wrote:

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!

23

Hi –

On Wed, 4 Nov 2009, Charles Oliver N. wrote:

points to.
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 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)

24

2009/11/4 David A. Black [email protected]:

Hi –

On Wed, 4 Nov 2009, Charles Oliver N. 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 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

25

2009/11/4 lith [email protected]:

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?

No.

26

On Wed, Nov 4, 2009 at 1:58 AM, Charles Oliver N.
[email protected] wrote:

points to.
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.

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

27

On 2009-11-04, Marnen Laibow-Koser [email protected] 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.

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

28

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

29

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.

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
[email protected]

30

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
[email protected] 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.
31

On 2009-11-04, lith [email protected] wrote:

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.

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

32

On 2009-11-04, Yukihiro M. [email protected] 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 [email protected] 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.

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.

33

On Wed, Nov 4, 2009 at 3:55 AM, Gavin S. [email protected]
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!

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

34

On Nov 4, 7:14 am, “David A. Black” [email protected] wrote:

see that added. It doesn’t fundamentally change the expectations of
a++
It would, I think, be quite anomalous, since it would be the only case
–
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” [email protected] wrote:

see that added. It doesn’t fundamentally change the expectations of
a++
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 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 K., 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 = 230-1; show (a) => Got 1073741823; class = Fixnum; object_id
= 2147483647; v >> 1 = 1073741823
a = 230; 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

35

On Wed, Nov 4, 2009 at 10:23 AM, Martin DeMello
[email protected]wrote:

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?

36

On Wed, Nov 4, 2009 at 10:23 AM, Martin DeMello
[email protected]wrote:

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?

37

On Wed, Nov 4, 2009 at 10:41 PM, Tony A. [email protected] 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.

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

martin

38

On Wed, Nov 4, 2009 at 6:16 PM, Tony A. [email protected] wrote:

On Wed, Nov 4, 2009 at 10:23 AM, Martin DeMello [email protected]wrote:

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?

a = 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 ++
differently?

–
Tony A.
Medioh/Nagravision

–
Paul S.
http://www.nomadicfun.co.uk

[email protected]

39

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’

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

40

On Wed, Nov 4, 2009 at 11:46 PM, Tony A. [email protected] wrote:

On Wed, Nov 4, 2009 at 10:23 AM, Martin DeMello [email protected]wrote:

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?

yes, i see your point, but consider:

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

martin