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

Hi, 

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

>relax.... Your information in so far, was very valuable. But your
>health will be more valueable, isn't it? :-)

Thank you! I shall surely write that next week :-)

>again I hope, that Ruby one day will have a own newsgroup. I know
>matz like mailing lists the better, but I think a newsgroup perhaps
>could draw more peoples to Ruby than a mailing list. But that is
>another topic!

I hope so. Though, I believe that the appearence of newsgroup is a
result of pupularization rather than a method to spread.  To difuuse
Ruby into the world, we may need another strategic publication.

>>Some elements have no natural predecessor; What is `"a".pred'?  
>>And I think such iteration is too complex to generalize by Range. 
>
>As I have decided to implement a class Interval, I will use that new
>class to answer your question, ok? 

I see. But as you point out, I have a different image of Interval
rather than Cle or Matz.  `Interval' reminds me a class managing
membership, because the most familiar interval for me is `an interval
on real number' wheare as you guys supporse to use Interval to
itarations. I'm interested in an native speaker's sense of words.
Julian? or Bryce?

>Whereas I really like your idea (allthough I would prefer someting
>like |b,e|, [b,e|, |b,e] and [b,e]; it's more mathematically), I
>think that introducing a new syntax is perhaps a little bit too much
>for that only purpose, isn't it?

Yes, a class method may be enough. 

>I think I would like to have it, as it would enable us to look what
>kind of member is on the n'th position. Furthermore I would like to
>add a between test like:
>
>   interval("a", "z").included?("c")

How about `("a".."z") === "c"'?
But your interval would be devoted to iteration, isn't it?

By the way, I've felt not good the name of Array#include?.  It should
be `has?' because `include' reminds mathematicians `subset check',
i.e., ``["foo", "bar", "baz"].include? ["foo", "baz"] #=> true''

>>Again, we should mind that negative options are limited. 
>
>No! Please not! I think for strings it can make sense to have such
>magic behavior.

I maybe don't need that. All my anxity is defference between succ and
pred.  `pred' shall behave as same as succ(-1) then pred may have
implicit restrictions because, I say again, some objects have no
suitable predecessor. Furthermore, such restriction is needed for not
only strings but also for nutural numbers like a Julius date. In such
sense, the predecessor is a quite different notion than the successor. 
We should mind it. I don't see whether or not that is serious
difference. Of course that can be avoided by raising an error:
"a".pred #! Error

-- gotoken