From: "Randy W. Sims" <ml-ruby@...>
Date: 2004-10-08T10:21:10+09:00
Subject: Re: Range behavior (Re: [RCR] New [] Semantics)

On 10/7/2004 8:08 PM, Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: Range behavior (Re: [RCR] New [] Semantics)"
>     on Fri, 8 Oct 2004 01:19:21 +0900, "trans.  (T. Onoma)" <transami@runbox.com> writes:
> 
> |A BIG question that comes to mind after reading your post is this: What do 
> |people usually use Range for? Is it continuous or discrete? I know there is 
> |some of both, but I wonder if one far exceeds the other. Hopefully yes, b/c I 
> |think the solution must basically fall to something like this:
> 
> <snip>
> 
> Define the problem to solve.  What do you want to fix?
> 
> Ranges serving both continuous and discrete?  Or "member?" and
> "include?"  behaving differently?  Or having fun with designing
> ranges?  Or something else?
> 
> For your note, I refuse to separate continuous ranges and discrete
> ranges.  In Ruby, I'd rather choose classes to have multiple purpose.
> For example, arrays can be served as stack, queue, etc.  I feel same
> to ranges too.
> 
> I thought "member?" (which means item is included in the member set of
> enumeration) and "include?" (which means item is included between
> upper and lower bound) can be easily distinguished.
> 
> I have several ideas, but I have to know what is the problem first.

FWIW, I like the current implementation.

I think it is important to be able to express ideas like those being 
expressed here, and it's great to be able to make suggestions and have a 
conversation with the language author. Unfortunately, a lot of people 
(myself included) sometimes get in a mode where we over design things. 
We start thinking hypothetically and abstractly about things that would 
be nice to have. But most of them are not strictly necessary . A lot of 
the suggestions I've seen on this and other lang forums, especially in 
"scripting" languages suffer this problem.

I've always liked C++'s philosophy of a complete, but minimal core. It 
keeps things simple, fewer points of failure, easy to understand and 
learn, etc. But it's hard to find a balance. Some simple additions like 
a ++ operator are used so much they are useful to the language. But some 
operators that are just as simple (implementation wise) are just not 
useful enough to be implemented. This seems to be a problem, for 
example, with Perl6 IMHO. An example might be an xor operator (^^). It 
might be useful and expressive in some situations, but it's probably not 
useful often enough to be worth the cost of having yet another operator, 
and it also has an easy workaround ((A || B) && !(A && B)).

The same thing could be argued about continuous ranges. Workaround are easy:

irb(main):001:0> rng = 0..9
=> 0..9
irb(main):002:0> 0.42 > rng.first && 0.42 < rng.last
=> true

And I'm not sure they're used often enough to warrant more.

Just MHO,
Randy.