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

[Fredrik Olsson]

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!*/;
> 
> So instead you could follow the lead of templates and use parens with a 
> 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
> 
>