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

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.

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.

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.

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

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

On 07/30/2015 05:48 AM, Timon Gehr wrote:
>
> Hence AliasSeq: It is 'seq alias'.

(Of course, auto-expansion is still odd.)

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.

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.

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