# Range objects and fancy indexing -- Re: Removing elements from dynamic arrays?

Fredrik Olsson peylow at gmail.com
Wed Nov 1 09:09:37 PST 2006

```Bill Baxter skrev:
> Fredrik Olsson wrote:
>> Bill Baxter skrev:
>> <snip>
>>
>>> Note that if 3..5 returned a range object, then there would be no
>>> real need for the opSlice methods.  They would be replaced by opIndex
>>> overloaed for the range type.  E.g opIndex(range r)
>>>
>>
>> I cut most of it, as you know what I am referring to anyway :).
>>
>>
>> Ranges and sets are related, in fact in my own sets implementation I
>> have four kinds of sets:
>> - finite sets
>
> Ok.  Is that just numbers or anything?
>
Anything.

>> - range sets
>
> Ok.  That must be just numbers.  Does that include things like the set
> containing the semi-open real number intervals (1,3] and [5,7)?
>
Yes. As well as -infinite, and +infinite.

>> - computer sets
>
> No idea what that is. It sounds like a set of computers, which would be
> hard to implement with just code. :-)
>
Misspelled, computed set that is. See it as "set operators". For example
the union of sets, etc.

>> - functions sets
>
> A set of functions?  A collection of things like 'int function(int bar)'?
>
No a set where membership is determined by a function. For example a set
with primes, even integers, etc.

>> This implantation is however an overkill, and way too slow, as it also
>> covers infinite sets. For a compiler feature finite sets is the only
>> realistic goal. But having a infinite set solution as well in the
>> standard lib is good too.
>
> Haskell's lazy infinite lists are pretty nifty in that regard.
>
>
>> I think you should be able to have sets of any type, and ranges of any
>> numeric type. For obvious reasons finite sets of integers can be
>> optimized greatly if used having a special case. And in worst case, I
>> can live with only them (As they make up for 99% of real world cases
>> and a templete implementation can fix the rest).
>
> Ok, but I think sets of arbitrary objects are also about as common as
> sets of integers.
>
Common yes, but set arithmetics are not common on them. So for most
implementations a dynamic array is just fine. Some templates array
manipulation, like what I think Oscar Linde posted some months ago would
be fine (map function etc).

>> I would suggest declaring a set as this:
>> int<> foo = <1,2,3>;
>> char<> bar = <'a'..'z', 'A'..'Z'>;
>
> Y'know there's a reason the < and > are available.  It's because their
> use in templates caused annoying ambiguity in C++ when nesting.  Your
> sets notation will have the same problem.
>
>    int<int<>> /*oops!*/ foo = <</*oops*/1,2>,<3,4>>/*oops!*/;
>
> sigil.  Like \$!  Looks sort of like an 'S' for set. :-)
>
>    \$int foo = \$(1,2,3);
>    \$char bar = \$('a'..'z', 'A'..'Z');
>
> Urm, nah.  People are going to start thinking they're reading Perl or
> BASIC code.  The great thing about sets is that 'set' is such a small word.
>    auto foo = set([1,2,3]);
>    auto bar = set(['a'..'z', 'A'..'Z']);
>
> Why bother with introducing another syntax?
>
>> How a range type can be declared, I am not sure. Writing the literals
>> is obvious with the .. operator. But for declaring?
>> int.. foo = 1..42;
>> Just does not look right :).
>
> Yeh, that does look odd.  I don't really see a great need for a special
> range syntax.  Have a standard definition for a thing called a 'range',
> and make that be what 1..42 evaluates to.
>
>   range!(int) foo = 1..42;
>
> or
>
>   auto foo = 1..42;
>
Well, I do not much care for the actual syntax, I just think <...> looks
nice, and D-like :).
But \$ works for me, but as a suffix when declaring, as you might want:
int[]\$ foo; // set of int arrays. \$int[] would be ambiguous.

I do however think a range-specific-syntax is crucial if ranges are to
be first class citizens. Using range!(type) would demote it to a
template hack, and auto would force programmers to initialize.

// Fredrik Olsson

> --bb
>
>

```