On 2012-07-10 16:54, Andrei Alexandrescu wrote:

> Actually I take that back. One may use uniq to remove duplicates in
> unsorted ranges.

How does that work? It didn't work in my example.

-- 
/Jacob Carlborg

"Jacob Carlborg" <doob@me.com> wrote in message news:jthlpf$2pnb$1@digitalmars.com...
>
> Can't "map" and "filter" return a random-access range if that's what they receive?
>
map can, and does.
filter cannot, because it doesn't know which element is number 4 until it
knows if element 3 is included or not.

On 07/10/2012 06:38 PM, Jacob Carlborg wrote:
> On 2012-07-10 17:30, Andrei Alexandrescu wrote:
>
>> It would be possible to chain a single element to the end of a range.
>> One related thing to do is to define singletonRange(x) that returns a
>> range with exactly one element, namely x.
>
> Ok, I saw that suggestion in another post.
>
>> Ranges and std.algorithm obey simple, mathematical realities deriving
>> from algorithm and storage topology constraints. For example sort works
>> in place so it generally can't work on mapped stuff because there's no
>> place to put the sorted contents. Also sort needs a random-access range
>> to work with so it can't work e.g. with the result of filter, which
>> necessarily yields a non-random-access range. And so on.
>
> Can't "map" and "filter" return a random-access range if that's what
> they receive?
>

Map can do that and does do that. How would it work for filter?

On 07/10/2012 06:40 PM, Jacob Carlborg wrote:
> On 2012-07-10 16:54, Andrei Alexandrescu wrote:
>
>> Actually I take that back. One may use uniq to remove duplicates in
>> unsorted ranges.
>
> How does that work? It didn't work in my example.
>

It works. It removes consecutive duplicates. 'uniq' in ruby is
different, which is strange as the name was taken from the command-line
facility. (that also removes consecutive duplicates)

Andrei Alexandrescu , dans le message (digitalmars.D:171723), a écrit :
>> auto emptyRange(E)(E value)
>> {
>>    return repeat(value).takeNone;
>> }

> That also seems to answer Jonathan's quest about defining emptyRange. Just use takeNone(R.init).

err, that should be more like:

auto singletonRange(E)() // with no parameters
{
  return takeNone!type_of(repeat(E.init))();
}

An emptyRange compatible with singletonRange should be called singletonRange and take no parameter, so that emptyRange name could be reserved to a real statically empty range (which is pretty easy to implement).

-- 
Christophe

On 2012-07-10 16:36, Dmitry Olshansky wrote:

> typeof to the rescue. In fact I'm not so proud of voldemort types. As
> when you need to sotre range somewhere they stand in your way for no
> benefit.

I'm not exactly sure how you mean but this is what I came up with:

import std.algorithm;
import std.traits;
import std.conv;

class Foo
{
    auto bar ()
    {
        return [3, 4].map!(x => x.to!(string));
    }

    ReturnType!(bar) x;
}

Which is just the worst idea ever. BTW I can't see how "typeof" would work.

> auto a = [5, 3, 5, 6, 8].uniq.map!(x => x.to!(string)).array;
> sort(a);
> return a;
>
> Just use the same array, it's just that sort returns a wrapper around
> array (or other range) that indicates it's sorted by predicate x. It can
> then help to reuse this information e.g. to perforam binary search etc.

Aha, I didn't know that it sorted in place.

>
> Just take an array and call sort on it like in the old days. I don't
> think that stuffing it into one liner is required.
> Again if you need an array just call array at the end that's how it's
> supposed to be.

See above.

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

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.

You see how stupid that is.

-- 
/Jacob Carlborg

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

-- 
Christophe

I it were just me, array litterals would be static, and people should use .dup when they want a a surviving slice.

Well, if it were just me, all function signature should tell when references to data escape the scope of the function, and all data would be allocated automatically where it should by the compiler.

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.

-- 
/Jacob Carlborg

Jacob Carlborg , dans le message (digitalmars.D:171725), a écrit :
> On 2012-07-10 17:11, Christophe Travert wrote:
> 
>> What is wrong with foo.chain(["bar"])?
> 
> I think it conceptually wrong for what I want to do. I don't know if I misunderstood ranges completely but I'm seeing them as an abstraction over a collection. With most mutable collection you can add/append an element.

That may be the source of your problem. ranges are not collections. They do not own data. They just show data. You can't make them grow. You can only consume what you have already read.

On 2012-07-10 18:42, Daniel Murphy wrote:
> "Jacob Carlborg" <doob@me.com> wrote in message
> news:jthlpf$2pnb$1@digitalmars.com...
>>
>> Can't "map" and "filter" return a random-access range if that's what they
>> receive?
>>
> map can, and does.

It doesn't seem to:

auto a = [3, 4].map!(x => x);
auto b = a.sort;

Result in one of the original errors I started this thread with.

-- 
/Jacob Carlborg