www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Last call for AliasSeq

reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
Martin has just merged the rename of `TypeTuple` to `AliasSeq` 
into the stable branch, which will be released soon. If anyone 
wants to change the name again, please open a PR immediately, 
this is the last chance.
Jul 24 2015
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote:

 Martin has just merged the rename of `TypeTuple` to `AliasSeq` 
 into the stable branch, which will be released soon. If anyone 
 wants to change the name again, please open a PR immediately, 
 this is the last chance.


Here are the final results of the poll if any one cares...
AliasTuple		3.083333333
AliasList		2.85
Aliases			2.716666667
AliasSeq		2.55
AliasPack		2.516666667
Pack			2.266666667
TemplateArgumentList 	2.15
Arguments		2.066666667
TypeTuple		2.016666667
CtTuple			1.983333333
ArgPack			1.9
ParamPack		1.833333333
ArgumentsTuple		1.783333333
AliasArray		1.766666667
AliasSplat		1.716666667
CompileTimeTuple	1.716666667
Splat			1.683333333
Identities		1.6
Tuple			1.566666667
Identity		1.55
AliasGroup		1.466666667
List			1.416666667
AliasSet		1.416666667
TemplateSplat		1.4
MixedList		1.4
OmniSplat		1.35
AliasBag		1.266666667
AliasLine		1.166666667
Bag			1.166666667
AliasBall		1.133333333
AliasPile		1.133333333
AliasBeads		1.1
Jul 24 2015
next sibling parent "Daniel N" <ufo orbiting.us> writes:
On Friday, 24 July 2015 at 10:35:35 UTC, Tofu Ninja wrote:

 On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote:

 Martin has just merged the rename of `TypeTuple` to `AliasSeq` 
 into the stable branch, which will be released soon. If anyone 
 wants to change the name again, please open a PR immediately, 
 this is the last chance.


 Here are the final results of the poll if any one cares...
 AliasTuple		3.083333333
 AliasList		2.85
 Aliases			2.716666667
 AliasSeq		2.55


Even though I personally favor tuple, 'Aliases' has the "extra 
umph that the BDFL favors it" as well as scoring higher in the 
poll than 'AliasSeq'.
Jul 24 2015
prev sibling parent reply "Enamex" <enamex+d outlook.com> writes:
On Friday, 24 July 2015 at 10:35:35 UTC, Tofu Ninja wrote:

 On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote:

 Martin has just merged the rename of `TypeTuple` to `AliasSeq` 
 into the stable branch, which will be released soon. If anyone 
 wants to change the name again, please open a PR immediately, 
 this is the last chance.


 Here are the final results of the poll if any one cares...
 AliasTuple		3.083333333
 AliasList		2.85
 Aliases			2.716666667
 AliasSeq		2.55


Why is the poll at odds with the supposed-to-be-final decision?
Jul 26 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, 27 July 2015 at 01:52:34 UTC, Enamex wrote:

 On Friday, 24 July 2015 at 10:35:35 UTC, Tofu Ninja wrote:

 On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote:

 Martin has just merged the rename of `TypeTuple` to 
 `AliasSeq` into the stable branch, which will be released 
 soon. If anyone wants to change the name again, please open a 
 PR immediately, this is the last chance.


 Here are the final results of the poll if any one cares...
 AliasTuple		3.083333333
 AliasList		2.85
 Aliases			2.716666667
 AliasSeq		2.55


 Why is the poll at odds with the supposed-to-be-final decision?


Because the decision is not going to be made based on a 
popularity contest, and many of the folks who have been 
discussing this have not voted in that poll. Also, there is no 
clear winner in the poll anyway. AliasTuple is slightly ahead, 
but remember that _5_ was the top, not 3. So, the ones at the 
"top" of the list are far from being universally liked.

AliasTuple in particular has serious issues with it from the 
perspective of teaching people what it is an how to use it, 
because it has Tuple in its name, and the construct in question 
is not actually a tuple (in addition to being easily confused 
with std.typecons.Tuple). This has been shown time and time again 
with TypeTuple.

On technical merit, AliasSeq is one of the better choices; it was 
what TypeTuple had been changed to prior to the recent, large 
discussion on it; and none of the new suggestions are better 
enough to win any kind of consensus. At this point, for it to be 
changed, Walter and Andrei need to step in and choose something 
else. Otherwise, it's just going to stay AliasSeq, and it will be 
final, because we're not changing it again after 2.068 goes out. 
But thus far, they haven't changed it and have let it stay as 
AliasSeq, and the window of time for them to change it is 
shrinking fast. Regardless, even if the decision were to be made 
based on the poll, it would be Walter and Andrei making that 
decision, because it is abundantly clear that the community is 
unable to come to a consensus on this.

- Jonathan M Davis
Jul 26 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis wrote:

 On technical merit, AliasSeq is one of the better choices; it 
 was what TypeTuple had been changed to prior to the recent,


On technical merits "Seq" is one of the worst choices, let's not 
confuse social dynamics with objectivity.
Jul 27 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/27/2015 10:12 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis wrote:

 On technical merit, AliasSeq is one of the better choices; it was what
 TypeTuple had been changed to prior to the recent,


 On technical merits "Seq" is one of the worst choices, let's not confuse
 social dynamics with objectivity.


Your particular flavour of objectivity.
Jul 27 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 27 July 2015 at 20:47:08 UTC, Timon Gehr wrote:

 On 07/27/2015 10:12 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis 
 wrote:

 On technical merit, AliasSeq is one of the better choices; it 
 was what
 TypeTuple had been changed to prior to the recent,


 On technical merits "Seq" is one of the worst choices, let's 
 not confuse
 social dynamics with objectivity.


 Your particular flavour of objectivity.


No. It means I can argue my point and provide references.
Jul 27 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/28/2015 05:23 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Monday, 27 July 2015 at 20:47:08 UTC, Timon Gehr wrote:

 On 07/27/2015 10:12 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis wrote:

 On technical merit, AliasSeq is one of the better choices; it was what
 TypeTuple had been changed to prior to the recent,


 On technical merits "Seq" is one of the worst choices, let's not confuse
 social dynamics with objectivity.


 Your particular flavour of objectivity.


 No. It means I can argue my point and provide references.


There's a bootstrapping problem. It's not even clear what "objectivity" 
means here. You have not explicitly listed the criteria you were using 
and how you weighted them, neither have you made a convincing point for 
them nor provided relevant references. Unless I missed it, that is.

Anyway, it should be pretty clear that all proposed names are bad for 
some reasonable choice of "objectivity". If you want to avoid a bad 
name, suggest a good one.
Jul 27 2015
next sibling parent "Ola Fosheim Gr" <ola.fosheim.grostad+dlang gmail.com> writes:
On Tuesday, 28 July 2015 at 03:59:54 UTC, Timon Gehr wrote:

 There's a bootstrapping problem. It's not even clear what 
 "objectivity" means here.


It means there were no technical merits that lead to "Seq". Only 
social dynamics and psychology.


 If you want to avoid a bad name, suggest a good one.


Several acceptable ones have been suggested. And the argument 
against "AliasTuple" is weak given that you already have an 
unusual Tuple and that "Seq" is bound to break consistency.

I don't want to change a name. I want to see a sound design 
process that can lead to an enjoyable language.
Jul 28 2015
prev sibling parent reply "Daniel N" <ufo orbiting.us> writes:
On Tuesday, 28 July 2015 at 03:59:54 UTC, Timon Gehr wrote:

 Anyway, it should be pretty clear that all proposed names are 
 bad for some reasonable choice of "objectivity". If you want to 
 avoid a bad name, suggest a good one.


I suggest we remove it without replacement.

The original intention from...
https://web.archive.org/web/20120111015958/http://dlang.org/tuple.html
... suggested that the user should declare their own 
'Unspeakable'.(what I have been doing).

Unfortunately TypeTuple was made available without proper 
template constraints, due to the path of least resistance, people 
started using it for everything.

Surely it better, either to not change it at all, or to remove it 
rather than adding something most feel is bad?
Jul 28 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 28 July 2015 at 07:57:36 UTC, Daniel N wrote:

 On Tuesday, 28 July 2015 at 03:59:54 UTC, Timon Gehr wrote:

 Anyway, it should be pretty clear that all proposed names are 
 bad for some reasonable choice of "objectivity". If you want 
 to avoid a bad name, suggest a good one.


 I suggest we remove it without replacement.

 The original intention from...
 https://web.archive.org/web/20120111015958/http://dlang.org/tuple.html
 ... suggested that the user should declare their own 
 'Unspeakable'.(what I have been doing).

 Unfortunately TypeTuple was made available without proper 
 template constraints, due to the path of least resistance, 
 people started using it for everything.

 Surely it better, either to not change it at all, or to remove 
 it rather than adding something most feel is bad?


Template constraints? Why on earth would TypeTuple need template 
constraints? Because it was badly named and has Type in its name? 
It holds more than types and that's a _good_ thing. TypeTuple is 
incredibly useful - especially for unit testing, and forcing you 
to declare it yourself is just wasteful. We're definitely going 
to have it. It's just a question of what it's going to be called. 
And no one has a good name for it. Alias fits the bill far better 
than type, since essentially, it's a list of aliases, so we're 
definitely going with Alias in the name. It's just a question of 
what the second half of its name is, and Seq gives the fewest 
wrong preconceptions about what the thing is, which is why it was 
picked. It's still a sucky name, but _all_ of the names suck.

Regardless, we're definitely not getting rid of it. That would 
make no sense at all.

- Jonathan M Davis
Jul 28 2015
next sibling parent "Daniel N" <ufo orbiting.us> writes:
On Tuesday, 28 July 2015 at 08:11:20 UTC, Jonathan M Davis wrote:

 Template constraints? Why on earth would TypeTuple need 
 template constraints? Because it was badly named and has Type 
 in its name? It holds more than types and that's a _good_ thing.


Yes, following the original intention, plain Tuple was the 
unconstrained version.

It has a perfectly find name given this definition from 
tuple.html:
"Type Tuples

If a tuple's elements are solely types, it is called a TypeTuple"
Jul 28 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 28 July 2015 at 08:11:20 UTC, Jonathan M Davis wrote:

 half of its name is, and Seq gives the fewest wrong 
 preconceptions about what the thing is, which is why it was 
 picked. It's still a sucky name, but _all_ of the names suck.


How do you know that it will give the fewest wrong 
preconceptions? For anyone that work with sequences it most 
certainly is doomed to give the wrong preconception.

Define a vocabulary with clean semantics for D and stick with it. 
If the only key difference between Tuple and TypeTuple is auto 
expansion, then change the semantics and add a separate construct 
for expansion.
Jul 28 2015
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis wrote:

 AliasTuple in particular has serious issues with it from the 
 perspective of teaching people what it is an how to use it, 
 because it has Tuple in its name,


People keep claiming that, but have never posted any evidence. We 
know that _TypeTuple_ had issues, but for all we know, the 
problem was the "Type" part, not the "Tuple" part.


 and the construct in question is not actually a tuple


And that's IMO another really bizarre claim. Of course it's a 
tuple.


 (in addition to being easily confused with std.typecons.Tuple). 
 This has been shown time and time again with TypeTuple.

 On technical merit, AliasSeq is one of the better choices; it 
 was what TypeTuple had been changed to prior to the recent, 
 large discussion on it; and none of the new suggestions are 
 better enough to win any kind of consensus.


If ease of learning / avoidance of misunderstandings is a goal, 
it's clear that AliasSeq is one of the worst choices. The term 
"sequence" - in all other related areas of science or engineering 
- invokes certain associations that don't fit this thing at all. 
This has been brought up by several people, but it's just getting 
ignored by the proponents.

As for Andrei and Walter: From what I've seen, they, too, agree 
that AliasSeq is bad. Andrei's critique even started that other 
thread.
Jul 27 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 27 July 2015 at 09:01:33 UTC, Marc Schütz wrote:

 On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis wrote:

 AliasTuple in particular has serious issues with it from the 
 perspective of teaching people what it is an how to use it, 
 because it has Tuple in its name,


 People keep claiming that, but have never posted any evidence. 
 We know that _TypeTuple_ had issues, but for all we know, the 
 problem was the "Type" part, not the "Tuple" part.


We have various reports that are consistent and confirm this is 
an issue. At this point, this is a repeatable experiment, not an 
anecdote anymore. Ignoring repeatable experiment puts you in the 
tinfoil hat section of the population. You don't want to be there.


 and the construct in question is not actually a tuple


 And that's IMO another really bizarre claim. Of course it's a 
 tuple.


Technically you are right. But in fact, this is NOT what people 
EXPECT a tuple to be.


 (in addition to being easily confused with 
 std.typecons.Tuple). This has been shown time and time again 
 with TypeTuple.

 On technical merit, AliasSeq is one of the better choices; it 
 was what TypeTuple had been changed to prior to the recent, 
 large discussion on it; and none of the new suggestions are 
 better enough to win any kind of consensus.


 If ease of learning / avoidance of misunderstandings is a goal, 
 it's clear that AliasSeq is one of the worst choices. The term 
 "sequence" - in all other related areas of science or 
 engineering - invokes certain associations that don't fit this 
 thing at all. This has been brought up by several people, but 
 it's just getting ignored by the proponents.


It is not ignored. It is simply that alternative proposal also 
have issues, and many of them have issues that are worse. No 
proposal was significantly better so that it reached any kind of 
consensus.

No your personal favorite did not either.


 As for Andrei and Walter: From what I've seen, they, too, agree 
 that AliasSeq is bad. Andrei's critique even started that other 
 thread.


Yet, nobody came with anything significantly better, so here it 
is.
Jul 27 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Monday, 27 July 2015 at 22:52:11 UTC, deadalnix wrote:

 On Monday, 27 July 2015 at 09:01:33 UTC, Marc Schütz wrote:

 On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis 
 wrote:

 AliasTuple in particular has serious issues with it from the 
 perspective of teaching people what it is an how to use it, 
 because it has Tuple in its name,


 People keep claiming that, but have never posted any evidence. 
 We know that _TypeTuple_ had issues, but for all we know, the 
 problem was the "Type" part, not the "Tuple" part.


 We have various reports that are consistent and confirm this is 
 an issue. At this point, this is a repeatable experiment, not 
 an anecdote anymore. Ignoring repeatable experiment puts you in 
 the tinfoil hat section of the population. You don't want to be 
 there.


Well, your post kind of proves my point. You've stated this 
several times, and you mentioned that people had problems, but as 
evidence you only mentioned some obscure irc communications that 
- for all I know - no one except you has ever seen. Now, I could 
simply believe you there (after all you're a competent person), 
but... that's not very scientific at all. If you say that these 
are repeatable experiments, with a representative sample of the 
programming community (or even just beginners), with consistent 
outcomes, then I prefer to see evidence for these claims before I 
believe them. I'm therefore not ignoring experiments, I have 
doubts about the validity of said experiments.


 It is not ignored. It is simply that alternative proposal also 
 have issues, and many of them have issues that are worse. No 
 proposal was significantly better so that it reached any kind 
 of consensus.

 No your personal favorite did not either.


I don't have a strong personal favourite, I just have a strong 
anti-favourite :-)
Jul 28 2015
parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Tuesday, 28 July 2015 at 08:54:34 UTC, Marc Schütz wrote:

 On Monday, 27 July 2015 at 22:52:11 UTC, deadalnix wrote:

 On Monday, 27 July 2015 at 09:01:33 UTC, Marc Schütz wrote:

 On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis 
 wrote:

 AliasTuple in particular has serious issues with it from the 
 perspective of teaching people what it is an how to use it, 
 because it has Tuple in its name,


 People keep claiming that, but have never posted any 
 evidence. We know that _TypeTuple_ had issues, but for all we 
 know, the problem was the "Type" part, not the "Tuple" part.


 We have various reports that are consistent and confirm this 
 is an issue. At this point, this is a repeatable experiment, 
 not an anecdote anymore. Ignoring repeatable experiment puts 
 you in the tinfoil hat section of the population. You don't 
 want to be there.


 Well, your post kind of proves my point. You've stated this 
 several times, and you mentioned that people had problems, but 
 as evidence you only mentioned some obscure irc communications 
 that - for all I know - no one except you has ever seen. Now, I 
 could simply believe you there (after all you're a competent 
 person), but... that's not very scientific at all. If you say 
 that these are repeatable experiments, with a representative 
 sample of the programming community (or even just beginners), 
 with consistent outcomes, then I prefer to see evidence for 
 these claims before I believe them. I'm therefore not ignoring 
 experiments, I have doubts about the validity of said 
 experiments.


That's nonsense.

Being a company that regularly teaches D to newcomers, I can 
confirm that in the real world it's a mess to teach TypeTuple.

And IMHO that is the common experience of everyone that has to 
deal regularly with someone that he's learning D in the 
development department.

Dicebot, feel free to correct me, but I think that this is also 
what you are experiencing day by day in Berlin...

So, literally, what we are talking about? That's a fact, not a 
speculation, and a fact that's costing to my company.

--
Paolo
Jul 28 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 28 July 2015 at 10:16:21 UTC, Paolo Invernizzi wrote:

 On Tuesday, 28 July 2015 at 08:54:34 UTC, Marc Schütz wrote:

 On Monday, 27 July 2015 at 22:52:11 UTC, deadalnix wrote:

 On Monday, 27 July 2015 at 09:01:33 UTC, Marc Schütz wrote:

 On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis 
 wrote:

 AliasTuple in particular has serious issues with it from 
 the perspective of teaching people what it is an how to use 
 it, because it has Tuple in its name,


 People keep claiming that, but have never posted any 
 evidence. We know that _TypeTuple_ had issues, but for all 
 we know, the problem was the "Type" part, not the "Tuple" 
 part.


 We have various reports that are consistent and confirm this 
 is an issue. At this point, this is a repeatable experiment, 
 not an anecdote anymore. Ignoring repeatable experiment puts 
 you in the tinfoil hat section of the population. You don't 
 want to be there.


 Well, your post kind of proves my point. You've stated this 
 several times, and you mentioned that people had problems, but 
 as evidence you only mentioned some obscure irc communications 
 that - for all I know - no one except you has ever seen. Now, 
 I could simply believe you there (after all you're a competent 
 person), but... that's not very scientific at all. If you say 
 that these are repeatable experiments, with a representative 
 sample of the programming community (or even just beginners), 
 with consistent outcomes, then I prefer to see evidence for 
 these claims before I believe them. I'm therefore not ignoring 
 experiments, I have doubts about the validity of said 
 experiments.


 That's nonsense.

 Being a company that regularly teaches D to newcomers, I can 
 confirm that in the real world it's a mess to teach TypeTuple.

 And IMHO that is the common experience of everyone that has to 
 deal regularly with someone that he's learning D in the 
 development department.

 Dicebot, feel free to correct me, but I think that this is also 
 what you are experiencing day by day in Berlin...

 So, literally, what we are talking about? That's a fact, not a 
 speculation, and a fact that's costing to my company.


Sorry, but this is unhelpful. All you are saying here is that 
"TypeTuple" is bad. Yes, but we already know that. Everyone 
agrees on that.

The real question is: _What exactly_ is the problem with 
TypeTuple? The "Type" part of the name? The "Tuple" part? The 
combination? Maybe it's not the name at all, but the concept, or 
only some part of its behaviour?

Nothing in your post gives us a clue which kind of name would be 
better. In particular, it doesn't show that `AliasSeq` is any 
better than `TypeTuple`. So we're changing it from a bad name to 
one that could be even worse, for all we know.

It seems you and deadalnix actually have useful evidence that can 
answer these questions, but neither of you posted them. Please do!
Jul 28 2015
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:

 Nothing in your post gives us a clue which kind of name would 
 be better. In particular, it doesn't show that `AliasSeq` is 
 any better than `TypeTuple`. So we're changing it from a bad 
 name to one that could be even worse, for all we know.


Neither do we know anything about the other alternatives.


 It seems you and deadalnix actually have useful evidence that 
 can answer these questions, but neither of you posted them. 
 Please do!


What sort of evidence are you hoping for?

  — David
Jul 28 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 28 July 2015 at 11:52:32 UTC, David Nadlinger wrote:

 What sort of evidence are you hoping for?


Consistency???
Jul 28 2015
prev sibling next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 28 July 2015 at 11:52:32 UTC, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:

 Nothing in your post gives us a clue which kind of name would 
 be better. In particular, it doesn't show that `AliasSeq` is 
 any better than `TypeTuple`. So we're changing it from a bad 
 name to one that could be even worse, for all we know.


 Neither do we know anything about the other alternatives.


 It seems you and deadalnix actually have useful evidence that 
 can answer these questions, but neither of you posted them. 
 Please do!


 What sort of evidence are you hoping for?

  — David


We know which is most popular :)

So far the only concrete "evidence" that any one has is the poll. 
Every thing else is just speculation and anecdotes. No one else 
has bothered to collect any other evidence.
Jul 28 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/28/2015 02:00 PM, Tofu Ninja wrote:

 On Tuesday, 28 July 2015 at 11:52:32 UTC, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:

 Nothing in your post gives us a clue which kind of name would be
 better. In particular, it doesn't show that `AliasSeq` is any better
 than `TypeTuple`. So we're changing it from a bad name to one that
 could be even worse, for all we know.


 Neither do we know anything about the other alternatives.


 It seems you and deadalnix actually have useful evidence that can
 answer these questions, but neither of you posted them. Please do!


 What sort of evidence are you hoping for?

  — David


 We know which is most popular :)

 So far the only concrete "evidence" that any one has is the poll. Every
 thing else is just speculation and anecdotes. No one else has bothered
 to collect any other evidence.


What the poll has shown is that no proposed name is significantly more 
popular than 3 on a scale from 1 to 5.
Jul 29 2015
prev sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 28 July 2015 at 11:52:32 UTC, David Nadlinger wrote:

 On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:

 Nothing in your post gives us a clue which kind of name would 
 be better. In particular, it doesn't show that `AliasSeq` is 
 any better than `TypeTuple`. So we're changing it from a bad 
 name to one that could be even worse, for all we know.


 Neither do we know anything about the other alternatives.


 It seems you and deadalnix actually have useful evidence that 
 can answer these questions, but neither of you posted them. 
 Please do!


 What sort of evidence are you hoping for?


E.g.
"Joe D. Veloper came on IRC last evening and asked whether D 
supports something like TypeTuple that can also contain strings."
=> He was evidently confused by the term "Type" in the name and 
didn't expect that he _can_ use TypeTuple for that purpose. This 
means the problem - at least in his case - was the "Type" part. 
He will profit if we rename it to CompileTimeTuple or something 
similar, but it will not help if we call it TypeSeq.

"X.Y.Z. didn't understand the difference between Tuple and 
TypeTuple".
=> Maybe the "Tuple" part of the name is the problem. We should 
consider a different name.

"N.N. asked whether he can append things to a TypeTuple in a for 
loop."
=> This shows a fundamental misunderstanding of the concept. No 
matter how we change the name, we probably can't help him avoid 
this misunderstanding.
Jul 28 2015
parent reply "Daniel N" <ufo orbiting.us> writes:
On Tuesday, 28 July 2015 at 12:10:54 UTC, Marc Schütz wrote:

 "X.Y.Z. didn't understand the difference between Tuple and 
 TypeTuple".
 => Maybe the "Tuple" part of the name is the problem. We should 
 consider a different name.


In which case it makes more sense to change std/typecons:Tuple, 
since it's the odd one out when comparing with .tupleof and 
TypeTuple.
Jul 28 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 28 July 2015 at 12:34:13 UTC, Daniel N wrote:

 On Tuesday, 28 July 2015 at 12:10:54 UTC, Marc Schütz wrote:

 "X.Y.Z. didn't understand the difference between Tuple and 
 TypeTuple".
 => Maybe the "Tuple" part of the name is the problem. We 
 should consider a different name.


 In which case it makes more sense to change std/typecons:Tuple, 
 since it's the odd one out when comparing with .tupleof and 
 TypeTuple.


Yes, tuples are supposed to be:
- immutable
- subject to structural typing only

So typecons.Tuple is not a tuple… Which probably just adds to the 
confusion...
Jul 28 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/28/2015 04:13 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Tuesday, 28 July 2015 at 12:34:13 UTC, Daniel N wrote:

 On Tuesday, 28 July 2015 at 12:10:54 UTC, Marc Schütz wrote:

 "X.Y.Z. didn't understand the difference between Tuple and TypeTuple".
 => Maybe the "Tuple" part of the name is the problem. We should
 consider a different name.


 In which case it makes more sense to change std/typecons:Tuple, since
 it's the odd one out when comparing with .tupleof and TypeTuple.


 Yes, tuples are supposed to be:
 - immutable


Not necessarily.
You can think about having e.g. a tuple of mutable lvalues, so this 
distinction is useless in the context of D.


 - subject to structural typing only

 So typecons.Tuple is not a tuple… Which probably just adds to the
 confusion...


Yup.
Jul 29 2015
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:

 Sorry, but this is unhelpful. All you are saying here is that 
 "TypeTuple" is bad. Yes, but we already know that. Everyone 
 agrees on that.

 The real question is: _What exactly_ is the problem with 
 TypeTuple? The "Type" part of the name? The "Tuple" part? The 
 combination? Maybe it's not the name at all, but the concept, 
 or only some part of its behaviour?

 Nothing in your post gives us a clue which kind of name would 
 be better. In particular, it doesn't show that `AliasSeq` is 
 any better than `TypeTuple`. So we're changing it from a bad 
 name to one that could be even worse, for all we know.

 It seems you and deadalnix actually have useful evidence that 
 can answer these questions, but neither of you posted them. 
 Please do!


Honestly when I first was learning D, the Type part of TypeTuple 
was the part messed me up. I had a rough idea what a tuple was 
though never need to use one, so the Tuple part seemed to make 
sense to me, but the Type part always confused the crap out of me.
Jul 28 2015
prev sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:

 On Tuesday, 28 July 2015 at 10:16:21 UTC, Paolo Invernizzi 
 wrote:

 [...]


 Sorry, but this is unhelpful. All you are saying here is that 
 "TypeTuple" is bad. Yes, but we already know that. Everyone 
 agrees on that.

 The real question is: _What exactly_ is the problem with 
 TypeTuple? The "Type" part of the name? The "Tuple" part? The 
 combination? Maybe it's not the name at all, but the concept, 
 or only some part of its behaviour?

 Nothing in your post gives us a clue which kind of name would 
 be better. In particular, it doesn't show that `AliasSeq` is 
 any better than `TypeTuple`. So we're changing it from a bad 
 name to one that could be even worse, for all we know.

 It seems you and deadalnix actually have useful evidence that 
 can answer these questions, but neither of you posted them. 
 Please do!


As already posted in the bike-shedding thread, I'm fine with 
'Aliases'.
Or AliasSeq.
Or everything that does not have the 'tuple' or 'type' part in it.
I'm so desperate I would be fine with 'Arguments'!

Please just proceed with something TOTALLY different for this 
concept

---
Paolo
Jul 28 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 28 July 2015 at 12:33:35 UTC, Paolo Invernizzi wrote:

 On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:

 On Tuesday, 28 July 2015 at 10:16:21 UTC, Paolo Invernizzi 
 wrote:

 [...]


 Sorry, but this is unhelpful. All you are saying here is that 
 "TypeTuple" is bad. Yes, but we already know that. Everyone 
 agrees on that.

 The real question is: _What exactly_ is the problem with 
 TypeTuple? The "Type" part of the name? The "Tuple" part? The 
 combination? Maybe it's not the name at all, but the concept, 
 or only some part of its behaviour?

 Nothing in your post gives us a clue which kind of name would 
 be better. In particular, it doesn't show that `AliasSeq` is 
 any better than `TypeTuple`. So we're changing it from a bad 
 name to one that could be even worse, for all we know.

 It seems you and deadalnix actually have useful evidence that 
 can answer these questions, but neither of you posted them. 
 Please do!


 As already posted in the bike-shedding thread, I'm fine with 
 'Aliases'.
 Or AliasSeq.
 Or everything that does not have the 'tuple' or 'type' part in 
 it.
 I'm so desperate I would be fine with 'Arguments'!

 Please just proceed with something TOTALLY different for this 
 concept


Please reread my post, and then look at your answer again. I 
asked for evidence, and you posted your opinion.
Jul 28 2015
parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Tuesday, 28 July 2015 at 13:26:48 UTC, Marc Schütz wrote:

 On Tuesday, 28 July 2015 at 12:33:35 UTC, Paolo Invernizzi 
 wrote:

 On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:

 On Tuesday, 28 July 2015 at 10:16:21 UTC, Paolo Invernizzi 
 wrote:

 [...]


 Sorry, but this is unhelpful. All you are saying here is that 
 "TypeTuple" is bad. Yes, but we already know that. Everyone 
 agrees on that.

 The real question is: _What exactly_ is the problem with 
 TypeTuple? The "Type" part of the name? The "Tuple" part? The 
 combination? Maybe it's not the name at all, but the concept, 
 or only some part of its behaviour?

 Nothing in your post gives us a clue which kind of name would 
 be better. In particular, it doesn't show that `AliasSeq` is 
 any better than `TypeTuple`. So we're changing it from a bad 
 name to one that could be even worse, for all we know.

 It seems you and deadalnix actually have useful evidence that 
 can answer these questions, but neither of you posted them. 
 Please do!


 As already posted in the bike-shedding thread, I'm fine with 
 'Aliases'.
 Or AliasSeq.
 Or everything that does not have the 'tuple' or 'type' part in 
 it.
 I'm so desperate I would be fine with 'Arguments'!

 Please just proceed with something TOTALLY different for this 
 concept


 Please reread my post, and then look at your answer again. I 
 asked for evidence, and you posted your opinion.


Again, that's not "my opinion", these are facts, collected 
everyday in my working room, and I'm just reporting them.

The problem lays in the "Tuple" word, and in the "Type" word, so 
just avoid them completely.

It is up to you, D developers, to take care of our experiences, 
as we must teach D, or just ignore them.

You are free to judge them as you want, but I don't have the 
burden to prove anything, as my company is a business user of D, 
not a contributor.

I just don't understand why, every single time, we business users 
report our experience, they are just labeled as 'opinions', or 
they are declassed to minor problems, as in the never ending 
'break-my-code' discussions.
---
Paolo
Jul 28 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 28 July 2015 at 14:00:29 UTC, Paolo Invernizzi wrote:

 On Tuesday, 28 July 2015 at 13:26:48 UTC, Marc Schütz wrote:

 On Tuesday, 28 July 2015 at 12:33:35 UTC, Paolo Invernizzi 
 wrote:

 On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:

 On Tuesday, 28 July 2015 at 10:16:21 UTC, Paolo Invernizzi 
 wrote:

 [...]


 Sorry, but this is unhelpful. All you are saying here is 
 that "TypeTuple" is bad. Yes, but we already know that. 
 Everyone agrees on that.

 The real question is: _What exactly_ is the problem with 
 TypeTuple? The "Type" part of the name? The "Tuple" part? 
 The combination? Maybe it's not the name at all, but the 
 concept, or only some part of its behaviour?

 Nothing in your post gives us a clue which kind of name 
 would be better. In particular, it doesn't show that 
 `AliasSeq` is any better than `TypeTuple`. So we're changing 
 it from a bad name to one that could be even worse, for all 
 we know.

 It seems you and deadalnix actually have useful evidence 
 that can answer these questions, but neither of you posted 
 them. Please do!


 As already posted in the bike-shedding thread, I'm fine with 
 'Aliases'.
 Or AliasSeq.
 Or everything that does not have the 'tuple' or 'type' part 
 in it.
 I'm so desperate I would be fine with 'Arguments'!

 Please just proceed with something TOTALLY different for this 
 concept


 Please reread my post, and then look at your answer again. I 
 asked for evidence, and you posted your opinion.


 Again, that's not "my opinion", these are facts, collected 
 everyday in my working room, and I'm just reporting them.


You wrote "I'm fine with ..." and "Please just proceed with 
something TOTALLY different", and not much else. How is this 
anything more than opinion? It is probably based on facts, but 
where is the evidence for these facts?


 The problem lays in the "Tuple" word, and in the "Type" word, 
 so just avoid them completely.


This is already a conclusion you drew from the experiences in 
your company. But we have no way of knowing how well these 
conclusions match reality. I don't understand why it's so 
difficult just to recount a few of your experiences. I already 
gave a few examples how this could look:

http://forum.dlang.org/post/ynqxgjekwcgaiywlnmrk forum.dlang.org

Then everyone can judge for themselves whether your conclusions 
are justified. Given that deadalnix declared this a "repeatable 
experiment", I don't think this is asking too much.

And really, I'm genuinely interested in that. I don't keep asking 
for it just to annoy everyone. And if you can't share that 
information because it involves business secrets, then please 
just say so.


 It is up to you, D developers, to take care of our experiences, 
 as we must teach D, or just ignore them.


We're trying, but you don't share the experiences. You just tell 
us that you want something changed. But that's like going to a 
doctor and asking him to operate on you, instead of telling him 
where you're hurting and giving him the information to decide 
whether you need surgery at all.
Jul 29 2015
parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Wednesday, 29 July 2015 at 11:16:29 UTC, Marc Schütz wrote:

 On Tuesday, 28 July 2015 at 14:00:29 UTC, Paolo Invernizzi 
 wrote:

 On Tuesday, 28 July 2015 at 13:26:48 UTC, Marc Schütz wrote:

 On Tuesday, 28 July 2015 at 12:33:35 UTC, Paolo Invernizzi 
 wrote:

 On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:

 On Tuesday, 28 July 2015 at 10:16:21 UTC, Paolo Invernizzi 
 wrote:

 [...]


 Sorry, but this is unhelpful. All you are saying here is 
 that "TypeTuple" is bad. Yes, but we already know that. 
 Everyone agrees on that.

 The real question is: _What exactly_ is the problem with 
 TypeTuple? The "Type" part of the name? The "Tuple" part? 
 The combination? Maybe it's not the name at all, but the 
 concept, or only some part of its behaviour?

 Nothing in your post gives us a clue which kind of name 
 would be better. In particular, it doesn't show that 
 `AliasSeq` is any better than `TypeTuple`. So we're 
 changing it from a bad name to one that could be even 
 worse, for all we know.

 It seems you and deadalnix actually have useful evidence 
 that can answer these questions, but neither of you posted 
 them. Please do!


 As already posted in the bike-shedding thread, I'm fine with 
 'Aliases'.
 Or AliasSeq.
 Or everything that does not have the 'tuple' or 'type' part 
 in it.
 I'm so desperate I would be fine with 'Arguments'!

 Please just proceed with something TOTALLY different for 
 this concept


 Please reread my post, and then look at your answer again. I 
 asked for evidence, and you posted your opinion.


 Again, that's not "my opinion", these are facts, collected 
 everyday in my working room, and I'm just reporting them.


 You wrote "I'm fine with ..." and "Please just proceed with 
 something TOTALLY different", and not much else. How is this 
 anything more than opinion? It is probably based on facts, but 
 where is the evidence for these facts?


For sure it's based on facts, but, again and again, I don't have 
the burden to prove anything.


 The problem lays in the "Tuple" word, and in the "Type" word, 
 so just avoid them completely.


 This is already a conclusion you drew from the experiences in 
 your company. But we have no way of knowing how well these 
 conclusions match reality. I don't understand why it's so 
 difficult just to recount a few of your experiences. I already 
 gave a few examples how this could look:

 http://forum.dlang.org/post/ynqxgjekwcgaiywlnmrk forum.dlang.org

 Then everyone can judge for themselves whether your conclusions 
 are justified. Given that deadalnix declared this a "repeatable 
 experiment", I don't think this is asking too much.

 And really, I'm genuinely interested in that. I don't keep 
 asking for it just to annoy everyone. And if you can't share 
 that information because it involves business secrets, then 
 please just say so.


Again, and again, you can try it yourself, it's a repeatable 
experiment, as deadalnix said: just try yourself, teach D, and 
take your conclusion.

I'm not a contributor, my day it's already made by 30hrs, I can't 
simply afford the effort.


 It is up to you, D developers, to take care of our 
 experiences, as we must teach D, or just ignore them.


 We're trying, but you don't share the experiences. You just 
 tell us that you want something changed. But that's like going 
 to a doctor and asking him to operate on you, instead of 
 telling him where you're hurting and giving him the information 
 to decide whether you need surgery at all.


I'm trying to understand why you are the doctor and I am the 
common man.

So, what kind of experience you have, more than me, in teaching D 
to newcomers, turning them in efficient programmers in short time?

I've done my diagnosis, that's my work: I'm a CTO, I earn over 
evaluations of technologies.

Feel free to doubt, and feel free to perform all the examinations 
you prefer, they are repeatable, and take your conclusion.
---
Paolo
Jul 29 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
So to summarize, you've done the experiments, but don't want to 
share the data. That's sad, but of course it's your right. Maybe 
someone else will want to contribute something...
Jul 29 2015
parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Wednesday, 29 July 2015 at 12:51:08 UTC, Marc Schütz wrote:

 So to summarize, you've done the experiments, but don't want to 
 share the data. That's sad, but of course it's your right. 
 Maybe someone else will want to contribute something...


A 35 hr day it's beyond my will: I'm sharing the conclusions, and 
they match the conclusions of some others, and we are telling you 
that, if you have time, you can repeat the experiment, you can 
judge yourself.

Maybe someone else will start to trust the experience of the 
commercial adopters and will start to change something...

--
Paolo
Jul 29 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 29 July 2015 at 12:40:57 UTC, Paolo Invernizzi 
wrote:

 So, what kind of experience you have, more than me, in teaching 
 D to newcomers, turning them in efficient programmers in short 
 time?


I have no experience in teaching D, but I have been teaching 
programming in the past, and I'd feel awkward explaining some of 
the terminology that D uses. Including "AliasSeq" and "Tuple".
Jul 29 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 28 July 2015 at 14:00:29 UTC, Paolo Invernizzi wrote:

 Again, that's not "my opinion", these are facts, collected 
 everyday in my working room, and I'm just reporting them.

 The problem lays in the "Tuple" word, and in the "Type" word, 
 so just avoid them completely.

 It is up to you, D developers, to take care of our experiences, 
 as we must teach D, or just ignore them.

 You are free to judge them as you want, but I don't have the 
 burden to prove anything, as my company is a business user of 
 D, not a contributor.

 I just don't understand why, every single time, we business 
 users report our experience, they are just labeled as 
 'opinions', or they are declassed to minor problems, as in the 
 never ending 'break-my-code' discussions.
 ---
 Paolo


Don't worry, they aren't just labeled as opinion. The problem 
encountered teaching type tuple, where both type and tuple 
confused the hell out of newcomers, it the very reason why this 
whole name change started.
Jul 29 2015
prev sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Monday, 27 July 2015 at 02:14:57 UTC, Jonathan M Davis wrote:

 Because the decision is not going to be made based on a 
 popularity contest, and many of the folks who have been 
 discussing this have not voted in that poll. Also, there is no 
 clear winner in the poll anyway. AliasTuple is slightly ahead, 
 but remember that _5_ was the top, not 3. So, the ones at the 
 "top" of the list are far from being universally liked.

 AliasTuple in particular has serious issues with it from the 
 perspective of teaching people what it is an how to use it, 
 because it has Tuple in its name, and the construct in question 
 is not actually a tuple (in addition to being easily confused 
 with std.typecons.Tuple). This has been shown time and time 
 again with TypeTuple.

 On technical merit, AliasSeq is one of the better choices; it 
 was what TypeTuple had been changed to prior to the recent, 
 large discussion on it; and none of the new suggestions are 
 better enough to win any kind of consensus. At this point, for 
 it to be changed, Walter and Andrei need to step in and choose 
 something else. Otherwise, it's just going to stay AliasSeq, 
 and it will be final, because we're not changing it again after 
 2.068 goes out. But thus far, they haven't changed it and have 
 let it stay as AliasSeq, and the window of time for them to 
 change it is shrinking fast. Regardless, even if the decision 
 were to be made based on the poll, it would be Walter and 
 Andrei making that decision, because it is abundantly clear 
 that the community is unable to come to a consensus on this.

 - Jonathan M Davis


Just food for thought, the difference between the rating of 
AliasTuple and AliasSeq is the same as the difference between 
AliasSeq and TypeTuple....
Jul 27 2015
prev sibling next sibling parent reply "Sean Campbell" <sycam.inc gmail.com> writes:
On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote:

 Martin has just merged the rename of `TypeTuple` to `AliasSeq` 
 into the stable branch, which will be released soon. If anyone 
 wants to change the name again, please open a PR immediately, 
 this is the last chance.


Personally I like Arity.

But if we are going with AliasSeq can we at least use the full 
word AliasSequence.

IMOA:
AliasSeq on it's own seems an obscure word to describe what it is
Jul 28 2015
next sibling parent "wobbles" <grogan.colin gmail.com> writes:
On Tuesday, 28 July 2015 at 07:23:07 UTC, Sean Campbell wrote:

 On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote:

 Martin has just merged the rename of `TypeTuple` to `AliasSeq` 
 into the stable branch, which will be released soon. If anyone 
 wants to change the name again, please open a PR immediately, 
 this is the last chance.


 Personally I like Arity.

 But if we are going with AliasSeq can we at least use the full 
 word AliasSequence.

 IMOA:
 AliasSeq on it's own seems an obscure word to describe what it 
 is


+1

I don't see the need to shorten it myself.
Jul 28 2015
prev sibling parent reply "Elvis Zhou" <elvis.x.zhou gmail.com> writes:
On Tuesday, 28 July 2015 at 07:23:07 UTC, Sean Campbell wrote:

 On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote:

 Martin has just merged the rename of `TypeTuple` to `AliasSeq` 
 into the stable branch, which will be released soon. If anyone 
 wants to change the name again, please open a PR immediately, 
 this is the last chance.


 Personally I like Arity.

 But if we are going with AliasSeq can we at least use the full 
 word AliasSequence.

 IMOA:
 AliasSeq on it's own seems an obscure word to describe what it 
 is


+10086

WTF does 'Seq' means?
AliasSequence is much better!
Jul 28 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 28 July 2015 at 11:23:07 UTC, Elvis Zhou wrote:

 WTF does 'Seq' means?
 AliasSequence is much better!


Seq is a function that maps natural numbers to values in the set 
X.

«A finite sequence is a finite indexed set of values of the same 
type, whose domain is a contiguous set of positive integers 
starting at 1.»

In Z-notation:

«seq X is the set of all finite sequences of values of X , that 
is, of finite functions from the set 1 . . n, for some n, to 
elements of X .»

«seq1 X is the set of all non-empty finite sequences of values of 
X .»

«iseq X is the set of injective finite sequences over X : these 
are precisely the
finite sequences over X which contain no repetitions.»
Jul 28 2015
next sibling parent reply "Elvis Zhou" <elvis.x.zhou gmail.com> writes:
On Tuesday, 28 July 2015 at 11:55:01 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 28 July 2015 at 11:23:07 UTC, Elvis Zhou wrote:

 WTF does 'Seq' means?
 AliasSequence is much better!


 Seq is a function that maps natural numbers to values in the 
 set X.

 «A finite sequence is a finite indexed set of values of the 
 same type, whose domain is a contiguous set of positive 
 integers starting at 1.»

 In Z-notation:

 «seq X is the set of all finite sequences of values of X , that 
 is, of finite functions from the set 1 . . n, for some n, to 
 elements of X .»

 «seq1 X is the set of all non-empty finite sequences of values 
 of X .»

 «iseq X is the set of injective finite sequences over X : these 
 are precisely the
 finite sequences over X which contain no repetitions.»


Good to know, thanks.
However, isn't AliasSequence more clear and does eliminate 
ambiguity?
Moreover, as a nonnative English speaker, I've no idea how to 
pronounce Seq :(
Jul 28 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 28 July 2015 at 14:05:47 UTC, Elvis Zhou wrote:

 Good to know, thanks.
 However, isn't AliasSequence more clear and does eliminate 
 ambiguity?
 Moreover, as a nonnative English speaker, I've no idea how to 
 pronounce Seq :(


Well, I don't think "seq" or "sequence" are descriptive for what 
TypeTuple does… Just pointing out common definitions for "Seq", 
"Seq1" etc since you asked.

"Aliases", "Parameters", "Pack" , "List" etc would be more 
descriptive given that the elements of TypeTuple is not drawn 
from a typed set, but basically anything that isn't a list…
Jul 29 2015
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/28/2015 01:54 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Tuesday, 28 July 2015 at 11:23:07 UTC, Elvis Zhou wrote:

 WTF does 'Seq' means?
 AliasSequence is much better!


 Seq is a function that maps natural numbers to values in the set X.

 «A finite sequence is a finite indexed set of values of the same type,
 whose domain is a contiguous set of positive integers starting at 1.»

 In Z-notation:

 «seq X is the set of all finite sequences of values of X , that is, of
 finite functions from the set 1 . . n, for some n, to elements of X .»

 «seq1 X is the set of all non-empty finite sequences of values of X .»

 «iseq X is the set of injective finite sequences over X : these are
 precisely the
 finite sequences over X which contain no repetitions.»


Hence AliasSeq: It is 'seq alias'.
It's like IntList which is 'list int'.

Also, this usage is quite common, but still, I was under the impression 
that you consider it important to provide sources. :-)
Jul 29 2015
next sibling parent reply "Ola Fosheim Gr" <ola.fosheim.grostad+dlang gmail.com> writes:
On Thursday, 30 July 2015 at 03:48:50 UTC, Timon Gehr wrote:

 Hence AliasSeq: It is 'seq alias'.
 It's like IntList which is 'list int'.

 Also, this usage is quite common, but still, I was under the 
 impression that you consider it important to provide sources. 
 :-)


"alias" is not a set of values if the same type...
Jul 29 2015
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/30/2015 05:59 AM, Ola Fosheim Gr wrote:

 On Thursday, 30 July 2015 at 03:48:50 UTC, Timon Gehr wrote:

 Hence AliasSeq: It is 'seq alias'.
 It's like IntList which is 'list int'.

 Also, this usage is quite common, but still, I was under the
 impression that you consider it important to provide sources. :-)


 "alias" is not a set of values if the same type...


D is a fancy macro system on top of an improved C-like language. It's 
the same type in the former system, but no such type exists in the 
latter system. D does not have a design that is as principled as that of 
the systems you draw inspiration from.
Jul 29 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 30 July 2015 at 04:20:41 UTC, Timon Gehr wrote:

 type exists in the latter system. D does not have a design that 
 is as principled as that of the systems you draw inspiration 
 from.


I'm not drawing inspiration from anywhere. I'm talking about how 
the term "sequence"/"seq" is commonly used both in CS literature 
and elsewhere: a list of related values.

synonyms: «succession, order, course, series, chain, 
concatenation, train, string, cycle, progression»

If you want do design a language that is pleasant to deal with 
you need to be consistent and principled both when it comes to 
naming and to semantics.

If "sequence" is to be understood as a compile time list of 
random shit with a flattening constructor and auto expansion, 
then you prevent sensible and consistent use of the term in other 
contexts.
Jul 30 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
If in doubt, just google "define:sequence" and you'll get these 
two meanings:

1. a particular order in which related things follow each other.

2. a set of related events, movements, or items that follow each 
other in a particular order.

Replace "related" with "type" and "things" with "value".
Jul 30 2015
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/30/2015 09:39 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 30 July 2015 at 04:20:41 UTC, Timon Gehr wrote:

 type exists in the latter system. D does not have a design that is as
 principled as that of the systems you draw inspiration from.


 ...


Don't garble quotes like that. Thanks.


 I'm not drawing inspiration from anywhere. I'm talking about how the
 term "sequence"/


You talked extensively about seq.


"seq" is commonly used both in CS literature and
 elsewhere: a list of related values.
 ...


That's basically what that comment said, modulo possibly a slight 
movement of goalposts from your side now.


 synonyms: «succession, order, course, series, chain, concatenation,
 train, string, cycle, progression»

 If you want do design a language that is pleasant to deal with you need
 to be consistent and principled both when it comes to naming and to
 semantics.
 ...


Well, D fails here.


 If "sequence" is to be understood as a compile time list of random shit
 with a flattening constructor


There's no flattening constructor.


 and auto expansion, then you prevent
 sensible and consistent use of the term in other contexts.


I have argued why it can be seen as somewhat sensible and consistent 
given the constraints, and you have ignored that argument.

Anyway, this is getting tiresome, because you keep changing the specific 
topic initiated in the subthreads if the original one is not defensible. 
E.g. here, I was replying to the specific comment that '"alias" is not a 
set of values if [sic] the same type...'.

I fully agree that "Seq" does not deal with auto-expansion.

Are you using a non-threaded interface by any chance?

Note that I don't have an agenda here. I'm not going to use any library 
primitive for this that uses more than 3 characters anyway and I am not 
teaching D to anyone.
Jul 30 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 30 July 2015 at 09:45:31 UTC, Timon Gehr wrote:

 On 07/30/2015 09:39 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 30 July 2015 at 04:20:41 UTC, Timon Gehr wrote:

 type exists in the latter system. D does not have a design 
 that is as
 principled as that of the systems you draw inspiration from.


 ...


 Don't garble quotes like that. Thanks.


No garbling. I quote as little as possible per Usenet convention.

[…on principled design and consistency…]


 Well, D fails here.


I think D is at a decent position, and I don't judge a language 
based on its libraries, so Phobos itself is inconsequential.  
When DMD shifts to D it might become an interesting starting 
point for experimentation as I think a compiler is a task for 
which the current D language is well suited.


 Note that I don't have an agenda here. I'm not going to use any 
 library primitive for this that uses more than 3 characters 
 anyway and I am not teaching D to anyone.


Ok, so let's drop it.  I am merely supporting the OP's viewpoint 
that "sequence" is the less suitable name…
Jul 30 2015
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/30/2015 05:48 AM, Timon Gehr wrote:

 Hence AliasSeq: It is 'seq alias'.


(Of course, auto-expansion is still odd.)
Jul 29 2015
prev sibling parent "Enamex" <enamex+d outlook.com> writes:
On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote:

 Martin has just merged the rename of `TypeTuple` to `AliasSeq` 
 into the stable branch, which will be released soon. If anyone 
 wants to change the name again, please open a PR immediately, 
 this is the last chance.


Slightly non-sequitur question: Does this whole thing mean that 
tuple literals are never going to be implemented? The DIP I found 
mentioned most often is from 2013...
Aug 02 2015