www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why tuples are not ranges?

reply Mr.Bingo <Bingo Namo.com> writes:
Seems like it would unify things quite a bit.

import std.typecons, std.range, std.array, std.algorithm, 
std.stdio;

void main()
{
	auto t = tuple(3,4,5,6);
	//auto t = [3,4,5,6];
	
	writeln(t.map!(a => 3*a).sum());
	
	
}
Jun 28 2018
next sibling parent Timoses <timosesu gmail.com> writes:
On Thursday, 28 June 2018 at 14:35:33 UTC, Mr.Bingo wrote:
 Seems like it would unify things quite a bit.

 import std.typecons, std.range, std.array, std.algorithm, 
 std.stdio;

 void main()
 {
 	auto t = tuple(3,4,5,6);
 	//auto t = [3,4,5,6];
 	
 	writeln(t.map!(a => 3*a).sum());
 	
 	
 }
You could make a range out of tuples. This seems to work: import std.typecons, std.range, std.array, std.algorithm, std.stdio; void main() { auto t = tuple(3,4,5,6); auto m = t.expand.only; writeln(m.map!(a => 3*a).sum()); } Tuple.expand will expand the elements when calling a function (in this case only from std.range). https://dlang.org/library/std/typecons/tuple.expand.html
Jun 28 2018
prev sibling parent reply Alex <sascha.orlov gmail.com> writes:
On Thursday, 28 June 2018 at 14:35:33 UTC, Mr.Bingo wrote:
 Seems like it would unify things quite a bit.
Yeah... this is, because you can't popFront on a tuple, as the amount of entries is fixed. You can, however, popFront on every range. But as Timoses wrote you can easily make a range out of a tuple, for example by slicing: ´´´ import std.typecons, std.range, std.array, std.algorithm, std.stdio; void main() { auto t = tuple(3,4,5,6); auto m = [t[]]; writeln(m.map!(a => 3*a).sum()); } ´´´
Jun 28 2018
parent reply Mr.Bingo <Bingo Namo.com> writes:
On Thursday, 28 June 2018 at 16:02:59 UTC, Alex wrote:
 On Thursday, 28 June 2018 at 14:35:33 UTC, Mr.Bingo wrote:
 Seems like it would unify things quite a bit.
Yeah... this is, because you can't popFront on a tuple, as the amount of entries is fixed. You can, however, popFront on every range. But as Timoses wrote you can easily make a range out of a tuple, for example by slicing: ´´´ import std.typecons, std.range, std.array, std.algorithm, std.stdio; void main() { auto t = tuple(3,4,5,6); auto m = [t[]]; writeln(m.map!(a => 3*a).sum()); } ´´´
But is this going to be optimized? BTW, surely the tuple has a popFront! Just pop the last element and returns a new tuple. That is, a tuple is a range! Just because it doesn't implement the proper functions doesn't mean it can't do so. It is clearly easy to see if a tuple is empty, to get the front, and to pop the front and return a new tuple with n - 1 elements, which is really just the tuple(a sliced tuple, say) with the first member hidden. Since a tuple is fixed at compile time you can "virtually" pop the elements, it doesn't mean that a tuple is not a range. So, maybe for it to work the compiler needs to be able to slice tuples efficiently(not convert to dynamic arrays). This is moot if the compiler can realize that it can do most of the work at compile time but I'm not so sure it can. I mean, if you think about it, the memory layout of a tuple is sequential types: T1 T2 ... So, to popFront a tuple is just changing the starting offset.
Jun 28 2018
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/28/2018 10:00 AM, Mr.Bingo wrote:

 But is this going to be optimized?
Not our job! :o)
 That is, a tuple is a range!
Similar to the array-slice distinction, tuple is a container, needing its range.
 It is clearly easy to see if a tuple is empty, to get the front,
Ok.
 and to
 pop the front and return a new tuple with n - 1 elements, which is
 really just the tuple(a sliced tuple, say) with the first member hidden.
That would be special for tuples because popFront does not return a new range (and definitely not with a new type) but mutates the existing one. Here is a quick and dirty library solution: // TODO: Template constraints auto rangified(T)(T t) { import std.traits : CommonType; import std.conv : to; alias ElementType = CommonType!(T.tupleof); struct Range { size_t i; bool empty() { return i >= t.length; } ElementType front() { final switch (i) { static foreach (j; 0 .. t.length) { case j: return t[j].to!ElementType; } } } void popFront() { ++i; } enum length = t.length; // TODO: save(), opIndex(), etc. } return Range(); } unittest { import std.typecons : tuple; import std.stdio : writefln; import std.range : ElementType; auto t = tuple(5, 3.5, false); auto r = t.rangified; writefln("%s elements of '%s': %(%s, %)", r.length, ElementType!(typeof(r)).stringof, r); } void main() { } Prints 3 elements of 'double': 5, 3.5, 0 Ali
Jun 28 2018
parent reply Mr.Bingo <Bingo Namo.com> writes:
On Thursday, 28 June 2018 at 18:03:09 UTC, Ali Çehreli wrote:
 On 06/28/2018 10:00 AM, Mr.Bingo wrote:

 But is this going to be optimized?
Not our job! :o)
 That is, a tuple is a range!
Similar to the array-slice distinction, tuple is a container, needing its range.
 It is clearly easy to see if a tuple is empty, to get the
front, Ok.
 and to
 pop the front and return a new tuple with n - 1 elements,
which is
 really just the tuple(a sliced tuple, say) with the first
member hidden. That would be special for tuples because popFront does not return a new range (and definitely not with a new type) but mutates the existing one. Here is a quick and dirty library solution: // TODO: Template constraints auto rangified(T)(T t) { import std.traits : CommonType; import std.conv : to; alias ElementType = CommonType!(T.tupleof); struct Range { size_t i; bool empty() { return i >= t.length; } ElementType front() { final switch (i) { static foreach (j; 0 .. t.length) { case j: return t[j].to!ElementType; } } } void popFront() { ++i; } enum length = t.length; // TODO: save(), opIndex(), etc. } return Range(); } unittest { import std.typecons : tuple; import std.stdio : writefln; import std.range : ElementType; auto t = tuple(5, 3.5, false); auto r = t.rangified; writefln("%s elements of '%s': %(%s, %)", r.length, ElementType!(typeof(r)).stringof, r); } void main() { } Prints 3 elements of 'double': 5, 3.5, 0 Ali
Thanks, why not add the ability to pass through ranges and arrays and add it to phobos?
Jun 28 2018
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/28/2018 11:08 AM, Mr.Bingo wrote:

 Thanks, why not add the ability to pass through ranges and arrays and
 add it to phobos?
Makes sense. It needs an enhancement request at http://issues.dlang.org/, a good implementation, and a pull request. :) Ali
Jun 28 2018
parent reply Alex <sascha.orlov gmail.com> writes:
On Thursday, 28 June 2018 at 19:02:51 UTC, Ali Çehreli wrote:
 On 06/28/2018 11:08 AM, Mr.Bingo wrote:

 Thanks, why not add the ability to pass through ranges and
arrays and
 add it to phobos?
Makes sense. It needs an enhancement request at http://issues.dlang.org/, a good implementation, and a pull request. :) Ali
Wouldn't this be weird from the semantic view? Assume, I define a tuple with named fields "key" and "value", where a popFront is defined. Now, I use popFront. Is the "key" field still available? Why? Or, why not? What happens, if I name a field of a tuple "front"? Is it available after using popFront? And where does it point to? I mean, I use something similar in my own project, but doesn't one has to make a clear distinction between a container and a slice of this container? Or should static arrays be unified in the same manner?
Jun 28 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, June 29, 2018 05:52:03 Alex via Digitalmars-d-learn wrote:
 On Thursday, 28 June 2018 at 19:02:51 UTC, Ali ehreli wrote:
 On 06/28/2018 11:08 AM, Mr.Bingo wrote:
 Thanks, why not add the ability to pass through ranges and
arrays and
 add it to phobos?
Makes sense. It needs an enhancement request at http://issues.dlang.org/, a good implementation, and a pull request. :) Ali
Wouldn't this be weird from the semantic view? Assume, I define a tuple with named fields "key" and "value", where a popFront is defined. Now, I use popFront. Is the "key" field still available? Why? Or, why not? What happens, if I name a field of a tuple "front"? Is it available after using popFront? And where does it point to? I mean, I use something similar in my own project, but doesn't one has to make a clear distinction between a container and a slice of this container? Or should static arrays be unified in the same manner?
It wouldn't make any sense to turn a Tuple into a range. However, if all of the values are of the same type, it might make sense to create a range from each of the values in the Tuple. Just like static arrays, they're indexable, so there's a clear order to them. So, I suppose that Tuple could be made sliceable, or a helper function could be created that takes a Tuple and returns a range which wraps it. However, Tuples frequently have different types for each of their members (in which case, creating a range from a Tuple makes no sense at all), and really, a Tuple is essentially a way to declare a POD struct of values without explicitly declaring a struct. And at that point, talking about getting a range over a Tuple is basically the same thing as talking about creating a range from an arbitrary struct whose members all happen to have the same type - and that would be pretty weird. So, under limited circumstances, a range could be constructed from a Tuple, but in general, it just strikes me as a bizarre thing to do. Tuples and ranges are very distinct concepts, and Tuples aren't really containers. - Jonathan M Davis
Jun 28 2018
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/28/2018 11:10 PM, Jonathan M Davis wrote:
 On Friday, June 29, 2018 05:52:03 Alex via Digitalmars-d-learn wrote:
 Wouldn't this be weird from the semantic view?
I agree with all your concerns. The fact that Meta decided to make the element type Algebraic!T as opposed to my CommonType!T choice is another semantic problem.
 It wouldn't make any sense to turn a Tuple into a range. However, if 
all of
 the values are of the same type, it might make sense to create a 
range from
 each of the values in the Tuple.
I went a step further and used CommonType!T.
 a helper function could be created that takes a Tuple and
 returns a range which wraps it.
That's what my example did (with added bugs like 'length' being an enum by mistake).
 And at that point, talking about
 getting a range over a Tuple is basically the same thing as talking about
 creating a range from an arbitrary struct whose members all happen to 
have
 the same type - and that would be pretty weird.
Agreed. Ali
Jun 29 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/29/18 1:35 PM, Ali Çehreli wrote:
 On 06/28/2018 11:10 PM, Jonathan M Davis wrote:
  > On Friday, June 29, 2018 05:52:03 Alex via Digitalmars-d-learn wrote:
 
  >> Wouldn't this be weird from the semantic view?
 
 I agree with all your concerns. The fact that Meta decided to make the 
 element type Algebraic!T as opposed to my CommonType!T choice is another 
 semantic problem.
 
  > It wouldn't make any sense to turn a Tuple into a range. However, if 
 all of
  > the values are of the same type, it might make sense to create a 
 range from
  > each of the values in the Tuple.
 
 I went a step further and used CommonType!T.
Isn't this what only does? https://dlang.org/phobos/std_range.html#only -Steve
Jun 30 2018
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/30/2018 05:17 AM, Steven Schveighoffer wrote:

 Isn't this what only does? https://dlang.org/phobos/std_range.html#only
Cool. :) import std.range : only; auto t = tuple(5, 3.5, false); auto r = only(t.expand); Ali
Jun 30 2018
prev sibling parent Meta <jared771 gmail.com> writes:
On Thursday, 28 June 2018 at 17:00:37 UTC, Mr.Bingo wrote:
 I mean, if you think about it, the memory layout of a tuple is 
 sequential types:

 T1
 T2
 ...

 So, to popFront a tuple is just changing the starting offset.
You're right; it can definitely be done. struct TupleRange(T...) { size_t index; Tuple!T store; property length() { assert(index <= store.length); return store.length - index; } Algebraic!T front() { assert(length > 0); return typeof(return)(store[index]); } void popFront() { assert(length > 0); index++; } }
Jun 28 2018