On Tue, 25 Sep 2012 12:07:33 +0200
deadalnix <deadalnix@gmail.com> wrote:

> Le 25/09/2012 09:11, Jacob Carlborg a écrit :
> > On 2012-09-25 00:28, bearophile wrote:
> >
> >> (||)
> >> (|1|)
> >> (|1, 2|)
> >> (|1, 2, 3|)
> >
> > What about:
> >
> > ||
> > |1|
> > |1, 2|
> >
> 
> Yeah and why not þ1, 2þ or ŀ1, 2ŀ ?
> 
> maybe ↓1, 2↓ is better ?
> 
> or « 1, 2 » (this one at least is readable).

| is easily typed. þ, ŀ, ↓ and « I had to copy-paste.

On 9/25/12 4:14 PM, Jonathan M Davis wrote:
> On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:
>> But, the two are often confused, by the word "tuple". It has
>> introduced badly confusion in many discussions.
>> To make matters worse, it had often invoked incorrect suggestion that
>> merging the two into one.
>>
>> My suggestion is very simple.
>> 1. Change all words "built-in tuple" in the documentation to "built-in
>> sequence". Then, in the D language world, we can have clarify name for
>> the built-in one.
>> 2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
>>
>> template Seq(T...) { alias T Seq; } // identical with
>> std.typetuple.TypeTuple
>> template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
>> template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T
>> ExpSeq; }
>>
>> If you really want to a sequence with heterogeneous elements, use
>> Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
>
> In principle, renaming TypeTuple makes sense given it's bad name (though I
> really don't seem much point in separating expression tuples and type tuples),
> but it would break a _lot_ of code. And both Walter and Andrei are
> increasingly against making any breaking changes.
>
> - Jonathan M Davis

TypeTuple does a lot of harm. I'd be glad to rename it GenericTuple and leave TypeTuple as a slowly rotting alias.

Andrei

On 9/25/12 4:37 PM, deadalnix wrote:
> Le 25/09/2012 17:08, Andrei Alexandrescu a écrit :
>> On 9/25/12 10:05 AM, deadalnix wrote:
>>> OK, my bad. It means that tuple(...) behave differently than T...
>>> defined tuples.
>>>
>>> And both behave differently than Caml or Haskell's tuples.
>>>
>>> isn't the time for some unification ? Preferably on how tuples work in
>>> other languages, except if limitations can be shown and better proposal
>>> are made (and not include that in D2.xxx).
>>
>> I'm not sure actually. The way I look at it, built-in tuples are quite
>> low-level (types can't be spelled, automatic expansion and flattening,
>> undecided first-class semantics) and should seldom be dealt with
>> directly. The best use of built-in tuples is in the implementation of
>> truly well-behaved, composable tuples.
>>
>> Andrei
>
> We currently have 2 type of tuples, both unsatisfying it its own way
> (and I assume I can say it is confusing as I was confused before).
>
> If the new tuple stuff is implemented, D will ends up with 3 tuples
> systems, 2 of them unsatisfying and 1 of them satisfying (at least that
> is the goal).
>
> Still, language complexity would have increased in the process and have
> 3 time the same feature with different flavor isn't a good thing. Even
> if the tuple solution is a good one, the resulting situation isn't.

I agree. That's why I want to take the minimum amount of steps to make library tuples work. That minimum amount may be 1, i.e. just implement deconstruction.

Andrei

On Tuesday, September 25, 2012 22:39:37 ixid wrote:
> I meant to reply to your post rather than Jacob's.

It would help if you actually quoted at least _some_ of the post that you're replying to. I have _no_ idea what post you're replying to here. Many people view this newsgroup without any threading (meaning that your post is _really_ confusing), and even when you _have_ threading, it doesn't always work right (my mail client frequently puts posts in the wrong place in the hierarchy). So, please include at least some of the posts that you're replying to in your replies.

- Jonathan M Davis

On Tuesday, 25 September 2012 at 10:04:46 UTC, deadalnix wrote:
> Le 25/09/2012 03:19, ixid a écrit :
>> What would a special case where the first level of tuple (with higher
>> levels being tuples in tuples) didn't require parens break? This would
>> be a beautiful syntax:
>>
>> auto a = 1, 2; // A tuple of two ints
>>
>> int, string fun(double, double d) {
>> return cast(int) (d[0] * d[1]), "hello";
>> }
>>
>> auto a, b = 1, 2; // Two ints
>> auto a = fun(1.0, 1.0); // Tuple of 1 and "hello".
>> auto a, b = fun(1.0, 1.0); // An int and a string.
>>
>
> It can get pretty confusing with , separated declarations :
>
> int a, b = 3;
>
> or worse :
>
> int a, int b = foo();
>     -->
>         (int a, int b) = foo();
>       or
>         int a, (int b = foo());
>
> and it gets worse with int a, auto b = foo();
>
> But I do agree that this is really nice in many places.

Replying to the correct post this time, sorry for the repeated posting.

You've shown it's clearly incompatible with the current language
and would break lots of code. What would it break if assignment
required explicit tuple brackets?

(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be
filled in order by the multiple return values of foo()

int foo() {
    return 1;
}

(int a, b) = foo(); // Also valid and only sets 'a'


int, int foo() {
    return 1, 2;
}

int a = foo(); // Also valid and 'a' takes the first tuple value

(int a, auto b) = foo(); // Evaluated left to right so 'a' will
take the first argument of foo and b will auto to a type or tuple
of what remains. It will error if there is nothing remaining for
b. This would still allow the clean expression of stand-alone
tuples and function arguments and return values.

int, string a = 1, "hello";
int, string foo(double, double a) {
   return cast(int) (d[0] * d[1]), "hello";
}

Doesn't the needs of bracketing to determine order operation,
(stuff) more or less imply that implicit conversion between one
member tuples and the type of that tuple member is a requirement?
Or would the (stuff, ) syntax be better?

On 9/25/12 4:44 PM, Jonathan M Davis wrote:
> On Tuesday, September 25, 2012 22:39:37 ixid wrote:
>> I meant to reply to your post rather than Jacob's.
>
> It would help if you actually quoted at least _some_ of the post that you're
> replying to. I have _no_ idea what post you're replying to here. Many people
> view this newsgroup without any threading (meaning that your post is _really_
> confusing), and even when you _have_ threading, it doesn't always work right
> (my mail client frequently puts posts in the wrong place in the hierarchy).
> So, please include at least some of the posts that you're replying to in your
> replies.
>
> - Jonathan M Davis

Also, ixid, while you're at it, don't _forget_ to _underline_ all _words_ that are _important_.

_Andrei_

On 09/25/2012 11:01 PM, Andrei Alexandrescu wrote:
> On 9/25/12 4:14 PM, Jonathan M Davis wrote:
>> On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:
>>> But, the two are often confused, by the word "tuple". It has
>>> introduced badly confusion in many discussions.
>>> To make matters worse, it had often invoked incorrect suggestion that
>>> merging the two into one.
>>>
>>> My suggestion is very simple.
>>> 1. Change all words "built-in tuple" in the documentation to "built-in
>>> sequence". Then, in the D language world, we can have clarify name for
>>> the built-in one.
>>> 2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
>>>
>>> template Seq(T...) { alias T Seq; } // identical with
>>> std.typetuple.TypeTuple
>>> template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
>>> template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T
>>> ExpSeq; }
>>>
>>> If you really want to a sequence with heterogeneous elements, use
>>> Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
>>
>> In principle, renaming TypeTuple makes sense given it's bad name
>> (though I
>> really don't seem much point in separating expression tuples and type
>> tuples),
>> but it would break a _lot_ of code. And both Walter and Andrei are
>> increasingly against making any breaking changes.
>>
>> - Jonathan M Davis
>
> TypeTuple does a lot of harm. I'd be glad to rename it GenericTuple and
> leave TypeTuple as a slowly rotting alias.
>
> Andrei

I'd never use GenericTuple, because already after four usages it would
have been cheaper to just define Seq inline.

GenericTupleGenericTupleGenericTupleGenericTuple
template Seq(T...){ alias T Seq; }SeqSeqSeqSeq

What is the rationale for calling this construct a tuple anyway?
Programming language tuples usually impose more structure on the
data than just ordering.

On 09/25/2012 09:29 PM, kenji hara wrote:
> 2012/9/26 Jonathan M Davis <jmdavisProg@gmx.com>:
>> On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
>>> On 2012-09-25 16:38:31 +0000, "Jonathan M Davis" <jmdavisProg@gmx.com> said:
>>>> On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
>>>>> Although to make things less confusing, I think the built-in language
>>>>> tuple should give up its name. It could become a "sequence". Renaming
>>>>> the built-in one would certainly be less trouble, as code doesn't refer
>>>>> to it by its name, and you can pick a name that fits better with its
>>>>> auto-expanding behaviour.
>>>>
>>>> Not referred to by its name? It's refereed to as TypeTuple all over the
>>>> place. It's arguably a bad name, but it would break a _lot_ of code to
>>>> change it now.
>>> TypeTuple is only a construct allowing you to create a built-in
>>> language tuple, one that does not necessarily match the definition of a
>>> TypeTuple. The language spec defines a Tuples, TypeTuples, and
>>> ExpressionTuples with these words (ironically, using the word
>>> "sequence" twice):
>>>
>>> """
>>> If the last template parameter in the TemplateParameterList is declared
>>> as a TemplateTupleParameter, it is a match with any trailing template
>>> arguments. The sequence of arguments form a Tuple. A Tuple is not a
>>> type, an expression, or a symbol. It is a sequence of any mix of types,
>>> expressions or symbols.
>>>
>>> A Tuple whose elements consist entirely of types is called a TypeTuple.
>>> A Tuple whose elements consist entirely of expressions is called an
>>> ExpressionTuple.
>>> """
>>> Source: http://dlang.org/template.html
>>
>> I wasn't aware of that being in the language definition, but it doesn't change
>> the fact that they're used and referred to in code as TypeTuple, and renaming
>> that would break a lot of code. And it _is_ used for the built-in tuple type,
>> regardless of whether the spec considers the terms type tuple and expression
>> tuple to refer to distinct entities. Rename the stuff in the spec to whatever
>> you like, but the library uses the term TypeTuple, so it _is_ used in code.
>>
>> - Jonathan M Davis
>
> I like current design - open (built-in, automatically flattened, and
> *unpacked*) tuple, and closed (library, be structured, and *packed*)
> tuple.
>
> But, the two are often confused, by the word "tuple". It has
> introduced badly confusion in many discussions.
> To make matters worse, it had often invoked incorrect suggestion that
> merging the two into one.
>
> My suggestion is very simple.
> 1. Change all words "built-in tuple" in the documentation to "built-in
> sequence". Then, in the D language world, we can have clarify name for
> the built-in one.
> 2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
>
>      template Seq(T...) { alias T Seq; }    // identical with
> std.typetuple.TypeTuple

+1.

>      template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
>      template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T ExpSeq; }
>
>    If you really want to a sequence with heterogeneous elements, use
> Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
>
> Kenji Hara
>

I don't consider TypeSeq and ExpSeq crucial. They do not do more
checking than using the sequence in type or expression context triggers
automatically, but YMMV.

Le 25/09/2012 23:34, ixid a écrit :
> You've shown it's clearly incompatible with the current language
> and would break lots of code. What would it break if assignment
> required explicit tuple brackets?
>
> (int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be
> filled in order by the multiple return values of foo()
>
> int foo() {
> return 1;
> }
>
> (int a, b) = foo(); // Also valid and only sets 'a'
>
>
> int, int foo() {
> return 1, 2;
> }
>
> int a = foo(); // Also valid and 'a' takes the first tuple value
>
> (int a, auto b) = foo(); // Evaluated left to right so 'a' will
> take the first argument of foo and b will auto to a type or tuple
> of what remains. It will error if there is nothing remaining for
> b. This would still allow the clean expression of stand-alone
> tuples and function arguments and return values.
>

This does not exist according to current language specs, so it is up to us to decide if it works and how.

> int, string a = 1, "hello";
> int, string foo(double, double a) {
> return cast(int) (d[0] * d[1]), "hello";
> }
>

This is incompatible with current language specs (or will ends up with highly bizantine rules do define what to do, in a topic where it is already complex).

> Doesn't the needs of bracketing to determine order operation,
> (stuff) more or less imply that implicit conversion between one
> member tuples and the type of that tuple member is a requirement?
> Or would the (stuff, ) syntax be better?

I don't know.

Le 25/09/2012 22:55, Nick Sabalausky a écrit :
> On Tue, 25 Sep 2012 12:07:33 +0200
> deadalnix<deadalnix@gmail.com>  wrote:
>
>> Le 25/09/2012 09:11, Jacob Carlborg a écrit :
>>> On 2012-09-25 00:28, bearophile wrote:
>>>
>>>> (||)
>>>> (|1|)
>>>> (|1, 2|)
>>>> (|1, 2, 3|)
>>>
>>> What about:
>>>
>>> ||
>>> |1|
>>> |1, 2|
>>>
>>
>> Yeah and why not þ1, 2þ or ŀ1, 2ŀ ?
>>
>> maybe ↓1, 2↓ is better ?
>>
>> or « 1, 2 » (this one at least is readable).
>
> | is easily typed. þ, ŀ, ↓ and « I had to copy-paste.
>

My post was ironic. It isn't hard to come up with new characters but is it really useful ?