Sorry about the top-reply; stupid Outlook email.
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?)
I think your idea about not arguing for or against your proposal on the
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.
2) 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 about
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
message, your reply, or this message to the mailing list.
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
ยทยทยท
On 1/14/07, Gavin Kistner <gavin.kistner@anark.com> wrote:
-----Original Message-----
From: Robert Dober [mailto:robert.dober@gmail.com]
Sent: Sat 01.13.2007 00:32
To: Gavin Kistner
Cc:
Subject: Re: RCR again (Integer#succ!, Integer#pred!)On 1/12/07, Gavin Kistner <gavin.kistner@anark.com> wrote:
>
> For some reason your emails aren't showing up on groups.google.com; are
> you using multi-part/styled email?No, that is strange, I never had any complaints.
Anyhow, since I can't reply to you there:
>
> 1) Please keep in mind that there needs to be a compelling reason for an
> RCR to be in the core/kernel of the language. You've definitely not
> provided that in the Analysis. (Please see the RCR guidelines on the
> site for what each section should entail.)I am aware of that, but I feel that "compelling reason" is a very
subjectiv
thing.
There are tons of things in Ruby without a "compelling reason", #injcet,
#collect as an alias to #map.
Matz felt that they make Ruby "better" in some way, that was reason
enough.
That is exactly why one consults the community, right?
Please be aware that I have not filed an RCR yet of course.
The important thing here is that you do not feel any reason for succ! and
pred! to be in the core.
Me neither, but it is about the community.
I am kind of counting, not counting myself, so right now the score is 1-0.
I try to avoid to give my reasoning for the RCR I feel it is not about
arguing but about wanting it or not.2)
> x=41
> y=x
> x.succ!
>
> What is why?
>
> You can't use a method call to change just one instance of a variable,
> and you can't possibly want everything that refers to 41 to suddenly
> refer to 42. Numbers are immutable for a reason.I am afraid that I was not very clear in my description, what you are
saying
is trivial and has nothing to do with
what I have written.
pred! would do what -- does in C++.
As in C++ one can not say 3++ one could not say 3.pred! in Ruby. That of
course would be made much clearer in
an actual RCR.Would you like me to forward all that to the list?
Thank you for your time.
Robert
-----Original Message-----
> From: Robert Dober [mailto:robert.dober@gmail.com]
> Sent: Friday, January 12, 2007 11:07 AM
> To: ruby-talk ML
> Subject: RCR again (Integer#succ!, Integer#pred!)
>
> I am definitely in an RCR mood
>
> Well as I was reading the archives and Jim Weirich'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
>
> --
> "The best way to predict the future is to invent it."
> - Alan Kay
>--
"The best way to predict the future is to invent it."
- Alan Kay
--
"The best way to predict the future is to invent it."
- Alan Kay