Chris Nicholson-Sauls wrote:
> # import cashew.utils.array;
> #
> # int[] foo = ... ;
> # foo.remove(3U);
> # foo.removeRange(2U, 7U);
> # foo.removeSub(foo[1 .. 5]);
> etc.

I went to http://www.dsource.org/projects/cashew but found no obvious way to download cashew or instructions related to obtaining the software.

--bb

I suspect that the benchmark timings may be highly dependent on
the type T of the array.  Integers should be very fast, since the
arr[which]=arr[which+1]
is effectively a memmove operation.
If the type T is char, I would expect things to slow down
considerably.

I might suggest that simply discovering the size of the memory
block to be moved, then using a memmove() on it would be robustly
fast (independent of type T) since it is (supposed to be)
optimised to use the native type-size best suited to the machine.

David Qualls
ps: I'm VERY new to D; just learning it...

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
- range sets
- computer sets
- functions sets
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.


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).

I would suggest declaring a set as this:
int<> foo = <1,2,3>;
char<> bar = <'a'..'z', 'A'..'Z'>;

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 :).

And yes, having sets and ranges solve many problems. More than a handful of the suggestions of the D wish list page, are solved easily and consistent using ranges or sets. Well conceptually solved, then comes the problem of actually implementing it is the compiler :/.

But I like the idea of a few universal components that fits together in infinite ways, better than exceptions, and special cases, that only solves a single problem.


// Fredrik Olsson

> 
> 
> --bb

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?

> - 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)?

> - computer sets

No idea what that is. It sounds like a set of computers, which would be hard to implement with just code. :-)

> - functions sets

A set of functions?  A collection of things like 'int function(int bar)'?

> 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.

> 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;

--bb

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
> 
> 

Bill Baxter wrote:
> Chris Nicholson-Sauls wrote:
> 
>> # import cashew.utils.array;
>> #
>> # int[] foo = ... ;
>> # foo.remove(3U);
>> # foo.removeRange(2U, 7U);
>> # foo.removeSub(foo[1 .. 5]);
>> etc.
> 
> I went to http://www.dsource.org/projects/cashew but found no obvious way to download cashew or instructions related to obtaining the software.
> 
> --bb

I guess I could mention it explicitly, but the way to do it is to use Subversion checkout.  I don't bother making "official" downloads of it, because there are constant updates being made.  (This is also why each package/module gets its own version number, rather than a library-wide version.)

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:
> Bill Baxter wrote:
>> Chris Nicholson-Sauls wrote:
>>
>>> # import cashew.utils.array;
>>> #
>>> # int[] foo = ... ;
>>> # foo.remove(3U);
>>> # foo.removeRange(2U, 7U);
>>> # foo.removeSub(foo[1 .. 5]);
>>> etc.
>>
>> I went to http://www.dsource.org/projects/cashew but found no obvious way to download cashew or instructions related to obtaining the software.
>>
>> --bb
> 
> I guess I could mention it explicitly, but the way to do it is to use Subversion checkout.  I don't bother making "official" downloads of it, because there are constant updates being made.  (This is also why each package/module gets its own version number, rather than a library-wide version.)
> 
> -- Chris Nicholson-Sauls

Ok, I know subversion, but I don't know how to do a subversion checkout from Dsource.  What's the subversion URL for your project?

--bb

Bill Baxter wrote:

> Chris Nicholson-Sauls wrote:
>> Bill Baxter wrote:
>>> Chris Nicholson-Sauls wrote:
>>>
>>>> # import cashew.utils.array;
>>>> #
>>>> # int[] foo = ... ;
>>>> # foo.remove(3U);
>>>> # foo.removeRange(2U, 7U);
>>>> # foo.removeSub(foo[1 .. 5]);
>>>> etc.
>>>
>>> I went to http://www.dsource.org/projects/cashew but found no obvious way to download cashew or instructions related to obtaining the software.
>>>
>>> --bb
>> 
>> I guess I could mention it explicitly, but the way to do it is to use Subversion checkout.  I don't bother making "official" downloads of it, because there are constant updates being made.  (This is also why each package/module gets its own version number, rather than a library-wide version.)
>> 
>> -- Chris Nicholson-Sauls
> 
> Ok, I know subversion, but I don't know how to do a subversion checkout from Dsource.  What's the subversion URL for your project?
> 
> --bb

svn co http://svn.dsource.org/projects/cashew/trunk cashew

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Lars Ivar Igesund wrote:
> Bill Baxter wrote:
> 
>> Chris Nicholson-Sauls wrote:
>>> Bill Baxter wrote:
>>>> Chris Nicholson-Sauls wrote:
>>>>
>>>>> # import cashew.utils.array;
>>>>> #
>>>>> # int[] foo = ... ;
>>>>> # foo.remove(3U);
>>>>> # foo.removeRange(2U, 7U);
>>>>> # foo.removeSub(foo[1 .. 5]);
>>>>> etc.
>>>> I went to http://www.dsource.org/projects/cashew but found no obvious
>>>> way to download cashew or instructions related to obtaining the
>>>> software.
>>>>
>>>> --bb
>>> I guess I could mention it explicitly, but the way to do it is to use
>>> Subversion checkout.  I don't bother making "official" downloads of it,
>>> because there are constant updates being made.  (This is also why each
>>> package/module gets its own version number, rather than a library-wide
>>> version.)
>>>
>>> -- Chris Nicholson-Sauls
>> Ok, I know subversion, but I don't know how to do a subversion checkout
>> from Dsource.  What's the subversion URL for your project?
>>
>> --bb
> 
> svn co http://svn.dsource.org/projects/cashew/trunk cashew
> 

Wikied!

Thanks.

--bb

Bill Baxter wrote:
> Lars Ivar Igesund wrote:
>> Bill Baxter wrote:
>>
>>> Chris Nicholson-Sauls wrote:
>>>> Bill Baxter wrote:
>>>>> Chris Nicholson-Sauls wrote:
>>>>>
>>>>>> # import cashew.utils.array;
>>>>>> #
>>>>>> # int[] foo = ... ;
>>>>>> # foo.remove(3U);
>>>>>> # foo.removeRange(2U, 7U);
>>>>>> # foo.removeSub(foo[1 .. 5]);
>>>>>> etc.
>>>>> I went to http://www.dsource.org/projects/cashew but found no obvious
>>>>> way to download cashew or instructions related to obtaining the
>>>>> software.
>>>>>
>>>>> --bb
>>>> I guess I could mention it explicitly, but the way to do it is to use
>>>> Subversion checkout.  I don't bother making "official" downloads of it,
>>>> because there are constant updates being made.  (This is also why each
>>>> package/module gets its own version number, rather than a library-wide
>>>> version.)
>>>>
>>>> -- Chris Nicholson-Sauls
>>> Ok, I know subversion, but I don't know how to do a subversion checkout
>>> from Dsource.  What's the subversion URL for your project?
>>>
>>> --bb
>>
>> svn co http://svn.dsource.org/projects/cashew/trunk cashew
>>
> 
> Wikied!
> 

DSource has always had a page describing this at http://www.dsource.org/site/svnclient.