View mode: basic / threaded / horizontal-split · Log in · Help
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
> The built-in tuple is also quite useful when defining templates.
>
> In essence, we have two kinds of tuples: the built-in language 
> tuple is the "unpacked" tuple while Phobos hosts the "packed" 
> one. They each have their own use case and they can coexist 
> peacefully. But the language itself needs to standardize on one 
> or the other.

+1, and it should standardize on "packed" (non-expanded) tuples 
because "unpacked" ones have very unusual behavior, and because 
it's impractical to eliminate "packed" tuples but practical to 
eliminate "unpacked" ones. "unpacked" tuples should only exist as 
an intermediate result (the result of .expand).

> If the language made T… a packed tuple instead, then we could 
> use the packed tuple everywhere and unpack it where necessary, 
> and something like this could be used to make a packed tuple:
>
> 	T getThings(T...)(T.expand t)
> 	{
> 		return T(t);
> 	}
>
> 	T t1;
> 	T t2 = getThings!(T)(t1.expand);

"T.expand" naturally has the connotation "unpacked" to me, 
whereas what you really want to do is indicate that "t" is 
packed, right? Clearly, the syntax for a varargs template like 
this would have to change to indicate that T is non-expanded; 
unfortunately, I don't have a really compelling syntax to suggest.

P.S. If non-expanded tuples were the default, they should 
probably have a quicker syntax than "t.expand" to expand them. I 
suggest overloading unary * as in "*t"; this is known as the 
"explode" operator in boo.
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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
   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
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
>"T.expand" naturally has the connotation "unpacked" to me,

Isn't T.unpack clearer? Does that clash with a different usage 
for the term?
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12 3:39 PM, ixid wrote:
>> "T.expand" naturally has the connotation "unpacked" to me,
>
> Isn't T.unpack clearer? Does that clash with a different usage for the
> term?

Let's stay with .expand.

Andrei
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 17:51, 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.
>
> int, string a = 1, "hello";
> int, string foo(double, double a) {
> return cast(int) (d[0] * d[1]), "hello";
> }
>

WTF are thoses affirmations ?
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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.
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
I meant to reply to your post rather than Jacob's.
9 10 11 12 13 14 15 16 17
Top | Discussion index | About this forum | D home