digitalmars.D - Tuples
- Russel Winder (15/15) May 26 2013 I wonder if people coming to D, looking for information about tuples,
- Diggory (11/19) May 26 2013 I found this especially confusing because the built-in Tuple is
- Jonathan M Davis (6/28) May 26 2013 I really wish that the term tuple didn't get used with the built-in tupl...
- Manu (23/52) May 26 2013 I have certainly been confused by the term 'tuple' used in D countless
- Jonathan M Davis (58/80) May 26 2013 You basically just have to worry about Tuple and TypeTuple. Tuple is of ...
- Diggory (32/145) May 26 2013 IMO we should have the following:
- Jonathan M Davis (16/21) May 26 2013 Well, changing TypeTuple to only accept types _will_ break code. It gets...
I wonder if people coming to D, looking for information about tuples, will get confused by http://dlang.org/tuple.html which seems to tell people they have to "roll their own", and http://dlang.org/phobos/std_typecons.html which tells people they have been pre-rolled in the standard library? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 26 2013
On Sunday, 26 May 2013 at 15:48:00 UTC, Russel Winder wrote:I wonder if people coming to D, looking for information about tuples, will get confused by http://dlang.org/tuple.html which seems to tell people they have to "roll their own", and http://dlang.org/phobos/std_typecons.html which tells people they have been pre-rolled in the standard library?I found this especially confusing because the built-in Tuple is defined differently. The Tuple in that example is equivalent to the definition of TypeTuple, and yet TypeTuple is supposedly specific to types while that example (as so by implication TypeTuple) apparently works just as well with other contents. On top of that Tuple is the one that only works with types - any string expressions are extracted and used as names... Surely a tuple which can only store types should be a TypeTyple and a tuple which can store anything should be a Tuple.
May 26 2013
Jonathan M Davis <jmdavisProg gmx.com> On Sunday, May 26, 2013 22:38:24 Diggory wrote:On Sunday, 26 May 2013 at 15:48:00 UTC, Russel Winder wrote:I really wish that the term tuple didn't get used with the built-in tuples / TypeTuples. They _aren't_ tuples. They're similar, but they don't nest, and they cause a lot of confusion with std.typecons.Tuple. And they're only compile-time constructs to boot. - Jonathan M DavisI wonder if people coming to D, looking for information about tuples, will get confused by http://dlang.org/tuple.html which seems to tell people they have to "roll their own", and http://dlang.org/phobos/std_typecons.html which tells people they have been pre-rolled in the standard library?I found this especially confusing because the built-in Tuple is defined differently. The Tuple in that example is equivalent to the definition of TypeTuple, and yet TypeTuple is supposedly specific to types while that example (as so by implication TypeTuple) apparently works just as well with other contents. On top of that Tuple is the one that only works with types - any string expressions are extracted and used as names... Surely a tuple which can only store types should be a TypeTyple and a tuple which can store anything should be a Tuple.
May 26 2013
I have certainly been confused by the term 'tuple' used in D countless times. It seems to exist in a variety of different contexts, and every time I think I understood it, I realise I'm probably wrong some time later. There seems to be poor/no documentation comparing/distinguishing various D tuples, also, there seems to be no real explicit syntax, which makes it hard to recognise. I can kinda handle a Tuple template, and then there are these type tuples, and then expression tuples? What is the relationship between these? Are they compatible? How do I distinguish them? Someone that understand what they're talking about should take some time to write a comprehensive article on the matter :) Some of the things I have read seem to presume that I already know what it's talking about, and as a result, lead to dismissing or misunderstanding the article. I think the practical take-away from my experience is that it ends up as one of those 'too hard' concepts, that I develop a tendency to actively avoid dealing with because it's confused me a number of times. I typically just start typing stuff and hope it works. And if it doesn't I fiddle with it until it eventually does (or I give up), and I never *really* understand why. I'll bet I'm not the only one... On 27 May 2013 10:25, Jonathan M Davis <jmdavisProg gmx.com> wrote:On Sunday, May 26, 2013 22:38:24 Diggory wrote:On Sunday, 26 May 2013 at 15:48:00 UTC, Russel Winder wrote:I really wish that the term tuple didn't get used with the built-in tuples / TypeTuples. They _aren't_ tuples. They're similar, but they don't nest, and they cause a lot of confusion with std.typecons.Tuple. And they're only compile-time constructs to boot. - Jonathan M DavisI wonder if people coming to D, looking for information about tuples, will get confused by http://dlang.org/tuple.html which seems to tell people they have to "roll their own", and http://dlang.org/phobos/std_typecons.html which tells people they have been pre-rolled in the standard library?I found this especially confusing because the built-in Tuple is defined differently. The Tuple in that example is equivalent to the definition of TypeTuple, and yet TypeTuple is supposedly specific to types while that example (as so by implication TypeTuple) apparently works just as well with other contents. On top of that Tuple is the one that only works with types - any string expressions are extracted and used as names... Surely a tuple which can only store types should be a TypeTyple and a tuple which can store anything should be a Tuple.
May 26 2013
On Monday, May 27, 2013 11:21:08 Manu wrote:I have certainly been confused by the term 'tuple' used in D countless times. It seems to exist in a variety of different contexts, and every time I think I understood it, I realise I'm probably wrong some time later. There seems to be poor/no documentation comparing/distinguishing various D tuples, also, there seems to be no real explicit syntax, which makes it hard to recognise. I can kinda handle a Tuple template, and then there are these type tuples, and then expression tuples? What is the relationship between these? Are they compatible? How do I distinguish them?You basically just have to worry about Tuple and TypeTuple. Tuple is of course very easy to understand. TypeTuple is then just an alias for the built-in tuples, which can hold basically anything. They're what template parameter lists, function parameter lists, template argument lists, and function argument lists are made of. And you can use them handily in other places (such as foreach) by using TypeTuple explicitly. I believe that an expression tuple is simply a TypeTuple which holds only expressions. In practice, I think that the differences are fairly simple, but they take quite a bit to wrap your head around - primarily due to the terminology used rather than the actual concept.Someone that understand what they're talking about should take some time to write a comprehensive article on the matter :)I guess that I'll have to look at doing that after I finish the article that I'm writing on ranges (that I really need to finish...).Some of the things I have read seem to presume that I already know what it's talking about, and as a result, lead to dismissing or misunderstanding the article.I generally know what's going on with D, but there were talks at dconf that taught be stuff about D that I'd either forgotten or never known (like some of what was going on with moves in Ali's talk). D is nowhere near as bad C++ with regards to how complicated it is, but it's still quite complicated.I think the practical take-away from my experience is that it ends up as one of those 'too hard' concepts, that I develop a tendency to actively avoid dealing with because it's confused me a number of times. I typically just start typing stuff and hope it works. And if it doesn't I fiddle with it until it eventually does (or I give up), and I never *really* understand why. I'll bet I'm not the only one...It's well worth understanding TypeTuple well enough to use it with foreach, as it's a great way to generate unit tests, particularly when you're dealing with templated functions. Phobos does that quite a lot, particularly with strings. Take splitLines unit test for example foreach (S; TypeTuple!(char[], wchar[], dchar[], string, wstring, dstring)) { auto s = to!S("\rpeter\n\rpaul\r\njerry\u2028ice\u2029cream\n\nsunday\n"); auto lines = splitLines(s); assert(lines.length == 9); assert(lines[0] == ""); assert(lines[1] == "peter"); assert(lines[2] == ""); assert(lines[3] == "paul"); assert(lines[4] == "jerry"); assert(lines[5] == "ice"); assert(lines[6] == "cream"); assert(lines[7] == ""); assert(lines[8] == "sunday"); lines = splitLines(s, KeepTerminator.yes); assert(lines.length == 9); assert(lines[0] == "\r"); assert(lines[1] == "peter\n"); assert(lines[2] == "\r"); assert(lines[3] == "paul\r\n"); assert(lines[4] == "jerry\u2028"); assert(lines[5] == "ice\u2029"); assert(lines[6] == "cream\n"); assert(lines[7] == "\n"); assert(lines[8] == "sunday\n"); s.popBack(); // Lop-off trailing \n lines = splitLines(s); assert(lines.length == 9); assert(lines[8] == "sunday"); lines = splitLines(s, KeepTerminator.yes); assert(lines.length == 9); assert(lines[8] == "sunday"); } You get to unit test with 6 different types while only writing the code once. That can be _extremely_ useful. - Jonathan M Davis
May 26 2013
On Monday, 27 May 2013 at 01:36:58 UTC, Jonathan M Davis wrote:On Monday, May 27, 2013 11:21:08 Manu wrote:IMO we should have the following: Tuple - Current Tuple implementation, equivalent to C++ tuple with the extra "naming" feature. Can be instantiated and passed around. StaticTuple - Current TypeTuple implementation, equivalent to type of "..." parameter in template arguments. Should not be instantiable. TypeTuple - A StaticTyple where all parts have been statically checked to be types. It should be easy to instantiate an actual Tuple using a TypeTuple. Note that the template system allows them to be the same type, ie. a StaticTuple!(int, float) == TypeTuple!(int, float) while a TypeTuple!("Hello") will fail to compile. ExpressionTuple - A StaticTuple where all parts have been statically checked to be expressions. It would be much easier to understand and it fills a big gap in the language - there's no guarantee than any methods such as "staticIndexOf" will work on the current "TypeTuple" if that tuple contains non-types. With the new system methods which can work on all types of static tuple can be moved to the "StaticTuple", while methods specific to a particular type of StaticTuple can be in the correct place. It also shouldn't break any code since the only addition to TypeTuple is a check to make sure that the undocumented behaviour of using it with non-types is disallowed, and in the case that this undocumented feature is used the code can simply switch to StaticTuple and be done. Another thing I'm not clear on is how "alias" template parameters interact with variadic parameters. Is it possible for a variadic parameter to be an alias? What happens if "alias T..." is used? (*goes off to check*)I have certainly been confused by the term 'tuple' used in D countless times. It seems to exist in a variety of different contexts, and every time I think I understood it, I realise I'm probably wrong some time later. There seems to be poor/no documentation comparing/distinguishing various D tuples, also, there seems to be no real explicit syntax, which makes it hard to recognise. I can kinda handle a Tuple template, and then there are these type tuples, and then expression tuples? What is the relationship between these? Are they compatible? How do I distinguish them?You basically just have to worry about Tuple and TypeTuple. Tuple is of course very easy to understand. TypeTuple is then just an alias for the built-in tuples, which can hold basically anything. They're what template parameter lists, function parameter lists, template argument lists, and function argument lists are made of. And you can use them handily in other places (such as foreach) by using TypeTuple explicitly. I believe that an expression tuple is simply a TypeTuple which holds only expressions. In practice, I think that the differences are fairly simple, but they take quite a bit to wrap your head around - primarily due to the terminology used rather than the actual concept.Someone that understand what they're talking about should take some time to write a comprehensive article on the matter :)I guess that I'll have to look at doing that after I finish the article that I'm writing on ranges (that I really need to finish...).Some of the things I have read seem to presume that I already know what it's talking about, and as a result, lead to dismissing or misunderstanding the article.I generally know what's going on with D, but there were talks at dconf that taught be stuff about D that I'd either forgotten or never known (like some of what was going on with moves in Ali's talk). D is nowhere near as bad C++ with regards to how complicated it is, but it's still quite complicated.I think the practical take-away from my experience is that it ends up as one of those 'too hard' concepts, that I develop a tendency to actively avoid dealing with because it's confused me a number of times. I typically just start typing stuff and hope it works. And if it doesn't I fiddle with it until it eventually does (or I give up), and I never *really* understand why. I'll bet I'm not the only one...It's well worth understanding TypeTuple well enough to use it with foreach, as it's a great way to generate unit tests, particularly when you're dealing with templated functions. Phobos does that quite a lot, particularly with strings. Take splitLines unit test for example foreach (S; TypeTuple!(char[], wchar[], dchar[], string, wstring, dstring)) { auto s = to!S("\rpeter\n\rpaul\r\njerry\u2028ice\u2029cream\n\nsunday\n"); auto lines = splitLines(s); assert(lines.length == 9); assert(lines[0] == ""); assert(lines[1] == "peter"); assert(lines[2] == ""); assert(lines[3] == "paul"); assert(lines[4] == "jerry"); assert(lines[5] == "ice"); assert(lines[6] == "cream"); assert(lines[7] == ""); assert(lines[8] == "sunday"); lines = splitLines(s, KeepTerminator.yes); assert(lines.length == 9); assert(lines[0] == "\r"); assert(lines[1] == "peter\n"); assert(lines[2] == "\r"); assert(lines[3] == "paul\r\n"); assert(lines[4] == "jerry\u2028"); assert(lines[5] == "ice\u2029"); assert(lines[6] == "cream\n"); assert(lines[7] == "\n"); assert(lines[8] == "sunday\n"); s.popBack(); // Lop-off trailing \n lines = splitLines(s); assert(lines.length == 9); assert(lines[8] == "sunday"); lines = splitLines(s, KeepTerminator.yes); assert(lines.length == 9); assert(lines[8] == "sunday"); } You get to unit test with 6 different types while only writing the code once. That can be _extremely_ useful. - Jonathan M Davis
May 26 2013
On Monday, May 27, 2013 04:24:51 Diggory wrote:It also shouldn't break any code since the only addition to TypeTuple is a check to make sure that the undocumented behaviour of using it with non-types is disallowed, and in the case that this undocumented feature is used the code can simply switch to StaticTuple and be done.Well, changing TypeTuple to only accept types _will_ break code. It gets used quite heavily with foreach to get a static foreach, and that can involve using expressions instead of types. Anyone using TypeTuple heavily knows what it can do and will probably have used it for expressions at some point. It wouldn't surprise me in the least if it's already done in Phobos, and there's no way to know how much it is or isn't done elsewhere. Because you're generally in control of the TypeTuples that you're using (you aren't usually getting the from APIs and the like), I really don' think that the fact that it can hold both types and expressions is a big deal. I expect that it pretty much never causes problems in actual code. It just makes it so that the name sucks. I don't think that we'd gain much (if anything) by separating out TypeTuple into three different types. Renaming it would be nice, but given the current push to stop making breaking changes like that, I would expect that at best, we'd get an alias with a better name. - Jonathan M Davis
May 26 2013
On Monday, 27 May 2013 at 02:31:50 UTC, Jonathan M Davis wrote:On Monday, May 27, 2013 04:24:51 Diggory wrote:Hmm, given that the fix can be entirely automated incredibly simply with find and replace it doesn't seem that bad, especially as the broken behaviour is undocumented. Given that the documentation specifically disambiguates between TypeTuples and ExpressionTuples I think at least emitting a warning when non-types are used to a TypeTuple is reasonable.It also shouldn't break any code since the only addition to TypeTuple is a check to make sure that the undocumented behaviour of using it with non-types is disallowed, and in the case that this undocumented feature is used the code can simply switch to StaticTuple and be done.Well, changing TypeTuple to only accept types _will_ break code. It gets used quite heavily with foreach to get a static foreach, and that can involve using expressions instead of types. Anyone using TypeTuple heavily knows what it can do and will probably have used it for expressions at some point. It wouldn't surprise me in the least if it's already done in Phobos, and there's no way to know how much it is or isn't done elsewhere. Because you're generally in control of the TypeTuples that you're using (you aren't usually getting the from APIs and the like), I really don' think that the fact that it can hold both types and expressions is a big deal. I expect that it pretty much never causes problems in actual code. It just makes it so that the name sucks. I don't think that we'd gain much (if anything) by separating out TypeTuple into three different types. Renaming it would be nice, but given the current push to stop making breaking changes like that, I would expect that at best, we'd get an alias with a better name. - Jonathan M Davis
May 26 2013
On Monday, 27 May 2013 at 02:31:50 UTC, Jonathan M Davis wrote:On Monday, May 27, 2013 04:24:51 Diggory wrote:Granted that nobody understand them, it is fair to say it should be changed.It also shouldn't break any code since the only addition to TypeTuple is a check to make sure that the undocumented behaviour of using it with non-types is disallowed, and in the case that this undocumented feature is used the code can simply switch to StaticTuple and be done.Well, changing TypeTuple to only accept types _will_ break code. It gets used quite heavily with foreach to get a static foreach, and that can involve using expressions instead of types. Anyone using TypeTuple heavily knows what it can do and will probably have used it for expressions at some point. It wouldn't surprise me in the least if it's already done in Phobos, and there's no way to know how much it is or isn't done elsewhere.
May 26 2013
On Monday, 27 May 2013 at 03:28:07 UTC, deadalnix wrote:On Monday, 27 May 2013 at 02:31:50 UTC, Jonathan M Davis wrote:In case people agree: https://github.com/D-Programming-Language/phobos/pull/1309On Monday, May 27, 2013 04:24:51 Diggory wrote:Granted that nobody understand them, it is fair to say it should be changed.It also shouldn't break any code since the only addition to TypeTuple is a check to make sure that the undocumented behaviour of using it with non-types is disallowed, and in the case that this undocumented feature is used the code can simply switch to StaticTuple and be done.Well, changing TypeTuple to only accept types _will_ break code. It gets used quite heavily with foreach to get a static foreach, and that can involve using expressions instead of types. Anyone using TypeTuple heavily knows what it can do and will probably have used it for expressions at some point. It wouldn't surprise me in the least if it's already done in Phobos, and there's no way to know how much it is or isn't done elsewhere.
May 27 2013
On Monday, 27 May 2013 at 09:25:14 UTC, Diggory wrote:I'm all for it. Thank you.Granted that nobody understand them, it is fair to say it should be changed.In case people agree: https://github.com/D-Programming-Language/phobos/pull/1309
May 27 2013