On 8/21/13 12:01 PM, Brad Anderson wrote:
> On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger wrote:
>> Personally, I like using "Seq" as the name for the constructor
>> template, as do a few other of the GitHub/NG regulars, so maybe
>> "(parameter/variadic/…) sequence" would be an alternative worth
>> discussing?
>
> "Seq" is nice too because it has no baggage that comes with terms like
> "type", "tuple", or "template".  It's its own thing which hasn't been
> used to mean anything but what people are proposing (at least in the
> context of D).
>
> I think I actually like "Seq" better than "parameter/variadic sequence"
> for this reason.  Neologism is a perfectly valid option (isn't that
> right, trie?).

"Seq" has the problem that it's not an actual word or phrase and as such is difficult to talk about.

Andrei

Am 21.08.2013 20:36, schrieb Meta:
> On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu
> wrote:
>> We much more need to get "type" out of the name. Those aren't
>> types.
>
> I think this is part of the problem. Nobody can agree on what
> they should be called because it's so hard to classify them.
> They're not types, they're not values, they're this weird
> in-between thing that can be either one, or the other, or both.
> Therefore anything containing Type or Value in the name will not
> describe exactly what this thing is. Neither will Symbol, nor
> Expression, as it can contain both of those again, but not
> exclusively. We may as well call it by some name that is
> completely unrelated to what it can contain, as it can contain
> pretty much *everything*. How about KitchenSinkquence?
>

what about "alias list", "alias sequence" - seems to be more in that directory - but not 100%

On Wednesday, 21 August 2013 at 19:19:35 UTC, Andrei Alexandrescu wrote:
> On 8/21/13 12:01 PM, Brad Anderson wrote:
>> On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger wrote:
>>> Personally, I like using "Seq" as the name for the constructor
>>> template, as do a few other of the GitHub/NG regulars, so maybe
>>> "(parameter/variadic/…) sequence" would be an alternative worth
>>> discussing?
>>
>> "Seq" is nice too because it has no baggage that comes with terms like
>> "type", "tuple", or "template".  It's its own thing which hasn't been
>> used to mean anything but what people are proposing (at least in the
>> context of D).
>>
>> I think I actually like "Seq" better than "parameter/variadic sequence"
>> for this reason.  Neologism is a perfectly valid option (isn't that
>> right, trie?).
>
> "Seq" has the problem that it's not an actual word or phrase and as such is difficult to talk about.
>
> Andrei

Seeing as basically all the "talking" is actually typing, I don't really see how this is a problem.

On Wednesday, 21 August 2013 at 19:19:35 UTC, Andrei Alexandrescu wrote:
> On 8/21/13 12:01 PM, Brad Anderson wrote:
>> On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger wrote:
>>> Personally, I like using "Seq" as the name for the constructor
>>> template, as do a few other of the GitHub/NG regulars, so maybe
>>> "(parameter/variadic/…) sequence" would be an alternative worth
>>> discussing?
>>
>> "Seq" is nice too because it has no baggage that comes with terms like
>> "type", "tuple", or "template".  It's its own thing which hasn't been
>> used to mean anything but what people are proposing (at least in the
>> context of D).
>>
>> I think I actually like "Seq" better than "parameter/variadic sequence"
>> for this reason.  Neologism is a perfectly valid option (isn't that
>> right, trie?).
>
> "Seq" has the problem that it's not an actual word or phrase and as such is difficult to talk about.
>
> Andrei

Nobody seems to know how to say "trie" either but it's successful enough (look at this show of hands: http://www.youtube.com/watch?v=RlVpPstLPEc&feature=youtu.be&t=50m46s ).  I would just pronounce it like abbreviated "sequence" so IPA: sikw.  Anyway, I think an neologism is something to consider even if it isn't Seq.

On 2013-08-21 13:36, Meta wrote:
> On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu
> wrote:
>> We much more need to get "type" out of the name. Those aren't
>> types.
>
> I think this is part of the problem. Nobody can agree on what they
> should be called because it's so hard to classify them. They're not
> types, they're not values, they're this weird in-between thing that
> can be either one, or the other, or both. Therefore anything
> containing Type or Value in the name will not describe exactly what
> this thing is. Neither will Symbol, nor Expression, as it can contain
> both of those again, but not exclusively. We may as well call it by
> some name that is completely unrelated to what it can contain, as it
> can contain pretty much *everything*. How about KitchenSinkquence?

abstract tuples they are.

(we have to alias them to maintain their full function)

i don't mind them being called ...tuples, to me it looks and feels enough like a tuple to be called this way. (Type... is very confusing though).

concerning the other typecons.Tuple: i think of this being more an issue of insufficient/bad/confusing documentation.

/det

On 2013-08-21 21:48, captaindet wrote:

> abstract tuples they are.
>
> (we have to alias them to maintain their full function)
>
> i don't mind them being called ...tuples, to me it looks and feels
> enough like a tuple to be called this way. (Type... is very confusing
> though).
>
> concerning the other typecons.Tuple: i think of this being more an issue
> of insufficient/bad/confusing documentation.

We could call the built-in ones for "tuple" and typecons.Tuple for anonymous structs.

-- 
/Jacob Carlborg

On Thursday, August 22, 2013 09:21:05 Jacob Carlborg wrote:
> On 2013-08-21 21:48, captaindet wrote:
> > abstract tuples they are.
> > 
> > (we have to alias them to maintain their full function)
> > 
> > i don't mind them being called ...tuples, to me it looks and feels enough like a tuple to be called this way. (Type... is very confusing though).
> > 
> > concerning the other typecons.Tuple: i think of this being more an issue of insufficient/bad/confusing documentation.
> 
> We could call the built-in ones for "tuple" and typecons.Tuple for anonymous structs.

Considering that std.typecons.Tuple actually acts like a full-on tuple (it actually nests) and the built-in "tuple" doesn't, that would be an odd choice IMHO.

- Jonathan M Davis

On 2013-08-22 09:29, Jonathan M Davis wrote:

> Considering that std.typecons.Tuple actually acts like a full-on tuple (it
> actually nests) and the built-in "tuple" doesn't, that would be an odd choice
> IMHO.

I don't know the exact definition of "tuple" but what have nesting to do with it?

You can add names to the values using std.typecons.Tuple

alias Tuple!(int, "index", string, "value") Entry;
Entry e;
e.index = 4;
e.value = "Hello";
assert(e[1] == "Hello");
assert(e[0] == 4);

The above is basically exactly like an anonymous struct.

-- 
/Jacob Carlborg

On Wednesday, 21 August 2013 at 18:50:30 UTC, Ali Çehreli wrote:
> On 08/21/2013 11:40 AM, Atash wrote:
>
> > I don't see wording 'template pack' being problematic,
> assuming that there's
> > really no other way to use them but through templates (which
> AFAIK they
> > can't).
>
> TypeTuple can represent function parameter lists and array literal lists as well:

Under the assumption that the following was meant to be a counterpoint...

> import std.typetuple;
>
> void func(int, int)
> {}
>
> struct S(int a, int b)
> {}
>
> void main()
> {
>     alias tt = TypeTuple!(1, 2);

^ I'm not seeing the case given that TypeTuple is a template.

== What are we *actually* talking about?

I feel like this wasn't well defined, because now I'm feeling mildly confused with where the discussion has gone.

template Stuff(A...) { <stuff> } // a sequence/tuple of template parameters
alias TypeTuple!(<stuff>) B; // std.TypeTuple
TypeTuple!(<stuff>) C; // value tuple

I'm inclined to say that the debate is currently about A, but just to make sure... are we talking about A, B, C, or something else entirely?

== Annnddd more general stuff

Under the assumption that we are talking about A in the section above...

IMO, it's almost inevitable that whatever noun you guys decide on is going to be preceded by the word 'template' in conversation and in written communication if it isn't there already. While that sort of casual wording may be easily relegated to a synonym, it's still worth thinking about, methinks.

On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> There's an inordinate amount of confusion around what we currently call "type tuple" (embodied in std's TypeTuple). I've been furious immediately as I got word that Walter called it that way, and it hasn't failed to make everybody else feel the same over the years.
>
> So: shall we use "template pack" going forward exclusively whenever we refer to that stuff? That way we can unambiguously use "tuple" for "value tuples, i.e. like mini-structs that group values together".
>
> Destroy. I mean criticize.

After reading the thread I think it might help to try to define the important characteristics of them, and from that select the key

Using this as a reference to my understanding:
http://wiki.dlang.org/The_D_Programming_Language/Seq

In particular the section:
"Q: What's the deal with "auto-expansion"?"

I think .. "type tuples" are:
- Compile time
- A kind of (list, set, group, or collection) of (parameters/arguments, initialisers, parent classes)
- Flat i.e. "auto expanded" where used, not nested.
- An alias for the elements it contains
- A <thing> in which the ordering is important

I am leaning toward the fact that they are an "alias" being a key property, that and the fact that they are a "list" or "set" of things.  "Sequence" may be even better than list as it imples more heavily that the ordering is important.

So, I am personally leaning toward dennis's suggestion of "Alias Sequence".

But, I do worry a little about overloading the term "alias".  However.. TypeTuple is defined using "alias" so maybe they are the "same thing" after all.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/