post inc problem

[Sebestyén Gábor]

Hi,

A quick and dumb question: does Ruby (1.6) support postincrementation
like C++? I mean: " x++ " expression where x is a numeric variable.
Thanks,

Gábor

"Put your message in a modem and throw it in the Cyber Sea." - N. Peart

 

[ES]

Hi,

A quick and dumb question: does Ruby (1.6) support postincrementation
like C++? I mean: " x++ " expression where x is a numeric variable.

Nope; all number variables reference number objects and you can't change
those. You can use:

x += 1
x = x + 1
x = x.succ
x = x.next

Thanks,

Gábor

E

 

[Martin DeMello]

Hi,

A quick and dumb question: does Ruby (1.6) support postincrementation
like C++? I mean: " x++ " expression where x is a numeric variable.

I've written up a wiki page on why it doesn't:
http://www.rubygarden.org/ruby?IncrementOperator

martin

 

[Brian Schröder]

Hi,

A quick and dumb question: does Ruby (1.6) support postincrementation
like C++? I mean: " x++ " expression where x is a numeric variable.
Thanks,

In ruby every operation is a method call. You can make this visible by writing

5.+(5)

So a ++ operation would mean change 5 to be 6. And that would be quite
inconsistent:
Numbers: 1,2,3,4,5,6,7....
5++
Numbers: 1,2,3,4,6,6,7...



So no chance you will ever find r++ in ruby.

hope to help,

Brian

 

[Randy Kramer]

So a ++ operation would mean change 5 to be 6. And that would be quite
inconsistent:
Numbers: 1,2,3,4,5,6,7....
5++
Numbers: 1,2,3,4,6,6,7...

Five introductory remarks: I dislike the ++ operator in C, etc., I don't like
the Perl TIMTOWTDI philosophy (makes it too hard for me to read Perl code,
especially since I gave up on learning Perl), and I don't know how I talked
myself into attempting to learn Ruby which has sometimes been described, in
some sense, as somewhat Perl like, and I'm too much of a newbie in Ruby to
think of the right (best) examples, and I'm not specifically responding to
Brian--I've seen similar answeres to this question a few times on the list,
but:

Doesn't Ruby somewhat pride itself on doing the intuitive thing, sometimes
including (for example) more than one syntax for the same thing to make it
more intuitive for newbies (like the ability to write a "normal looking" for
statement instead of requring the something.each syntax)?

Aren't there other cases somewhat like that--iiuc, a string is normally
mutable but you force it to be non-mutable (with, IIUC, the ! to make
destructive operations (if I have the terminology right)?

Is the "++" syntax used for some other operation, thus precluding its use for
a synonym for increment. And wouldn't the right thing for ++ be to increment
to the next number?

So why did I write this (and, will I press send? clearly, if you're reading
this I did press send)? Am I just ranting? Maybe. Do I really want "++"
added to the Ruby syntax? No, absolutely not!

Ok, maybe I have to go back to one of the statements attributed to Matz,
something like (paraphrased from memory): "I have tried to make Ruby
intuitive for me, I hope it is intuitive for others as well, but" he seems to
make no promises (iirc).

So, maybe I'm trying to come up with another explanation for why "++" will not
be supported in Ruby (with no sarcasm/disrepect intended), and maybe there
are at least two: One is the one mentioned above, that in the existing and
preferred (consistent) syntax of Ruby, ++ woud be interpreted as attempting
to change the object 5 to the object 6, and Matz's world view doesn't see
enough value in the == syntax to make it an exception. (100% fine by me, by
the way.)

So, again, shall I press send? Yes, I think so. I think the extra perspective
of knowing there is a person (at least nominally) in charge who has made a
conscious decision will let me (in my own mind) set the issue to rest. (That
is ignoring all the discussion I see (is that on a different list?) about
requests to change, among other things, the syntax of Ruby.

sorry for the noise,
Randy Kramer

 

[WoNáDo]

I've written up a wiki page on why it doesn't:
http://www.rubygarden.org/ruby?IncrementOperator

martin

The argumentation in your wiki page is much clear - but - I understood the
"x++", "++x", etc.-stuff as an abbreviation that will be inplemented by some
kind of preprocessing (while compiling or in a macro processor step).

 

[Matthias Luedtke]

I've written up a wiki page on why it doesn't:
http://www.rubygarden.org/ruby?IncrementOperator

Hi all...

I've just started getting into the ruby flow. While trying out some
statements from your Tutorial I noticed the following:

irb(main):001:0> s = "foo"
=> "foo"
irb(main):002:0> s.id
(irb):2: warning: Object#id will be deprecated; use Object#object_id
=> 24035848

I assume this warning is correct and I would have changed that right
away in the wiki. But because I am new I thought I'd rather ask first
before producing unnecessary work for anyone ;-)

Matthias

 

[Austin Ziegler]

Aren't there other cases somewhat like that--iiuc, a string is
normally mutable but you force it to be non-mutable (with, IIUC,
the ! to make destructive operations (if I have the terminology
right)?

Is the "++" syntax used for some other operation, thus precluding
its use for a synonym for increment. And wouldn't the right thing
for ++ be to increment to the next number?

This comes up every so often, and as much as it has to do with the
problem of mutating a fixed value (e.g., 5++), it has much more to
do with the understanding of Ruby variables and the true nature of
object orientation in Ruby, as well as operator overriding.

At least, IMO.

There's two ways to implement ++. The first way is to implement it
as an operator, like #+ and #*. Because it is a unary operator, it
would probably be something like:

def @++
# implementation
end

OK. That's fine. That's probably the better way, but then you've got
the question of -- how do you distinguish between prefix and
postfix? So now, you need *two* operators instead of one -- because
you know that people will use both (they have different meanings).
But you have to define both if you want one.

Ouch.

Okay, the other way is as syntax sugar. Define "a++" such that it is
the same as "a += 1". But what if a is a String? Your program blows
up. So we're back to option 1.

-austin

 

[Martin DeMello]

I've just started getting into the ruby flow. While trying out some
statements from your Tutorial I noticed the following:

irb(main):001:0> s = "foo"
=> "foo"
irb(main):002:0> s.id
(irb):2: warning: Object#id will be deprecated; use Object#object_id
=> 24035848

I assume this warning is correct and I would have changed that right
away in the wiki. But because I am new I thought I'd rather ask first
before producing unnecessary work for anyone ;-)

Yes, my mistake Please do change it.

martin

 

[Brian Schröder]

Is the "++" syntax used for some other operation, thus precluding

This comes up every so often, and as much as it has to do with the
problem of mutating a fixed value (e.g., 5++), it has much more to
do with the understanding of Ruby variables and the true nature of
object orientation in Ruby, as well as operator overriding.

At least, IMO.

There's two ways to implement ++. The first way is to implement it
as an operator, like #+ and #*. Because it is a unary operator, it
would probably be something like:

def @++
# implementation
end

OK. That's fine.

Maybe I didn't understand you, but how would such an implementation
look like? The problem as I see it, is that we are sending messages to
the object and not to the variable. So we can't increment the
variable, because we don't know it.

z = y = x = 5 => 5
x.++ => 6

Now which value does z have, and which value does x have?

regards,

Brian

 

[Wolfgang Nádasi-Donner]

--
Wolfgang Nádasi-Donner
(e-mail address removed)

The argumentation in your wiki page is much clear - but - I understood the
"x++", "++x", etc.-stuff as an abbreviation that will be inplemented by some
kind of preprocessing (while compiling or in a macro processor step).

I mean something like this (demonstration only - doesn't make sense in
programming):

class Numeric
def Numeric.spp(symbol)
return "tempsymbol=" + symbol.to_s + ";" + symbol.to_s + "+=1;tempsymbol"
end
def Numeric.pps(symbol)
return symbol.to_s + "+=1"
end
def Numeric.smm(symbol)
return "tempsymbol=" + symbol.to_s + ";" + symbol.to_s + "-=1;tempsymbol"
end
def Numeric.mms(symbol)
return symbol.to_s + "-=1"
end
end

s=6
puts eval(Numeric.spps)) # 6
puts eval(Numeric.spps)) # 7
puts eval(Numeric.spps)) # 8
puts eval(Numeric.spps)) # 9
puts s # 10
puts eval(Numeric.ppss)) # 11
puts eval(Numeric.ppss)) # 12
puts eval(Numeric.ppss)) # 13
puts eval(Numeric.ppss)) # 14
puts s # 14
puts eval(Numeric.smms)) # 14
puts eval(Numeric.smms)) # 13
puts eval(Numeric.smms)) # 12
puts eval(Numeric.smms)) # 11
puts s # 10
puts eval(Numeric.mmss)) # 9
puts eval(Numeric.mmss)) # 8
puts eval(Numeric.mmss)) # 7
puts eval(Numeric.mmss)) # 6
puts s # 6

 

[Austin Ziegler]

Maybe I didn't understand you, but how would such an implementation
look like? The problem as I see it, is that we are sending messages to
the object and not to the variable. So we can't increment the
variable, because we don't know it.

Well, that's part of what I forgot to mention; had a scrum meeting
coming up and forgot to finish the email.

Since Ruby's variables don't actually occupy "space" (as objects do),
then #@++ wouldn't do any good in any case, which leaves you with the
syntax sugar. Maybe a combination, if we really wanted this:

a++ # actually: a = a.@++
++a # actually: a = a.@++@

Or something. But that makes it even less acceptable, as the amount of
magic required to do that is very high.

-austin

 

[Brian Schröder]

Well, that's part of what I forgot to mention; had a scrum meeting

coming up and forgot to finish the email.

Since Ruby's variables don't actually occupy "space" (as objects do),
then #@++ wouldn't do any good in any case, which leaves you with the
syntax sugar. Maybe a combination, if we really wanted this:

a++ # actually: a = a.@++
++a # actually: a = a.@++@

Or something. But that makes it even less acceptable, as the amount of
magic required to do that is very high.

This may be a dumb question, but what is the meaning of the @ in your
expression?

regards,

Brian

 

[ts]

"B" == =?ISO-8859-1?Q?Brian Schr=F6der?= <ISO-8859-1> writes:

B> This may be a dumb question, but what is the meaning of the @ in your
B> expression?

uln% ruby -e 'class A; def +@() "unary operator" end end; puts +A.new'
unary operator
uln%



Guy Decoux

 

[Wolfgang Nádasi-Donner]

Wolfgang Nádasi-Donner
(e-mail address removed)

Well, define it as a += a.succ.

"a=a.succ" or "a+=1"

 

[Brian Schröder]

B> This may be a dumb question, but what is the meaning of the @ in your
B> expression?

uln% ruby -e 'class A; def +@() "unary operator" end end; puts +A.new'
unary operator
uln%

Thank you. I searched in the pickaxe 2, but I couldn't find it.

Brian

 

[furufuru]

A quick and dumb question: does Ruby (1.6) support
postincrementation

I've written up a wiki page on why it doesn't:
http://www.rubygarden.org/ruby?IncrementOperator

Very nice writing. But, the reason why performance reasons require
a Fixnum behave differently from a String isn't clear, in my humble
opinion:

The problem comes down to an implementation detail - for
performance reasons, Fixnums are "immediate values". This means
that all instances of an integer point to the *same object*.

If I remember correctly (which I'm not very sure , Fixnums are
stored _in_ variables, although variables usually _point_to_ objects.
When the least significant bit of the variable is 1, the remaining bits
of the variable represents the value of a Fixnum; when the bit is 0,
the value of the variable is taken to be a pointer to an object. . . .
something along the lines. This implementation choice is for
performance.

Now, we *could* implement a ++ operator for Fixnums: it would simply
increment the value stored _in_ the variable:

x = 1; y = 1
++x # => 2
y # => 1 (unchanged)

This behavior is exactly paralell to that of Strings:

x = "hello"; y = "hello"
x.upcase! # => "HELLO"
y # => "hello" (unchanged)

BUT, allowing a ++ operator would lead to this inconsistency:

x = 1; y = x # the value _in_ x is _copied_into_ y .
++x # => 2
y # => 1 (unchanged, because y has a copy of the original value.)

while

x = "hello"; y = x # y _points_to_ the same object as x does.
x.upcase # => "HELLO"
y # => "HELLO" (because y points to the same object)

So, since Ruby implements Fixnums as in C and Fortran (where variables
_store_ values) for performance reasons, allowing a ++ operator would
lead to inconsistency and confusion.

I think this is a better explanation than saying that a Fixnum is
immutable. We can conceptually _view_ Fixnums as immutable, but that
doesn't explain why that would lead to efficiency (performance).

Regards
Ryo

 

[Guillaume Marcais]

Well, define it as a += a.succ.

I guess you meant: define it as a = a.succ.

I used to miss ++ very much when I started Ruby, but I can't remember
feeling any need for it in the last time.

Same here. ++, -- and the for loop are gone from my mind when I program
in Ruby, and it's good this way.

Guillaume.

 

[Martin DeMello]

If I remember correctly (which I'm not very sure , Fixnums are
stored _in_ variables, although variables usually _point_to_ objects.
When the least significant bit of the variable is 1, the remaining bits
of the variable represents the value of a Fixnum; when the bit is 0,
the value of the variable is taken to be a pointer to an object. . . .
something along the lines. This implementation choice is for
performance.

Good catch. I'm definitely in the wrong there.

Now, we *could* implement a ++ operator for Fixnums: it would simply
increment the value stored _in_ the variable:
[...]

So, since Ruby implements Fixnums as in C and Fortran (where variables
_store_ values) for performance reasons, allowing a ++ operator would
lead to inconsistency and confusion.

I think this is a better explanation than saying that a Fixnum is
immutable. We can conceptually _view_ Fixnums as immutable, but that
doesn't explain why that would lead to efficiency (performance).

The problem, as I see it, is that ++ would have to be not a method but a
'keyword' operator like =, i.e. handled by the interpreter rather than
by a message call to an object. But unlike =, this would *only* apply to
Fixnums, wihch is a glaring asymmetry in the semantics of the language.
We could fix this by defining an Object#succ and having the interpreter
rewrite x++ as x = x.succ (there's even precedent for it - for .. in is
a keyword-level construct that delegates to the #each method, but it'd
still e a mildly ugly special case from a language point of view.

martin

 

[furufuru]

(e-mail address removed)-tokyo.ac.jp wrote: [...]

I think this is a better explanation than saying that a Fixnum is
immutable. We can conceptually _view_ Fixnums as immutable, but
that doesn't explain why that would lead to efficiency
(performance).

The problem, as I see it, is that ++ would have to be not a method
but a 'keyword' operator like =, i.e. handled by the interpreter
rather than by a message call to an object. But unlike =, this would
*only* apply to Fixnums, wihch is a glaring asymmetry in the
semantics of the language.

Yes. I think these are the reasons why Ruby people have adopted the
"illusion" (no derogatory meaning) or view that Fixnums are just
ordianary objects expect they are immutable. As long as you use only
non-destructive methods, you cannot distinguish objects stored in
variables from those pointed to through variables. So, instead of
telling the truth that Fixnums are stored in variables, we assume that
they are conceptually pointed to through variables and they are
immutable. This view is necessary for consistency. But, if we want
to talk about performance, we seem to need to "confess" the truth.

Regards,
Ryo