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

Hi,

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

>You're right! I try to mention Ruby among my fellows, whenever I have
>an opportunity. But it is not enough, I feel. I have thought about
>writing some articles in our computer magazins, but I don't know,
>whether my abilities are enough to write an magazin article.

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 :-)

>>>>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'?

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. 

>I have used it in terms of Smalltalk. In Smalltalk I can use
>
>   (1 to: 10) do: [:i| ...]
>
>In Smalltalk, the method Integer::to: will create an Interval. I
>should mention that in Smalltalk
>
>   Interval < FixedSizeCollection < IndexedCollection < Collection
>
>and there exists methods (e.g. Collection#do:) to iterate over
>Collections. So in Smalltalk, instances of class Interval are mostly
>used for iteration purposes! BTW: an Interval in Smalltalk is defined
>as: "... finite arithmetic progression." it "... contains all the
>elements within a specified range and with a specified distance
>between each of them, ...".

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.

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.

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?

>But as an Interval should be a iteration which also is a
>enumeration, (I plan to include Enumeration), the
>`Interval#include?' method would automatically creeps in! :-)

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

>I think it is an advantage to let all classes which could iterate
>over its elements be an Enumeration, and use all the same methods, so
>that I have not to look, what name I've to use for the
>class-of-the-day! :-)

:-) :-)

>That, I think, is the best way. Every class, which does not implement
>`succ' cannot be used for raising intervals; every which lacks a
>`pred' method cannot be used for falling intervals. That would be
>fair, and open a door to generality! What do you think?

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.

>You know, the big difference between an Array and an Interval would
>be, that all elements of an Interval depends on each other. So it is
>not necessary to store them all, but only the start, the stop and the
>increment. All other positions would be calculated. That can save
>much memory!

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.

-- gotoken