# RCR again (Integer#succ!, Integer#pred!)

I am definitely in an RCR mood

Well as I was reading the archives and Jim W.'s guidlines I saw an
accepted RCR for Integer#odd? Integer#even?
I always define Integer#pred for myself it seems so trivial that I did
not
bother the list on purpose
I filed the RCR right away.
Sorry for breaking the rule it seemed appropriate.

But I was considering a second RCR and this one does by no means allow
not
to consult the community.

I would also like to have
Integer#pred! and Integer#succ! doing the āobviousā of course.

x = 41
x.succ! => 42
x => 42

What do you think ?

Cheers
Robert

On Jan 12, 2007, at 12:06 PM, Robert D. wrote:

I always define Integer#pred for myselfā¦

What does pred stand for? I must be slow today.

I would have used prev for previous.

James Edward G. II

Gregory B. wrote:

On 1/12/07, Robert D. [email protected] wrote:

x = 41
x.succ! => 42
x => 42

This is probably in the same vein as ++.

I donāt like it because since integers are immediate values in ruby,
that looks messy.

I know, I know - itās pretty radical, but itās 2007. I think weāre

Regards,

Dan

PS - Evan P. did this for Sydney, so itās possible. Evan, got a
parse.y patch for us?

On 1/12/07, Robert D. [email protected] wrote:

x = 41
x.succ! => 42
x => 42

This is probably in the same vein as ++.

I donāt like it because since integers are immediate values in ruby,
that looks messy.

On Sat, Jan 13, 2007 at 03:25:06AM +0900, Daniel B. wrote:

I donāt like it because since integers are immediate values in ruby,
that looks messy.

I know, I know - itās pretty radical, but itās 2007. I think weāre

Maybe x++. Iām pretty sure it canāt be a method.
consider x.method(:succ!), letting x fall out of scope and then
invoking #call on that method. Ruby would have to realize it would need
to make a closure (unless we just had no unboxed values).

Hi ā

On Sat, 13 Jan 2007, Daniel B. wrote:

I donāt like it because since integers are immediate values in ruby,
that looks messy.

I know, I know - itās pretty radical, but itās 2007. I think weāre

Even when itās 2007++ integers will still be immutable, immediate
values I much prefer having people have to learn that thatās how
Ruby integers are.

David

On Jan 12, 2007, at 1:04 PM, Martin DeMello wrote:

On 1/13/07, James Edward G. II [email protected] wrote:

On Jan 12, 2007, at 12:06 PM, Robert D. wrote:

I always define Integer#pred for myselfā¦

What does pred stand for? I must be slow today.

predecessor, by symmetry with successor

Duh. Thank you.

James Edward G. II

On 1/14/07, Gavin K. [email protected] wrote:

Do not worry this is PL so the ML conventions do not apply.

Just a few quick replies:

1. Re the RCR - I should have been more clear; I was referring to the RCR
you filed (#pred) not the proposed one (#succ! and #pred!). I agree that
itās totally subjective as to what is ācompellingā for the core or not; I
was just commenting that there didnāt seem to be any argument at all in the
RCR you file.

Ah that comes quite as a big surprise to me, there were two RCRs about
Integer#odd? and Integer#even? that were accepted by Matz without a
single
line of discussion, he likes it (I like it too BTW).
I think that instead of creating two new methods adding the symetrical
for
an existing that is #succ would be even more obviously a good idea and
really did not want to bother the community with it.
Saying that now, Icould have bothered the community with it instead of
the
#pred!, #succ! which is really stupid stuff, I will elaborate belowā¦

Therefore I more or less copied the reasoning and format of the accepted
RCRs to the #pred RCR. I felt like somebody doing work so obvious that
nobody would do it because it was obvious.
(Just a little pun to recent discussions: maybe I should file an English
Change Request to add a ! to obvious as oubviously obvious is a
dangerous
word)

Maybe that explains why I was very lazy about that one.
Did I read you correctly that you do not feel that adding Integer#pred
as a
symetrie to Integer#succ would be improving the orthogonality of Ruby (I
put
it in a simpler way in the RCR, a ānaiveā user would expect it to exist
after having seen succ for the first time, would she not?)

mailing list interesting. As an anecdote, I was a web designer in my
previous job. For a long time we struggled with how to present designs to a
client. On the one hand, the design ought to speak for itself; if it used
blue and gold to appeal to a rich old male demographic, then the client
ought to automatically get a sense that the design was appropriate for the
target audience just by looking at it. On the other hand, explicitly listing
all the design decisions and implications of them was usually more succesful
at selling the design as a good one to the client. I was always torn on the
issue, and see the parallel here.

I am a very bad communicator, I know lots of things in theory and
miserably
fail to apply it, slightly simplified: I never really learned to
listen.
That is bad, but I try to compensate by staying calm when people are
harsh
to me, I know it might be my faultā¦
Nevertheless integerated into a team I can do quite a little bit, if you
want to convince someone of something there is only one way, make her
(yes I
am married that it was her idea. Not easy a task though.

1. Perhaps its my mental model and not Rubyās at fault here, but I donāt
see

how Ruby can be made to do what you suggest.

Me neither now, I was completely forgetting that x=42, y=42, x and y
reference the same object. I did not want to change 42 of course (you
see
but nobody could know after what I had written).

I can absolutely see that it would be possible to add āx++ā as syntax
sugar

that is interpretted as ā_tmp = x; x = x + 1; _tmpā.

Sure but I did not want to suggest that

I can further see that (as a pure syntax change) you could change the

interpretter to treat āx.succ!ā specially, as a syntax shortcut (and not a
method call at all).

And that would be most ugly and inconsistent and I love consistency,
there
would not be any support for this, given the discussion on the ML.

However, in Ruby, variables do not contain values, they /reference/
objects.

(Forgive me if you already know this.) When you do:

I forgive you I wrote some stupid stuff not thinking about what I know
Ruby. I wanted the object x references being changed without being
changed
elsewhere.

There would be an implementation but I think it would be a performance
nightmare. Make Integers mutable objects that are cloned on write.
Just for the sake of theory:

``````x=42  (x.object_id = 85)
y=43 (y.object_id=87)
x.succ! (x.object_id=0x2389f0d0) a clone of 42 is created and
``````

modifed
x== 43 && x==y (true)

No there is no need for that.

x = Foo.new

then the āxā variable is pointing to the instance of the Foo class. When
you do āy=xā then the āyā variable is set to point to that same instance in
memory. When you then do āx.barā you are invoking the bar method with the
self not set to āxā, but to that instance in memory. When the method call
occurs, you lose all information about what variable (or array slot, or hash
value, etc.) you were talking about.

Sorry that I wasted your time but I appreciate the time you have taken
anyway.

I hope that was clear. I suppose what Iām saying is:

āThereās no way without drastically changing the core of Ruby to implement
succ! as a method of the Fixnum or Integer classes. It could be treated
specially by changing the parser to treat it as syntax; I would personally
be very against implementing anything that looks like a method call
(particular a method with a name, and not an operator) as syntax.ā

Absolutely

And finally: I have absolutely no objection if you want to post my
original

Have a good day, and I do appreciate discussions on how to improve Ruby.

I will definitely put this stuff to the ML you have been most kind
taking
all this timeā¦

Cheers
Robert

Hi ā

On Sat, 13 Jan 2007, Phrogz wrote:

that it could be added to Ruby without violating the immutable
objects.

I donāt think thatās ever been in doubt (that the parser could be
trained to turn x++ into x += 1). But the reason Matz has always
given for not considering it appropriate is that in languages where
itās used it customarily indicates incrementation, rather than
reassignment to a variable. So using it for assignment would

David

Hi ā

On Sat, 13 Jan 2007, Robert D. wrote:

to consult the community.

I would also like to have
Integer#pred! and Integer#succ! doing the āobviousā of course.

x = 41
x.succ! => 42
x => 42

What do you think ?

I donāt consider that obvious at all. Integers are immutable, and
variables arenāt objects ā so it doesnāt fit the model.

Thatās also why Matz has never put x++ in the language.

David

[email protected] wrote:

Even when itās 2007++ integers will still be immutable, immediate
values I much prefer having people have to learn that thatās how
Ruby integers are.

To be fair, thatās a perfectly reasonable argument if ++ were to be a
method call. If itās to be programmer convenience for x += 1 (syntax
sugar for x=x+1) however, it could also be implemented as syntax sugar.

Iām personally perfectly happy without ++, but there are certainly ways
that it could be added to Ruby without violating the immutable
objects.

Well it does not seem that its was a good idea!

I was not aware how that RCR has to be interpreted, I meant something
else.
David (and Gevin in a private mail I did not understand very well,
apologies
Gevin) was very right when saying it is not obvious)?

x=42
x.object_id => 85
x.succ!
x.object_id => 87

and that would be a great mess I guess, Integer#succ! would need to know
the
binding as someone put it,
would violate at least one paradigm of OO design (a method changin the
scope
of the caller) etc. etc.
Funny how innocent it looked.
Sorry for having wasted your time.
But the good news is I do not feel like RCR anymore

Cheers
Robert

On 1/13/07, James Edward G. II [email protected] wrote:

On Jan 12, 2007, at 12:06 PM, Robert D. wrote:

I always define Integer#pred for myselfā¦

What does pred stand for? I must be slow today.

predecessor, by symmetry with successor

martin

Daniel B. wrote:

x++ in languages that implement it (PHP Iām sure of, Java and C++ Iām
less sure of) increment x after running the statement. So:

# All of the ++s are how it would be in PHP/Java/C++

def printNum x
puts x.to_s
end

x = 42
printNum(x++) #=> 42
printNum(x) #=> 43

x = 42
printNum(x.succ!) #=> 43
printNum(x) #=> 43

++x increments before passing the variable:
printNum(++x) #=> 44
printNum(x) #=> 44

So even if this was implemented, I think x++ would be a bad syntax to
x.succ! as other languages have something which looks exactly the same
and yet does something different.

Dan