From: "trans.  (T. Onoma)" <transami@...>
Date: 2004-10-08T14:08:25+09:00
Subject: Re: Range behavior (Re: [RCR] New [] Semantics)

On Thursday 07 October 2004 11:20 pm, Markus wrote:
| On Thu, 2004-10-07 at 19:08, trans. (T. Onoma) wrote:
| > There are a couple of other small things that would be nice, but these
| > are the main important ones (IMHO) that I'm interested in solving. Brian
| > and Markus may have other ideas.
|
|      I have lots of other ideas.  At present they are drowned out by the
| seductive notion that anyone who can get a significant body of C to do
| what they want (and no more) must have the patience of a saint or the
| perspicacity of a seer.  Or both.

He he. That's why I use Ruby!

|      That is to say, I'm still trying to get free form operators
| working.

All power to you! If it can be done, I think it is a very excellent thing for 
Ruby to have.

|      As for Ranges, I tend to favour class trees rather than (as matz
| prefers) trying to make one tool serve several purposes.  I would, for
| example, give the Range tribe a family tree much like that of Numeric
| (with Float, Bignum, Complex, etc.) where different members fill
| different rolls but all work together in harmony.

I think Einstein put is best (parapharsed): make things simple, but not too 
simple. In otherwords, its good to have something be multi-purpose, but not 
if it interferes with function. [1]

|      As I listed before, there are at least four things being done with
| ranges (Intervals, Pairs, Point_sets, Iteration_reification (including
| circular/end-based indexing) and perhaps others).  I would like to see
| them teased apart but haven't devoted much effort to doing so myself.

I would tend toward a balance. I think Discrete vs. Continuous is probably is 
kludge combined, but I think others can work fine for joint purposes.

|      Instead, since that isn't what matz wants, I am exploring my second
| option; making it possible for users to flesh out their own hierarchy as
| they see fit, without being sent to a syntactic ghetto.  Thus my
| interest in define-your-own operators.  The idea first came up in the
| context of Hash, where much the same discussion took place, with some
| people wanting finer control over the details of Hash behaviour, while
| others liked it being a single type.

I've always wanted some extra operators!

|      My silly hope is that it may be possible to make everyone happy, by
| increasing the flexibility of ruby in very specific ways (as discussed a
| few weeks back); we may be able to let people play with detailed class
| trees without breaking much (if any) existing code.  Then, if someone
| cooks up a clear winner, that can be considered for inclusion in the
| core language.

Sounds good.

T.

Footnotes:
[1] In fact, I tend to think even Class and Module could be one thing.

---

P.S. Two other (not very important) oddities about Range:

Although as you point out this is at least quite comprehensible, it might 
still strike one as odd:

  q = 0..3.5
  => 0..3.5
  q.member?(3.5)
  => false

I am not sure what causes this:

  q = 'a'..200
  => "a"..200
  q.member?(100)
  NoMethodError: undefined method `>' for false:FalseClass
        from (irb):6:in `member?'
        from (irb):6

Though it seems a dumb thing to do anyway.