Array operations are super cool, and I'm using ranges (which kinda look and feel like arrays) more and more these days, but I can't help but feel like their incompatibility with the standard array operations is a massive loss.

Let's say I want to assign one range to another: b[] = a[];
It's not clear to me why this should fall down if I want to apply a
lazy operation for instance: b[] = a.map!(e=>e*2)[];
... or something to that effect.

I find that my lazy ranges often end up on the stack, but I can't
assign/initialise directly: float[] a = b.transform[];
Instead I need to: float[] a;  b.transform.copy(a[]);

The fact that they don't mix with array expressions or operators means as soon as a lazy range finds it wants to enter existing array code, it needs to be converted to a series of map()'s.

There must be years of thoughts and work on this sort of thing? It seems arrays and ranges are unnecessarily distanced from eachother... what are the reasons for this?

On Sunday, 26 April 2015 at 10:17:59 UTC, Manu wrote:
> Array operations are super cool, and I'm using ranges (which kinda
> look and feel like arrays) more and more these days, but I can't help
> but feel like their incompatibility with the standard array operations
> is a massive loss.
>
> Let's say I want to assign one range to another: b[] = a[];
> It's not clear to me why this should fall down if I want to apply a
> lazy operation for instance: b[] = a.map!(e=>e*2)[];
> ... or something to that effect.
>
> I find that my lazy ranges often end up on the stack, but I can't
> assign/initialise directly: float[] a = b.transform[];
> Instead I need to: float[] a;  b.transform.copy(a[]);
>
> The fact that they don't mix with array expressions or operators means
> as soon as a lazy range finds it wants to enter existing array code,
> it needs to be converted to a series of map()'s.
>
> There must be years of thoughts and work on this sort of thing?
> It seems arrays and ranges are unnecessarily distanced from
> eachother... what are the reasons for this?

Vlad Levenfeld has been doing some interesting work on just this sort of thing.  I will see if he is around.

> On Sunday, 26 April 2015 at 10:17:59 UTC, Manu wrote:
>> I find that my lazy ranges often end up on the stack, but I can't
>> assign/initialise directly: float[] a = b.transform[];
>> Instead I need to: float[] a;  b.transform.copy(a[]);

To enable the first line, builtin arrays would need to be able to recognize arbitrary range types and do the right thing. You can always do this:

  float[] a = b[].transform.array;

I've got a lib to enable this syntax:

  Array!float a = b[].transform_1;
  a[i..j] = c[x..y].transform_2;

for arbitrary user-defined or composed n-dimensional range types.

here: https://github.com/evenex/autodata

where ranges are made more interoperable by common mixin templates which also cut down on a lot of boilerplate.

(see examples in:
https://github.com/evenex/autodata/tree/master/source/spaces)

Manu, I just saw your other post clarifying the code was float[N] a = ..., not float[] a. That changes things a bit.

I just implemented a static array type in the lib (1-d only for now) which can do the following:

unittest {
	import std.range: only;

	StaticArray!(int, 2) x;

	assert (x[] == [0, 0]);

	x[0..2] = only (5, 6);

	assert (x[] == [5, 6]);

	x[] += 5;

	assert (x[] == [10, 11]);

	x[0..1] -= 5;

	assert (x[] == [5, 11]);

	StaticArray!(int, 4) y = only (1,2,3,4);

	assert (y[] == [1, 2, 3, 4]);

	auto z = only (9,8,7).static_array!([3]);

	assert (z[] == [9, 8, 7]);
}


Assertions are thrown if the assigned range doesn't match the static array length.

https://github.com/evenex/autodata/blob/master/source/spaces/array.d

On Sunday, 26 April 2015 at 18:48:15 UTC, Vlad Levenfeld wrote:
> I've got a lib to enable this syntax:
>
>   Array!float a = b[].transform_1;
>   a[i..j] = c[x..y].transform_2;

Phobos containers already support the first line, and it would be a natural extension to make them support the second.

> Phobos containers already support the first line, and it would be a natural extension to make them support the second.

Sure, it's not complicated. It's something I had done in this other code and showing for example.

On 27 April 2015 at 15:58, Vlad Levenfeld via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> Phobos containers already support the first line, and it would be a natural extension to make them support the second.
>
>
> Sure, it's not complicated. It's something I had done in this other code and showing for example.


Yeah, see I don't feel making a simple thing like an array into
something more complex by wrapping it in templates is ever a good
thing to do.
I just think it's a missed opportunity that the compiler doesn't
support any of this in the language.

It would appear at face value to be a great opportunity for lowering.
Assignment can lower to .copy(), operators can lower to map!(...)

I can tell you, if I tried to explain to my colleagues that we should wrap an array in a template so assignment works, they would laugh at me, then ridicule me, and then they would dismiss D. Better to say it's not supported than to show them that approach.

On Monday, 27 April 2015 at 06:52:11 UTC, Manu wrote:
> On 27 April 2015 at 15:58, Vlad Levenfeld via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>> Phobos containers already support the first line, and it would be a
>>> natural extension to make them support the second.
>>
>>
>> Sure, it's not complicated. It's something I had done in this other code and
>> showing for example.
>
>
> Yeah, see I don't feel making a simple thing like an array into
> something more complex by wrapping it in templates is ever a good
> thing to do.
> I just think it's a missed opportunity that the compiler doesn't
> support any of this in the language.
>
> It would appear at face value to be a great opportunity for lowering.
> Assignment can lower to .copy(), operators can lower to map!(...)

It's similar to foreach, which already recognizes input ranges, so why not...

On Monday, 27 April 2015 at 06:52:11 UTC, Manu wrote:
> On 27 April 2015 at 15:58, Vlad Levenfeld via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>> Phobos containers already support the first line, and it would be a
>>> natural extension to make them support the second.
>>
>>
>> Sure, it's not complicated. It's something I had done in this other code and
>> showing for example.
>
>
> Yeah, see I don't feel making a simple thing like an array into
> something more complex by wrapping it in templates is ever a good
> thing to do.
> I just think it's a missed opportunity that the compiler doesn't
> support any of this in the language.
>
> It would appear at face value to be a great opportunity for lowering.
> Assignment can lower to .copy(), operators can lower to map!(...)
>
> I can tell you, if I tried to explain to my colleagues that we should
> wrap an array in a template so assignment works, they would laugh at
> me, then ridicule me, and then they would dismiss D. Better to say
> it's not supported than to show them that approach.

Yeah, it is an excessive solution. I guess just wanted to talk about my thing and didn't think it through. I think laughing at and ridiculing are the same thing though. Anyway, lowering to copy built-in to the language, at least, would be pretty great. Especially if it worked like foreach and picked up local symbols, so that custom copy and map implementations could be used wherever they were defined.

On Monday, 27 April 2015 at 06:52:11 UTC, Manu wrote:
> On 27 April 2015 at 15:58, Vlad Levenfeld via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>> Phobos containers already support the first line, and it would be a
>>> natural extension to make them support the second.
>>
>>
>> Sure, it's not complicated. It's something I had done in this other code and
>> showing for example.
>
>
> Yeah, see I don't feel making a simple thing like an array into
> something more complex by wrapping it in templates is ever a good
> thing to do.
> I just think it's a missed opportunity that the compiler doesn't
> support any of this in the language.
>
> It would appear at face value to be a great opportunity for lowering.
> Assignment can lower to .copy(), operators can lower to map!(...)

builtin slicesopSliceAssign (and opSliceOpAssign) understanding ranges as source operands is a good idea. I might even see if I can implement it.

Lowering array operations to lazy ranges seems like a huge can of worms. Not so keen. Lazy array ops are great, but I don't see it working out as a builtin feature unless it had it's own syntax.