[ruby-talk:00429] Re: New feature for Ruby?

On Sat, 03 Jul 1999, you wrote:
>Hi,
>
>In message "[ruby-talk:00427] Re: New feature for Ruby?"
>    on 99/07/03, Clemens Hintze <[e-mail]> writes:
>

[...]

>
>If `abilities' means `depth of knouledge about Ruby' or `depth of love
>to Ruby', your're just the right writer, I believe.  I guess Matz
>thinks so :-)

***BLUSH... URPS... AHMMMM*** <don'tknowwhattosaynow>...

:
:

Thanks for your opinion :-) Although regarding "depth of love" I would
consent you, but regarding "depth of knowledge" I will still need some
time to reach your level (if I ever will have a chance) :-}

But I perhaps lack ability to write articles so that a magazin would
publish it! But nevertheless, I will try it someday :-)

>
>>>>>Some elements have no natural predecessor; What is `"a".pred'?  
>>>>>And I think such iteration is too complex to generalize by Range. 
>>
>>I have defined, that `"a".pred' results in "". String increment and
>>decrement are magical. We can define, what it means! Okay... whether
>>it makes sense or not, is another issue. So we are discussing here :-)
>
>Exactly! We can/must define such magic. Then, what is `"a".pred.pred'?
>

In my current implementation, I have defined, that `"".succ' and
`"".pred' is not defined and therefore raise an exception. So your
`"".pred.pred' would cause an exception at least. I don't know,
whether it is clever or not!

But Ruby already have magical increment of Strings, means String#succ!
And if I do a `"".succ' I will get an `"\377"'. As I didn't consider
that behavior as the one one would expect, I have patched String#succ,
so that it would raise an exception.

Of course that also have to be discussed! I have no preferences here,
as it is only a non-vital part of my proposal. :-)

>I think this problem comes from the property of the natural
>number. The lexical order is a example of indexing by natural
>number. And, the nutural number is a basic one-side infinite discrete
>structure. As you know, this problem is just on *pred* rather than
>Interval. Any way, we have to decide the manner of non trivial pred
>for the first element. I consider it is serious decision. 

As I am not a mathematican, I normally have no problems with such
decisions. I simply do it ;-))))

Of course I agree, that such decision from a non-mathematican can
cause troubles later. 

[...]

>Thanks for the explanation.  In the discussion going here, I'm minding
>a parcialy ordered hierarchy of the role (not inheritance):
>
>    special  <<----------------------------------->>  general
>
>            (1) --+
>                  |
>       (2) --+  +-+- interation specialized --+
>             |  |                             |
>     Range --+--+                             +-- region of order
>                |                             |
>                +-+- membership specialized --+
>                  |
>region of Float --+
>region of Time  --+
>
>Which do you think to put Interval (1), (2) or the other place?  The
>difference between (2) and (1) is whether enumerable (or each member
>has successor) or not. If we accept Interval of Smalltalk, it would
>put in (2) because it is enumerable since arithmetic (I assume
>`arithmetic' means `nutural number theoretical', then descrete and
>countable).  If so, I feel such class is little redundant because
>Range exists already; This verboseness may be similar the relation
>between tuple and list in Python.

That was the reason, I originally want to patch class Range to give
it all the features it need to do such work. But as matz have stated,
that he want to define a Range as it currently is, means upwards, and
one by one, I have thought to implement these features in a new class
Interval.

So Interval would have all features of Range and more. But the
difference would be, that a Range#each would be faster for numbers
than an Interval, as Interval would use the generic part of
Range#each. Interval would not handle numbers and strings special, so
the lesser speed.

>
>On the other hand, I believe that I understand Cle requests a reverse
>order range. I think one of the problems is a range object can be used
>as an option of String/Array#[], e.g., "StarTrek"[4..-1] whareas 4..-1
>seems to be <4,3,2,1,0,-1> in the other contexts.

That was the originally starting point of my proposal. One day I have
programmed something like

   for i in 9..1
      ...
   end

and it didn't work. After investigation, I have found, that it
couldn't because of Range's limits. As I didn't want to program such
case explicit using `while' I have decide to modify Range etc. pp.

>
>Well, well, I become again getting thought Cle's idea is plausible,
>that is the order direction property for Range. More precisely, I think 
>a variety of that, for example, 
>
>  (-1..4).direction #=> Range::UP
>  (4..-1).direction #=> Range::DOWN
>  (-1..4).reverse   #=> 4..-1
>
>Of course, to implement the above, a set of methods are required,
>i.e., <=>, succ (or upto), and pred (downto).  For indeces, it is
>enough String#[] or Array#[] deals specially with range, I
>think. Other problem is compatibility...
>
>>>How about `("a".."z") === "c"'?
>>>But your interval would be devoted to iteration, isn't it?
>>
>>I have already thought of it! I aggree. I think it really makes no
>>sense to use an Interval where I can use a Range too!
>
>Yes. Though, we can admit define Interval#=== too, Is this wrong?

ATTENTION PLEASE: If Interval would define Interval#===, it would have
a slight other task than Range#===!

Interval#=== should checks, whether a certain value would be contained
by that interval or not. That means

   interval(0,100,2) === 2               # true
   interval(0,100,2) === 1               # false

The second example would be false, as the interval is [0, 2, 4, ...,
100] and there is no element 1.

[...]

>However I feel that makes Interval to become closer to Range. 

You're right! But it is not my desire to make Interval as different as
possible to Range. If we would obey that rule all the time, it would
not be necessary to have Fixnum and Integer. Fixnum would enough,
right?

[...]

>Okey, I agree now. All we have to decide is *how* we define the
>predecessor of the first member something like "a".pred or
>"a".pred.pred.  I'm considering nil or error for the candidates.

Although I have decided to let `"a".pred' be `""', but that was
without any logical reason. Perhaps it would be better to forbid
things like `"".pred' and `"".succ' and raise an exception if somebody
try `"a".pred'. Perhaps that would be the cleanest solution. I don't
thing, that `"a".pred == nil' is better than `"a".pred == ""'. The
last definition would have the advantage, that the type of the
returned object has not changed. It would remain a string. Other opinions?

[...]

>Yes! I understand that. In this point of view, I want also
>membership specified region class for non-enumerable objects. But it
>will be defined in the project anyway. In the numerical scene such
>ranges appear very often.

Perhaps I have not grasp your point at whole. Would you be so kind to
explain your last paragraph again?

>
>-- gotoken

\cle