On 2015-07-14 00:11, Jonathan M Davis wrote:

> Um. Seriously? I don't see how that would result in anything but
> ridicule. What's D do? It goes splat.

Variadic arguments are sometimes called "splat" in some languages, like Ruby. Or it's rather the operator, "*", that's called the splat operator.

-- 
/Jacob Carlborg

On Tuesday, 14 July 2015 at 11:14:58 UTC, Jacob Carlborg wrote:
> On 2015-07-14 00:11, Jonathan M Davis wrote:
>
>> Um. Seriously? I don't see how that would result in anything but
>> ridicule. What's D do? It goes splat.
>
> Variadic arguments are sometimes called "splat" in some languages, like Ruby. Or it's rather the operator, "*", that's called the splat operator.

I think this is what we want. Varargs in Ruby auto-expand, so they behave in a very similar manner to D's template parameters. AliasSplat or TemplateSplat both seem like good options.

On 7/13/15 7:38 PM, Tofu Ninja wrote:
> On Monday, 13 July 2015 at 23:01:35 UTC, Dmitry Olshansky wrote:
>> Popular != the right thing.
>> List in CS at large is generally speaking not indexable nor defines
>> such operations. So there may be a lot of people who don't care for
>> what a list is, but that doesn't make list a synonym for sequence.
>
> Who decreed lists can not be indexable, seriously this seems really odd
> to me.

It's just a matter of language ethos. Perl calls all arrays "lists", and if a new array-like feature comes about it that language, it would make sense to continue using that terminology. In D indexable and sliceable arrays are called "arrays" or "slices". That's a given. So adding something that is indexable and sliceable but is called a "list" is surprising. -- Andrei

On 7/13/15 8:10 PM, Mike wrote:
> On Monday, 13 July 2015 at 23:01:35 UTC, Dmitry Olshansky wrote:
>
>> List in CS at large is generally speaking not indexable nor defines
>> such operations. So there may be a lot of people who don't care for
>> what a list is, but that doesn't make list a synonym for sequence.
>
> "Sequence" implies that Item(n+1) is in some way dependent on Item(n),
> so "Sequence" is a misnomer in this situation, and "Seq" is a misnomer
> for the misnomer.

STL's "sequential containers" do not have serial dependence on items. There, "sequential" is meant as a converse of "associative".

> Furthermore, given that in a linked-list, one must
> first obtain Item(n) to get to Item(n+1), "linked-list" is ironically a
> misnomer for what is truly a sequence.  Hence the reason for the need to
> persistently qualify it with the "linked-" prefix.
>
> Even in the CS domain, the term "list" is rather general, as evident in
> its liberal usage in other programming languages and literature, and the
> need to persistently add qualifiers/quantifiers (e.g. "linked-") to
> disambiguate it.
> "List" is agnostic to order, indexing, linking, or any other specific
> qualification/quantification.  It is simply an enumeration of items
> (e.g. "grocery list", "todo list", "laundry list").  "List" describes,
> quite well, the subject under scrutiny, evident by the fact that
> "AliasList" was one of the first terms to come to mind.

I kinda agree in abstract especially because languages like Java and Perl use "lists" for arrays (see e.g. Java's ArrayList). Yet lists are often implicitly considered linked lists, ever since LISP. Also as I mentioned, each language bends terminology a bit one way or another. I don't think "list" is appropriate for describing a D abstraction that is indexable and sliceable. "Sequence" is better, and "Slice" or "Array" would be actually most recommended.


Andrei

On 7/13/15 8:12 PM, Mike wrote:
> On Monday, 13 July 2015 at 23:46:01 UTC, Dmitry Olshansky wrote:
>
>> That's all. No indexing folks.
>
>  From that very article:
>
> "Some languages may allow list types to be indexed or sliced like array
> types"

Yah, I think arguments based on the preciseness of definitions are difficult to carry. It's a fact of life that terms like "list", "sequence", "slice" and even "array" do carry ambiguity. -- Andrei

On 7/14/15 4:47 AM, Mike wrote:
> On Tuesday, 7 July 2015 at 21:15:40 UTC, Andrei Alexandrescu wrote:
>
>> What happened? Why are we replacing a crappy term with another crappy
>> term?
>
> And by request, "AliasTuple":
> https://github.com/D-Programming-Language/phobos/pull/3488

I'd be okay with this, prolly more than AliasSeq. -- Andrei

On Tuesday, 14 July 2015 at 14:06:04 UTC, Andrei Alexandrescu wrote:

> STL's "sequential containers" do not have serial dependence on items. There, "sequential" is meant as a converse of "associative".

Indeed, but the term "sequence" has existed long before the STL authors (mis)used it.  Actually, 3 of the 5 main "sequence containers" *are* sequences.  The other 2, vector (which is another name that has always bothered me) and array, are really best described as a random-access containers, but the authors probably didn't want to split hairs and make another category.

My interpretation of the word "list" both in and out of the CS domain jives with random access.  Consider a stream.  I define it to be truly a "sequence" of bytes, specifically because of its serial nature.  I would definitely *not* define it as a "list" of bytes.

When we say "these items must be accessed in sequence", we imply that Item(n+1) should be accessed only after Item(n) is accessed.

In our nomenclature, we should probably look more to the origin of terms, and their usage in other domains, than their (mis)use in the CS domain, especially C++.

Mike

On 7/14/15 5:13 PM, Mike wrote:
> On Tuesday, 14 July 2015 at 14:06:04 UTC, Andrei Alexandrescu wrote:
>
>> STL's "sequential containers" do not have serial dependence on items.
>> There, "sequential" is meant as a converse of "associative".
>
> Indeed, but the term "sequence" has existed long before the STL authors
> (mis)used it.  Actually, 3 of the 5 main "sequence containers" *are*
> sequences.  The other 2, vector (which is another name that has always
> bothered me) and array, are really best described as a random-access
> containers, but the authors probably didn't want to split hairs and make
> another category.

All this is more proof it comes down to a judgment call. Yeah, vector is probably a bit off,

> My interpretation of the word "list" both in and out of the CS domain
> jives with random access.

Well mine doesn't.

> Consider a stream.  I define it to be truly a
> "sequence" of bytes, specifically because of its serial nature.  I would
> definitely *not* define it as a "list" of bytes.
>
> When we say "these items must be accessed in sequence", we imply that
> Item(n+1) should be accessed only after Item(n) is accessed.

I'm not seeing much of that assertion at https://en.wikipedia.org/wiki/Sequence or really wherever https://www.google.com/search?q=sequence takes you.

> In our nomenclature, we should probably look more to the origin of
> terms, and their usage in other domains, than their (mis)use in the CS
> domain, especially C++.

I disagree. Context, affinity, and familiarity are important. It is no secret that the design of D has had C++ as a major influence, and the design of Phobos has had STL as a major influence. Defining the "right" terminology will take us from one imperfect nomenclature to another imperfect one, just less familiar one.

Let's drop it. Again: arguments base on purity and precision of widely used terms are futile.


Andrei

On 7/14/15 5:24 PM, Andrei Alexandrescu wrote:
> On 7/14/15 5:13 PM, Mike wrote:
>> On Tuesday, 14 July 2015 at 14:06:04 UTC, Andrei Alexandrescu wrote:
>>
>>> STL's "sequential containers" do not have serial dependence on items.
>>> There, "sequential" is meant as a converse of "associative".
>>
>> Indeed, but the term "sequence" has existed long before the STL authors
>> (mis)used it.  Actually, 3 of the 5 main "sequence containers" *are*
>> sequences.  The other 2, vector (which is another name that has always
>> bothered me) and array, are really best described as a random-access
>> containers, but the authors probably didn't want to split hairs and make
>> another category.
>
> All this is more proof it comes down to a judgment call. Yeah, vector is
> probably a bit off,

Sorry for the incomplete thought - easy to figure :o). -- Andrei

On Tuesday, 14 July 2015 at 21:25:50 UTC, Andrei Alexandrescu wrote:
> On 7/14/15 5:24 PM, Andrei Alexandrescu wrote:
>> All this is more proof it comes down to a judgment call. Yeah, vector is
>> probably a bit off,
>
> Sorry for the incomplete thought - easy to figure :o). -- Andrei

The one thing that's nice about the name vector as opposed to Array is that it's not going to be confused with the arrays in the language, which is way too easy to do with Array (especially in verbal conversation). Everyone who's used C++ much knows what you're talking about when you're talking about a vector as a container. But considering what a vector is outside of the STL, it's definitely an odd choice.

- Jonathan M Davis