On 7/10/12 12:57 PM, Jacob Carlborg wrote:
> On 2012-07-10 16:36, Dmitry Olshansky wrote:
>> Dunno, to me it says SORTED in one big scary thought. Again it should
>> ether check constraint or put some more useful description. e.g.
>> "(functionality akin to the uniq system utility)" doesn't strike me as
>> helpful.
>
> Sure, this particular example uses a sorted array, but nothing says an
> unsorted array won't work.

Clearly this and any documentation can be improved, but I'd say if it says "range" there there's no assumption "sorted range" there. I think the main thing that could be expressed better is "unique consecutive".

> Does it only handle ints. It doesn't say anything about that in the
> documentation and the example uses ints. Then it must only accept ints.

I think it would be onerous to mention for each algorithm, although clearly they all are generic, that they can handle ranges with any element type.

> You see how stupid that is.

That being what?


Andrei

On 7/10/12 1:17 PM, Daniel Murphy wrote:
> "Christophe Travert"<travert@phare.normalesup.org>  wrote in message
> news:jthmu8$2s5b$1@digitalmars.com...
>> "Daniel Murphy" , dans le message (digitalmars.D:171720), a écrit :
>>> Could it be extended to accept multiple values? (sort of like chain)
>>> eg.
>>> foreach(x; makeRange(23, 7, 1990)) // NO allocations!
>>> {
>>>      ....
>>> }
>>> I would use this in a lot of places I currently jump through hoops to get
>>> a
>>> static array without allocating.
>>
>> That's a good idea. IMHO, the real solution would be to make an easy way
>> to create static arrays, and slice them when you want a range.
>>
>
> It's not quite the same thing, static arrays are not ranges and once you
> slice them you no longer have a value type, and might be referring to stack
> allocated data.  With... this thing, the length/progress is not encoded in
> the type (making it rangeable) but the data _is_ contained in the type,
> making it safe to pass around.  The best of both worlds, in some situations.

That does seem good to have. What would be a better name than makeRange?

Andrei

On Tue, 10 Jul 2012 17:21:14 +0200, Christophe Travert <travert@phare.normalesup.org> wrote:

> "Simen Kjaeraas" , dans le message (digitalmars.D:171678), a écrit :
>>> Well, I haven't been able to use a single function from std.algorithm
>>> without adding a lot of calls to "array" or "to!(string)". I think the
>>> things I'm trying to do seems trivial and quite common. I'm I overrating
>>> std.algorithm or does it not fit my needs?
>>>
>>
>> bearophile (who else? :p) has suggested the addition of eager and in-place
>> versions of some ranges, and I think he has a very good point.
>
> That would have been useful before UFSC.
> Now, writing .array() at the end of an algorithm call is not a pain.
>
> int[] = [1, 2, 2, 3].uniq().map!toString().array();
>

Please tell me how that is in-place.

-- 
Simen

On 7/10/12 1:05 PM, Jacob Carlborg wrote:
> On 2012-07-10 16:22, Andrei Alexandrescu wrote:
>
>> It may be the case you're trying to write ruby in D. I rarely need to
>> convert stuff to arrays.
>
> Mostly I receive an array, do some operations on it and then want to
> store the result in an instance variable in a class or struct. It's
> quite awkward to store a range in an instance variable.

Then store an array. "No one's put a gun to yer head." http://youtu.be/CB1Pij54gTw?t=2m29s

Andrei

On Tuesday, July 10, 2012 13:58:50 Andrei Alexandrescu wrote:
> On 7/10/12 1:17 PM, Daniel Murphy wrote:
> > "Christophe Travert"<travert@phare.normalesup.org> wrote in message news:jthmu8$2s5b$1@digitalmars.com...
> > 
> >> "Daniel Murphy" , dans le message (digitalmars.D:171720), a écrit :
> >>> Could it be extended to accept multiple values? (sort of like chain)
> >>> eg.
> >>> foreach(x; makeRange(23, 7, 1990)) // NO allocations!
> >>> {
> >>> 
> >>> ....
> >>> 
> >>> }
> >>> I would use this in a lot of places I currently jump through hoops to
> >>> get
> >>> a
> >>> static array without allocating.
> >> 
> >> That's a good idea. IMHO, the real solution would be to make an easy way to create static arrays, and slice them when you want a range.
> > 
> > It's not quite the same thing, static arrays are not ranges and once you
> > slice them you no longer have a value type, and might be referring to
> > stack
> > allocated data. With... this thing, the length/progress is not encoded in
> > the type (making it rangeable) but the data _is_ contained in the type,
> > making it safe to pass around. The best of both worlds, in some
> > situations.
> That does seem good to have. What would be a better name than makeRange?

I see no problem with makeRange. It seems like a sensible name to me. You're taking a sequence of elements and making a range out of them.

- Jonathan M Davis

On 7/10/12 2:08 PM, Jonathan M Davis wrote:
>> That does seem good to have. What would be a better name than makeRange?
>
> I see no problem with makeRange. It seems like a sensible name to me. You're
> taking a sequence of elements and making a range out of them.

I swear I'd just call it "range".

Andrei

On Tue, 10 Jul 2012 20:09:15 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 7/10/12 2:08 PM, Jonathan M Davis wrote:
>>> That does seem good to have. What would be a better name than makeRange?
>>
>> I see no problem with makeRange. It seems like a sensible name to me. You're
>> taking a sequence of elements and making a range out of them.
>
> I swear I'd just call it "range".
>
> Andrei
>

I'm with Andy on this.

-- 
Simen

On 7/10/12 2:02 PM, Simen Kjaeraas wrote:
> On Tue, 10 Jul 2012 17:21:14 +0200, Christophe Travert
> <travert@phare.normalesup.org> wrote:
>
>> "Simen Kjaeraas" , dans le message (digitalmars.D:171678), a écrit :
>>>> Well, I haven't been able to use a single function from std.algorithm
>>>> without adding a lot of calls to "array" or "to!(string)". I think the
>>>> things I'm trying to do seems trivial and quite common. I'm I
>>>> overrating
>>>> std.algorithm or does it not fit my needs?
>>>>
>>>
>>> bearophile (who else? :p) has suggested the addition of eager and
>>> in-place
>>> versions of some ranges, and I think he has a very good point.
>>
>> That would have been useful before UFSC.
>> Now, writing .array() at the end of an algorithm call is not a pain.
>>
>> int[] = [1, 2, 2, 3].uniq().map!toString().array();
>>
>
> Please tell me how that is in-place.

Let's say it doesn't perform unnecessary allocations. It's like you'd create the array ["1", "2", "3"] from the array [1, 2, 2, 3] using a loop and a couple of state variables.

Andrei

On Tue, 10 Jul 2012 16:27:31 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 7/10/12 8:52 AM, Simen Kjaeraas wrote:
>> bearophile (who else? :p) has suggested the addition of eager and in-place
>> versions of some ranges, and I think he has a very good point.
>
> Where would good old loops not work for eager stuff?

Mostly because I like the std.algorithm way of writing stuff, now we have UFCS.

But yes,  could not come up with a good case for not using loops beyond that.

-- 
Simen

On 07/10/2012 08:09 PM, Andrei Alexandrescu wrote:
> On 7/10/12 2:08 PM, Jonathan M Davis wrote:
>>> That does seem good to have. What would be a better name than makeRange?
>>
>> I see no problem with makeRange. It seems like a sensible name to me.
>> You're
>> taking a sequence of elements and making a range out of them.
>
> I swear I'd just call it "range".
>
> Andrei
>
>

This was my thinking as well.