[ruby-talk:5896] Re: succ but no pred? (& the MURKY award)

> In message "[ruby-talk:5880] Re: succ but no pred? (& the MURKY award)"
>     on 00/10/27, [e-mail] <[e-mail]>
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.

I'm sorry, Matz. Of course that is true.

> |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 ;-).

Well, this is my opinion: I do not think it should be hard to define
String#pred
as the inverse of the existing String#succ. (I say this, never having looked
at
the code.)

However: To define the "proper" behavior of String#succ (which may be
different from current behavior!) -- I think that might be very hard.

I will put String#pred on my to-do list. But not at the top.

> |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.

True.