From: matz@... (Yukihiro Matsumoto)
Date: 2000-10-27T10:40:36+09:00
Subject: [ruby-talk:5893] Re: succ but no pred? (& the MURKY award)

Hi,

In message "[ruby-talk:5880] Re: succ but no pred? (& the MURKY award)"
    on 00/10/27, hal9000@hypermetrics.com <hal9000@hypermetrics.com> writes:

|OK... but for numbers it is trivial. Given an Integer#succ, should we
|not have an Integer#pred also?
|
|In fact, if we defined succ! and pred! also, these could serve as
|preincrement and predecrement operators (++x, --x) which some C
|programmers might miss. That is another issue. (There would still be no
|"post" versions, but these are more problematic anyway.)

2 points again:

  * predecessor for numbers can be defined in any case;  not for
    string in general.

  * Fixnums (actually Numbers in general) are immutable; so that succ!
    and pred! cannot be defined.  In fact, ++x and --x are operations
    on variables, which cannot be accomplished by methods.

|And as for decrementing strings -- my intuition (which may be wrong!)
|says that it is no harder than incrementing... we would need to ensure
|that x.succ.pred == x and x.pred.succ == x for all but the boundary
|cases.
|
|And there must be boundary cases. Just as there must be at least one
|string that does not have a successor, likewise there must be at least
|one string without a predecessor. (I am not sure about null strings.)

When I talked with Clemens about this topic before, I had hard time to
define detailed behavior.  I'm not against to add pred for Integers
and Strings, iff pred behavior for strings can be defined precisely
(or code supplied ;-).

|But I do like to see regularity -- if Lightbulb#screw exists, I want
|Lightbulb#unscrew to be there also. In fact, I think there are times
|when we should say, "Both or neither! But not just one."

There might not be both ways;  for example MD5 hash function.

							matz.