------art_65515_25005328.1168767857338
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 1/14/07, Gavin Kistner <gavin.kistner / anark.com> wrote:
>
> 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 xB, yB, 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   + 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:

    xB  (x.object_id  5)
    yC (y.object_id
    x.succ! (x.object_id2389f0d0) a clone of 42 is created and modifed
    x43 && x  (true)

No there is no need for that.

x  oo.new
> then the 'x' variable is pointing to the instance of the Foo class. When
> you do "y 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

-----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)
> > xA
> > y> > 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  1
> > 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

------art_65515_25005328.1168767857338--