DIP19: Remove comma operator from D and provision better syntactic support for tuples
I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 Unfortunately, I started much cockier than I ended. The analysis in there fails to construct a case even half strong that deprecating the comma operator could significantly help tuples. Well it essentially concludes that tuples are mostly fine as they are, and attempts to embellish them syntactically are marred with unexpected problems. Nevertheless, I sure have missed aspects all over, so contributions are appreciated. Thanks, Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu
wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps tuples. So I started
with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The
analysis in there fails to construct a case even half strong
that deprecating the comma operator could significantly help
tuples. Well it essentially concludes that tuples are mostly
fine as they are, and attempts to embellish them syntactically
are marred with unexpected problems. Nevertheless, I sure have
missed aspects all over, so contributions are appreciated.
Thanks,
Andrei
Yay! vote += infinity
Regarding specifics,
I'd argue that (int) should be a perfectly valid construct. I
don't see what's confusing about that. I also am opposed to the
idea to limit tuples to 2 or more elements. On the contrary, I
root for the clean semantics of having a proper unit type
represented as () instead of the horrible C semantics of the
'void' type. Just make void an alias to () for backwards
compatibility.
Also, why the need to special case the for loop? the increment
part can be a regular tuple since the for loop doesn't
for (int i, j; cond; i++, j++) {}
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12, Andrei Alexandrescu wrote: > I discussed this with Walter, and we concluded that we could deprecate > the comma operator if it helps tuples. So I started with this: > > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 About the (,) problem, what about using (void)? It's longer to type but it might be easier to humanly decode than trying to count lone commas. ((1, ), (,)) ((1, void), void, (void))
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 20:57:48 UTC, foobar wrote:
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei
Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps tuples. So I started
with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The
analysis in there fails to construct a case even half strong
that deprecating the comma operator could significantly help
tuples. Well it essentially concludes that tuples are mostly
fine as they are, and attempts to embellish them syntactically
are marred with unexpected problems. Nevertheless, I sure have
missed aspects all over, so contributions are appreciated.
Thanks,
Andrei
Yay! vote += infinity
Regarding specifics,
I'd argue that (int) should be a perfectly valid construct. I
don't see what's confusing about that. I also am opposed to the
idea to limit tuples to 2 or more elements. On the contrary, I
root for the clean semantics of having a proper unit type
represented as () instead of the horrible C semantics of the
'void' type. Just make void an alias to () for backwards
compatibility.
Also, why the need to special case the for loop? the increment
part can be a regular tuple since the for loop doesn't assign
the value of the expression.
for (int i, j; cond; i++, j++) {}
I'd suggest looking at functional implementations such as ML or
Haskel for more inspiration.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 21:00:39 UTC, foobar wrote:
On Sunday, 23 September 2012 at 20:57:48 UTC, foobar wrote:
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei
Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps tuples. So I started
with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The
analysis in there fails to construct a case even half strong
that deprecating the comma operator could significantly help
tuples. Well it essentially concludes that tuples are mostly
fine as they are, and attempts to embellish them
syntactically are marred with unexpected problems.
Nevertheless, I sure have missed aspects all over, so
contributions are appreciated.
Thanks,
Andrei
Yay! vote += infinity
Regarding specifics,
I'd argue that (int) should be a perfectly valid construct. I
don't see what's confusing about that. I also am opposed to the
idea to limit tuples to 2 or more elements. On the contrary, I
root for the clean semantics of having a proper unit type
represented as () instead of the horrible C semantics of the
'void' type. Just make void an alias to () for backwards
compatibility.
Also, why the need to special case the for loop? the increment
part can be a regular tuple since the for loop doesn't assign
the value of the expression.
for (int i, j; cond; i++, j++) {}
I'd suggest looking at functional implementations such as ML or
Haskel for more inspiration.
urg.. .Sorry for the double posting..
Also, I want to add that type declarations should be changed from
statements to expressions so that we could do:
auto tup = (3, "hello");
(int num, string s) = tup; // num == 3, s == "hello"
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 23/09/2012 22:40, Andrei Alexandrescu a écrit : I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 Unfortunately, I started much cockier than I ended. The analysis in there fails to construct a case even half strong that deprecating the comma operator could significantly help tuples. Well it essentially concludes that tuples are mostly fine as they are, and attempts to embellish them syntactically are marred with unexpected problems. Nevertheless, I sure have missed aspects all over, so contributions are appreciated. Thanks, Andrei This is a problem I think about for a while, and coding for SDC + studying how it is done in other languages has enlightened me on some points. I all for deprecating the comma operator. You have my full support on that point. As well as you have it for the « for » construct update. However, I'm not sure about everything you propose to implement tuples. I could discuss idea about 1 element tuples, or other tricky cases that deserve discussion (and I'm sure they will). But first, let me digress. D is already a really good language. One of its main flaw is the lack of 3rd party tools. The way new feature are implemented is a real problem for 3rd party tool developers. In other terms, the arm done by adding new feature is greater than any benefit new feature can bring us. Additionally, we have some open mess that need to be closed. Think about the -property madness, the holes in const/immutable transitivity, or other half buggy features. I consider that , operator should be deprecated then removed ASAP. It will limit the amount of code possibly broken in the future. But let's not introduce any new feature before at least introducing a versioning scheme that allow user to keep the version without the feature.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
I'm not for removing the comma operator, but it occurs to me we
could do it in the library:
auto commaOperatorReplacement(T...)(T t) {
return t[$-1];
}
There might be some edge case where that wouldn't work, but I
think it works in most cases.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/23/2012 10:58 PM, foobar wrote:
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The analysis in
there fails to construct a case even half strong that deprecating the
comma operator could significantly help tuples. Well it essentially
concludes that tuples are mostly fine as they are, and attempts to
embellish them syntactically are marred with unexpected problems.
Nevertheless, I sure have missed aspects all over, so contributions
are appreciated.
Thanks,
Andrei
Yay! vote += infinity
Regarding specifics,
I'd argue that (int) should be a perfectly valid construct.
If so, it should be the same as int.
I don't see what's confusing about that.
Those are currently both valid and give the same result:
int.max
(int).max
Anyway, the tuple type should resemble the tuple expression
syntactically.
I also am opposed to the idea to limit
tuples to 2 or more elements. On the contrary, I root for the clean
semantics of having a proper unit type represented as () instead of the
horrible C semantics of the 'void' type. Just make void an alias to ()
for backwards compatibility.
You mean, alias () to 'void' for backwards compatibility. How would
that give 'clean semantics'? It's just syntax. Or is it about void
supporting 'expand'? I don't think that makes sense.
void foo(){}
void main(){
void[] x = new int[42];
foo(x[0].expand); // whut?
}
Also, why the need to special case the for loop? the increment part can
be a regular tuple since the for loop doesn't assign the value of the
expression. for (int i, j; cond; i++, j++) {}
I assume Andrei intends the enclosing parens to be mandatory.
I'd suggest looking at functional implementations such as ML or Haskel[l] for
more inspiration.
They just do the two most obvious things. (well, Haskell has to answer
some questions related to the evaluation model that are irrelevant for
D.)
Neither one has a syntactic construct for building a single element tuple.
Also, I want to add that type declarations should be changed from statements to
expressions so that we could do:
auto tup = (3, "hello");
(int num, string s) = tup; // num == 3, s == "hello"
I'd support the addition of declaration expressions (mainly for using
them in conjuncts of if conditions), but this is not necessary to
enable what you show above.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Ok, here's a crazy idea: Do the reasons for explicit tuple-expansion necessarily apply to zero- and one-element tuples? I'm not so sure. Suppose we allowed implicit expansion on those... Now I know what you're thinking: That would be an ugly inconsistency between tuples of sizes >1 vs <=1. Well, *mechanically* yes, but consider this: *Logically* speaking, is there really any difference between a one-element tuple and an ordinary single value? I don't think so, and here's why: What is a tuple, logically speaking? Multiple values being handled as if they were a single value. So what's a one-element tuple? *One* value being handled as if it were one value - which is *is*. Similarly, a zero-element tuple is logically equivalent to void (or the one value a void can have: the value void, a concept which has been argued in the past that might be useful for D, particularly in metaprogramming). (I admit this is a little weaker than my argument for one-element tuples.) So perhaps zero- and one-element tuples should be implicitly convertible back and forth with void and ordinary non-tuple values, respectively (polysemous values?), because that's what they essentially are. That means (at least I think it means) that things like () or (1) or ((1)) require no way to disambiguate between tuple and expression, because either way they're the same thing (or at least freely convertible).
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 23/09/2012 23:52, Nick Sabalausky a écrit : Ok, here's a crazy idea: Do the reasons for explicit tuple-expansion necessarily apply to zero- and one-element tuples? I'm not so sure. Suppose we allowed implicit expansion on those... Now I know what you're thinking: That would be an ugly inconsistency between tuples of sizes>1 vs<=1. Well, *mechanically* yes, but consider this: *Logically* speaking, is there really any difference between a one-element tuple and an ordinary single value? I don't think so, and here's why: What is a tuple, logically speaking? Multiple values being handled as if they were a single value. So what's a one-element tuple? *One* value being handled as if it were one value - which is *is*. Similarly, a zero-element tuple is logically equivalent to void (or the one value a void can have: the value void, a concept which has been argued in the past that might be useful for D, particularly in metaprogramming). (I admit this is a little weaker than my argument for one-element tuples.) So perhaps zero- and one-element tuples should be implicitly convertible back and forth with void and ordinary non-tuple values, respectively (polysemous values?), because that's what they essentially are. My reflection on the subject for the past month lead me to the same conclusion. That means (at least I think it means) that things like () or (1) or ((1)) require no way to disambiguate between tuple and expression, because either way they're the same thing (or at least freely convertible). Exactly.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
This is a complex topic, and in this post I am not able to
discuss everything that needs to be discussed. So I will discuss
only part of the story.
First: tuples are important enough. I think they should be
built-in in a modern language, but maybe having them as
half-built-in will be enough in D. Currently in D we have
(deprecated) built-in complex numbers that I use only once in a
while, and half-usable library defined tuples that I use all the
time.
Second: removing comma operator from D has some advantages
unrelated to tuple syntax. Even disallowing bad looking C-like
code that uses commas is an improvement by itself (but maybe it's
not a big enough improvement...).
Third: replacing the packing syntax tuple(x,y) with (x,y) is nice
and maybe even expected in a partially functional language as D,
but that's _not_ going to improve D usability a lot. What I am
asking for is different: I'd like D tuples to support handy
unpacking syntax:
1) In function signatures;
2) In foreach;
3) At assignment points;
4) In switch cases.
Note: in the examples below I have used the tuple(x,y) syntax for
simplicity, feel free to replace it with a shorter (x,y) syntax
if you want.
---
1) This tuple unpacking use case is important, and it's not what
you argue against in the DIP:
int f(tuple(int x, int y)) { return x + y; }
auto pairs = zip([10, 20], [2, 3]);
map!f(pairs)
This is different from what you are arguing against because this
"f" is not accepting two normal ints, it accepts a tuple made of
two ints, and names them "x" and "y" on the fly.
---
2)
auto pairs = zip([10, 20], [2, 3]).array();
foreach (i, tuple(x, y); pairs) {}
---
3) This is probably the most common use case:
auto foo() { return tuple(10, 20); }
auto tuple(x, y) = foo(); // bad syntax
auto (x, y) = foo(); // better syntax
void main() {
auto a = tuple(1, 2);
auto tuple(x1, x2) = a; // bad syntax
auto (y1, y2) = a; // better syntax
}
---
4) This looks simple, but allows things like using BigInt in
switch cases, implementing a very simple but quite handy
pattern-matching, etc:
auto v = tuple(10, 20);
final switch (v) {
case tuple(5, y): { x in scope... } break; // y is not a
global
case tuple(x, y): { ... } break; // this covers all cases
}
---
There are other usage patterns that are handy, but in my opinion
the four I have shown here are the most commonly useful ones. See
also Bugzilla issues 6365 and 6367, they shows some other cases
and ideas and problems.
---
Tuple singletons: using (1,) as in Python is acceptable. using
(1) is not acceptable in my opinion, too much dangerous. tuple(1)
is also acceptable, it's longer, but it's not commonly used, so
it's OK.
Empty tuples: the (,) syntax proposed in the DIP is not nice, it
seems to have one invisible item, but maybe it's acceptable.
tuple() is also acceptable, it's longer, but it's not commonly
used, so it's OK.
In the end tuples with 0 and 1 items are sometimes useful, but
they are not nearly as useful as supporting well tuples with 2 or
more items. Scala language agrees with this.
---
Tuple slicing: it's not a fundamental operation, but it's nice to
try to make it work correctly :-) I think not even Haskell does
this well.
---
Summary:
- I think (1,2) is nicer and better than tuple(1,2), and I'd like
to have such syntax, but it's not a large improvement and it's
not what I am asking for now (less priority).
- Supporting tuples with 0 and 1 items is sometimes handy but I
think it's not essential.
- On the other hand syntax to unpack/destructure tuples in many
situations is important for allowing a proper and handy use of
tuples in D.
Bye,
bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 22:29:31 UTC, jerro wrote:
On Sunday, 23 September 2012 at 21:37:06 UTC, Adam D. Ruppe
wrote:
I'm not for removing the comma operator, but it occurs to me
we could do it in the library:
auto commaOperatorReplacement(T...)(T t) {
return t[$-1];
}
There might be some edge case where that wouldn't work, but I
think it works in most cases.
If D is like C in this regard, then the function above cannot
replace comma operator, because the order of evaluation is
defined for comma operator, but not for function parameters.
You could use something like that, though:
Sorry about the "You could use something like that, though" part.
I realized "something like that" wouldn't work either, but forgot
to delete that text.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 21:37:06 UTC, Adam D. Ruppe wrote:
I'm not for removing the comma operator, but it occurs to me we
could do it in the library:
auto commaOperatorReplacement(T...)(T t) {
return t[$-1];
}
There might be some edge case where that wouldn't work, but I
think it works in most cases.
If D is like C in this regard, then the function above cannot
replace comma operator, because the order of evaluation is
defined for comma operator, but not for function parameters. You
could use something like that, though:
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, September 24, 2012 00:30:27 jerro wrote: > If D is like C in this regard, then the function above cannot > replace comma operator, because the order of evaluation is > defined for comma operator, but not for function parameters. I believe that it's currently undefined for D, but Walter wants to define it so that it's left-to-right in an effort to eliminate bugs resulting from the varying order of function argument evaluation. He just hasn't gotten around to doing it yet. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/23/2012 10:40 PM, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The analysis in
there fails to construct a case even half strong that deprecating the
comma operator could significantly help tuples.
That is because it does not base the discussion on the right
limitations of built-in tuples:
auto (a,b) = (1,"3");
(auto a, string b) = (1, "3");
BTW: the following works
Tuple!(int, string) t2 = t1[0 .. 2];
because of this:
=> (alias this)
Tuple!(int, string) t2; t2._fields = t1[0 .. 2];
=> (tuple assignment)
Tuple!(int, string) t2; t2._fields[0]=t1[0]; t2._fields[1]=t1[1];
Well it essentially
concludes that tuples are mostly fine as they are, and attempts to
embellish them syntactically are marred with unexpected problems.
Nevertheless, I sure have missed aspects all over, so contributions are
appreciated.
- We already use the name 'tuple'. I'd suggest renaming that to
'sequence' or similar. template Seq(T...){ alias T Seq; }
- The empty tuple can well be (), just like 'Seq!()' works without
issues (it is an expression that is also a type). What is wrong with
it?
- How do we expand a sequence into a tuple?
=> (Seq!(1,2,3),)
- What is the calling convention used for passing built-in tuples to
and from functions?
- As tuples are built-in, expansion can be shorter than '.expand'.
foo(1, tup..., 3); ?
- Template tuple parameters? This would work, but...
template Tuple((T...,)){ alias (T,) Tuple; }
void bar(T,(U...,),V...)(T delegate(U) dg, V args){ ... }
void foo(T,(U...,),(V...,))(T delegate(U) dg, V args){
bar!(T,Tuple!U,V)(dg, args);
} // U and V can be passed separately
- Named tuple fields?
(int x, int y) tuple = (1,2);
swap(tuple.x, tuple.y);
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 5:57 PM, deadalnix wrote: Le 23/09/2012 23:52, Nick Sabalausky a écrit : Ok, here's a crazy idea: Do the reasons for explicit tuple-expansion necessarily apply to zero- and one-element tuples? I'm not so sure. Suppose we allowed implicit expansion on those... Now I know what you're thinking: That would be an ugly inconsistency between tuples of sizes>1 vs<=1. Well, *mechanically* yes, but consider this: *Logically* speaking, is there really any difference between a one-element tuple and an ordinary single value? I don't think so, and here's why: What is a tuple, logically speaking? Multiple values being handled as if they were a single value. So what's a one-element tuple? *One* value being handled as if it were one value - which is *is*. Similarly, a zero-element tuple is logically equivalent to void (or the one value a void can have: the value void, a concept which has been argued in the past that might be useful for D, particularly in metaprogramming). (I admit this is a little weaker than my argument for one-element tuples.) So perhaps zero- and one-element tuples should be implicitly convertible back and forth with void and ordinary non-tuple values, respectively (polysemous values?), because that's what they essentially are. My reflection on the subject for the past month lead me to the same conclusion. This notion a lot of trouble with it; I think it's safe to abandon it entirely. Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. Also, having no integrated notion of a zero-element tuple would again mess with the algebra as much as the absence of 0 would hurt numbers. It's just troublesome. I appreciate the attraction of this idea, but again I think it's safe to just not even discuss it. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 12:11 AM, bearophile wrote:
...
Second: removing comma operator from D has some advantages unrelated to
tuple syntax. Even disallowing bad looking C-like code that uses commas
is an improvement by itself (but maybe it's not a big enough
improvement...).
I would think that it isn't an improvement at all. Disallowing some
construct always will also disallow 'bad looking' code that uses it.
...
4) This looks simple, but allows things like using BigInt in switch
cases, implementing a very simple but quite handy pattern-matching, etc:
auto v = tuple(10, 20);
final switch (v) {
case tuple(5, y): { x in scope... } break; // y is not a global
case tuple(x, y): { ... } break; // this covers all cases
}
...
cases already introduce their own scopes in D, but switch cannot be
extended well to serve such use cases.
I agree with all the other points.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 12:40 AM, Jonathan M Davis wrote: On Monday, September 24, 2012 00:30:27 jerro wrote: If D is like C in this regard, then the function above cannot replace comma operator, because the order of evaluation is defined for comma operator, but not for function parameters. I believe that it's currently undefined for D, but Walter wants to define it so that it's left-to-right in an effort to eliminate bugs resulting from the varying order of function argument evaluation. He just hasn't gotten around to doing it yet. - Jonathan M Davis I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 6:42 PM, Timon Gehr wrote:
That is because it does not base the discussion on the right
limitations of built-in tuples:
auto (a,b) = (1,"3");
(auto a, string b) = (1, "3");
I meant to mention that but forgot. The interesting thing about this is
that, if we decide it's the main issue with today's tuples, we pull
Kenji's patch and close the case.
BTW: the following works
Tuple!(int, string) t2 = t1[0 .. 2];
because of this:
=> (alias this)
Tuple!(int, string) t2; t2._fields = t1[0 .. 2];
=> (tuple assignment)
Tuple!(int, string) t2; t2._fields[0]=t1[0]; t2._fields[1]=t1[1];
Yah, I thought the writeup clarified that.
- We already use the name 'tuple'. I'd suggest renaming that to
'sequence' or similar. template Seq(T...){ alias T Seq; }
Then what are the "old" tuples?
- The empty tuple can well be (), just like 'Seq!()' works without
issues (it is an expression that is also a type). What is wrong with
it?
There's already intensive use of parens in D. I predict there's going to
be big trouble with "()" even assuming it's not technical ambiguous, for
example a lambda that returns an empty tuple would be "()() {...}" and
all that jazz.
- How do we expand a sequence into a tuple?
=> (Seq!(1,2,3),)
I think we're discussing different things - the above seems to deal with
expression/alias tuples. DIP19 discusses strictly runtime value tuples.
- What is the calling convention used for passing built-in tuples to
and from functions?
I don't know. The current approach with .expand is nothing special - as
if the programmer wrote the expansion by hand.
- As tuples are built-in, expansion can be shorter than '.expand'.
foo(1, tup..., 3); ?
I find that sugar gratuitous.
- Template tuple parameters? This would work, but...
template Tuple((T...,)){ alias (T,) Tuple; }
void bar(T,(U...,),V...)(T delegate(U) dg, V args){ ... }
void foo(T,(U...,),(V...,))(T delegate(U) dg, V args){
bar!(T,Tuple!U,V)(dg, args);
} // U and V can be passed separately
- Named tuple fields?
(int x, int y) tuple = (1,2);
swap(tuple.x, tuple.y);
I kinda got lost around all that.
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 00:48, Andrei Alexandrescu a écrit : This notion a lot of trouble with it; I think it's safe to abandon it entirely. Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. This is a very weak point. In most cases, divide an conquer with tuple don't even make sense. Also, having no integrated notion of a zero-element tuple would again mess with the algebra as much as the absence of 0 would hurt numbers. It's just troublesome. I appreciate the attraction of this idea, but again I think it's safe to just not even discuss it. I'm not sure I want to answer that, so I wont.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 12:57 AM, Andrei Alexandrescu wrote:
On 9/23/12 6:42 PM, Timon Gehr wrote:
That is because it does not base the discussion on the right
limitations of built-in tuples:
Actually that is mostly unrelated to the comma operator. Apologies.
auto (a,b) = (1,"3");
(auto a, string b) = (1, "3");
I meant to mention that but forgot. The interesting thing about this is
that, if we decide it's the main issue with today's tuples, we pull
Kenji's patch and close the case.
Imho, it certainly is the main issue.
...
- We already use the name 'tuple'. I'd suggest renaming that to
'sequence' or similar. template Seq(T...){ alias T Seq; }
Then what are the "old" tuples?
Instances of TypeTuples, eg:
template Seq(T...){ alias T Seq; }
Seq!(int, double) foo(){ }
=> "Error: functions cannot return a tuple"
- The empty tuple can well be (), just like 'Seq!()' works without
issues (it is an expression that is also a type). What is wrong with
it?
There's already intensive use of parens in D. I predict there's going to
be big trouble with "()" even assuming it's not technical ambiguous,
Well, (,) cannot help with that.
for
example a lambda that returns an empty tuple would be "()() {...}" and
all that jazz.
Well, it would be ()=>() or delegate()()=>(), but is it even reasonable
to use the second form?
- How do we expand a sequence into a tuple?
=> (Seq!(1,2,3),)
I think we're discussing different things - the above seems to deal with
expression/alias tuples. DIP19 discusses strictly runtime value tuples.
I am discussing the interplay of the two features. Sequences are
auto-expanded in all contexts where it makes sense (except if they
happen to be the second argument to a comma expression, then they are
not, but I assume that is a bug.)
I expect the following to be equivalent:
(Seq!(1,2,3),)
and
(1,2,3)
- What is the calling convention used for passing built-in tuples to
and from functions?
I don't know. The current approach with .expand is nothing special - as
if the programmer wrote the expansion by hand.
Not sure we are on the same page. I meant the calling convention at the
ABI level.
- As tuples are built-in, expansion can be shorter than '.expand'.
foo(1, tup..., 3); ?
I find that sugar gratuitous.
You find built-in tuples gratuitous in general. :o)
Anyway, it certainly is not necessary.
- Template tuple parameters? This would work, but...
template Tuple((T...,)){ alias (T,) Tuple; }
void bar(T,(U...,),V...)(T delegate(U) dg, V args){ ... }
void foo(T,(U...,),(V...,))(T delegate(U) dg, V args){
bar!(T,Tuple!U,V)(dg, args);
} // U and V can be passed separately
- Named tuple fields?
(int x, int y) tuple = (1,2);
swap(tuple.x, tuple.y);
I kinda got lost around all that.
I assume named tuple fields are not a problem?
Other than that, I raised the issue of how to match and destructure
tuple types in template parameter lists. And came up with the following
proposal, which I do not like.
template Foo((U...,)){ alias (U,) Foo; }
void main(){
(int, double) x;
Foo!(typeof(x)) y;
static assert(is(typeof(x)==typeof(y)));
}
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 01:08 AM, deadalnix wrote: Le 24/09/2012 00:48, Andrei Alexandrescu a écrit : This notion a lot of trouble with it; I think it's safe to abandon it entirely. Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. This is a very weak point. In most cases, divide an conquer with tuple don't even make sense. Also, having no integrated notion of a zero-element tuple would again mess with the algebra as much as the absence of 0 would hurt numbers. It's just troublesome. I appreciate the attraction of this idea, but again I think it's safe to just not even discuss it. I'm not sure I want to answer that, so I wont. I agree with Andrei. Single element tuples need to support the same operations as tuples of other arities do.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Andrei Alexandrescu: The interesting thing about this is that, if we decide it's the main issue with today's tuples, we pull Kenji's patch and close the case. As I have tried to explain in my precedent post, Kenji's patch covers about 1/4 of the most important use cases. Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Timon Gehr: cases already introduce their own scopes in D, Thank you, I didn't remember this. but switch cannot be extended well to serve such use cases. Please explain, as I am not able to see the problems. I have discussed that topic a little here: http://d.puremagic.com/issues/show_bug.cgi?id=596 Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 01:36 AM, bearophile wrote: Timon Gehr: cases already introduce their own scopes in D, Thank you, I didn't remember this. but switch cannot be extended well to serve such use cases. Please explain, as I am not able to see the problems. Switch is syntax sugar for jump tables. An adequate pattern matching construct would not require explicit control flow statements, and it would be an expression of arbitrary type. I have discussed that topic a little here: http://d.puremagic.com/issues/show_bug.cgi?id=596 Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Timon Gehr: Switch is syntax sugar for jump tables. An adequate pattern matching construct would not require explicit control flow statements, and it would be an expression of arbitrary type. Introducing a good pattern matching syntax in D requires the introduction of a good amount of complexity. This idea was discussed few times in past. D switches also work on strings, wstrings, dstrings, so the idea of extending them to work on small array is not too much different. I think that switching on structs, and tuples with auto-assignment of variables for tuple fields, is enough to extend the usefulness of D switches significantly, while it introduces no new keywords, and not a lot of complexity for both the compiler and the programmer that has to learn D language. Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 01:28, Timon Gehr a écrit : I agree with Andrei. Single element tuples need to support the same operations as tuples of other arities do. Obviously it should. The whole point is that you can implicitly cast a 1 element tuple into the element and vice versa. like : (int) a = (3); // a is a tuple of 1 element. int b = a; // Implicit tuple unpack. a = b; // Implicit tuple packing.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 01:23, Timon Gehr a écrit :
I assume named tuple fields are not a problem?
I'm not sure it is really usefull.
Other than that, I raised the issue of how to match and destructure
tuple types in template parameter lists. And came up with the following
proposal, which I do not like.
template Foo((U...,)){ alias (U,) Foo; }
void main(){
(int, double) x;
Foo!(typeof(x)) y;
static assert(is(typeof(x)==typeof(y)));
}
The template syntax seems weird. Why do you want Foo((U...,)) when
Foo(U) could do it ?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 01:34, bearophile a écrit : Andrei Alexandrescu: The interesting thing about this is that, if we decide it's the main issue with today's tuples, we pull Kenji's patch and close the case. As I have tried to explain in my precedent post, Kenji's patch covers about 1/4 of the most important use cases. It would be great if we stopped to base design reflection on actual implementations we have somewhere.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 02:00 AM, deadalnix wrote: Le 24/09/2012 01:28, Timon Gehr a écrit : I agree with Andrei. Single element tuples need to support the same operations as tuples of other arities do. Obviously it should. The whole point is that you can implicitly cast a 1 element tuple into the element and vice versa. like : (int) a = (3); // a is a tuple of 1 element. int b = a; // Implicit tuple unpack. a = b; // Implicit tuple packing. Well, I do not want parentheses to randomly hide members. (a ~ b).length
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 02:21, Timon Gehr a écrit : On 09/24/2012 02:00 AM, deadalnix wrote: Le 24/09/2012 01:28, Timon Gehr a écrit : I agree with Andrei. Single element tuples need to support the same operations as tuples of other arities do. Obviously it should. The whole point is that you can implicitly cast a 1 element tuple into the element and vice versa. like : (int) a = (3); // a is a tuple of 1 element. int b = a; // Implicit tuple unpack. a = b; // Implicit tuple packing. Well, I do not want parentheses to randomly hide members. (a ~ b).length Then it easy to add a comma to create a one element tuple. IE: (a ~ b).length == a.length + b.length (a ~ b,).length == 1
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 02:28 AM, deadalnix wrote: Le 24/09/2012 02:21, Timon Gehr a écrit : On 09/24/2012 02:00 AM, deadalnix wrote: Le 24/09/2012 01:28, Timon Gehr a écrit : I agree with Andrei. Single element tuples need to support the same operations as tuples of other arities do. Obviously it should. The whole point is that you can implicitly cast a 1 element tuple into the element and vice versa. like : (int) a = (3); // a is a tuple of 1 element. int b = a; // Implicit tuple unpack. a = b; // Implicit tuple packing. Well, I do not want parentheses to randomly hide members. (a ~ b).length Then it easy to add a comma to create a one element tuple. IE: (a ~ b).length == a.length + b.length (a ~ b,).length == 1 The motivation for having these conversions was syntactic ambiguity. If there is none, just do it like this: (create_tuple,) get_value[0]
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 7:08 PM, deadalnix wrote: Le 24/09/2012 00:48, Andrei Alexandrescu a écrit : This notion a lot of trouble with it; I think it's safe to abandon it entirely. Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. This is a very weak point. In most cases, divide an conquer with tuple don't even make sense. The example came from min() applied to built-in "T..." tuples. I've implemented it a few times, and I recall at some point there was a compiler bug related to zero-length tuples. It was rather awkward to address. But there are many other cases. In my opinion, introducing a change of phase at length=1 is just causing trouble. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:08 PM, deadalnix wrote: Le 24/09/2012 00:48, Andrei Alexandrescu a écrit : This notion a lot of trouble with it; I think it's safe to abandon it entirely. Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. This is a very weak point. In most cases, divide an conquer with tuple don't even make sense. The example came from min() applied to built-in "T..." tuples. I've implemented it a few times, and I recall at some point there was a compiler bug related to zero-length tuples. It was rather awkward to address. But there are many other cases. In my opinion, introducing a change of phase at length=1 is just causing trouble. Andrei I understand the trouble here. But why divide and conquer is preferable here over a static foreach over the tuple ? Additionally, what lead me to think the idea is good is how tuple can be used to call function, or to extend the opDispatch feature to templated calls. I didn't wanted to go into such details, because I wanted to test several idea before doing a proposal. A lot of options are possible here, and interaction with other part of the language are everywhere.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 02:44, Timon Gehr a écrit : The motivation for having these conversions was syntactic ambiguity. If there is none, just do it like this: (create_tuple,) get_value[0] As I answered to Andrei, my motivation isn't related to syntax ambiguity, and I actually don't care what the syntax is as long as it isn't terribly twisted.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, September 24, 2012 03:31:08 deadalnix wrote: > Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : > > On 9/23/12 7:20 PM, Adam D. Ruppe wrote: > >> On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: > >>> I believe it is currently left-to-right for D, in all kinds of > >>> expressions, but DMD does not implement it yet. > >> > >> Yeah, I thought it was already defined. > > > > Actually it's right to left for assignments. In expr1 = expr2, expr2 > > gets evaluated first. > > > > Andrei > > Is it by implementation or by design ? Design. It makes no sense for the left-hand side of an assignment to be evaluated before the right-hand side. It's function arguments that should be evaluated left-to-right. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 03:14 AM, Andrei Alexandrescu wrote: On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is this documented anywhere?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 03:41 AM, Jonathan M Davis wrote: On Monday, September 24, 2012 03:31:08 deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Design. It makes no sense for the left-hand side of an assignment to be evaluated before the right-hand side. Of course it does. Some values are returned by dereferencing a hidden argument. It's function arguments that should be evaluated left-to-right. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 04:27 AM, Timon Gehr wrote: On 09/24/2012 03:41 AM, Jonathan M Davis wrote: On Monday, September 24, 2012 03:31:08 deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Design. It makes no sense for the left-hand side of an assignment to be evaluated before the right-hand side. Of course it does. Some values are returned by dereferencing a hidden argument. Nevermind. In the general case, a temporary still has to be generated because of aliasing issues. It's function arguments that should be evaluated left-to-right. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 9:27 PM, deadalnix wrote: I understand the trouble here. But why divide and conquer is preferable here over a static foreach over the tuple ? There are fewer data dependencies, which results on faster execution on today's CPUs. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 9:31 PM, deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Currently probably neither :o). I used to oppose it, then I figured it's actually nice because of things like: int[int] stuff; stuff[42] = stuff.length; Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12 10:15 PM, Timon Gehr wrote: On 09/24/2012 03:14 AM, Andrei Alexandrescu wrote: On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is this documented anywhere? Not to the best of my knowledge. I'm not even sure it's always the case. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sun, Sep 23, 2012 at 04:40:34PM -0400, Andrei Alexandrescu wrote: > I discussed this with Walter, and we concluded that we could > deprecate the comma operator if it helps tuples. So I started with > this: > > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 +1 to getting rid of the comma operator. (OK, just deprecation, but that's a good step.) I always felt it's one of those unnecessary holdovers from C. We don't need a comma operator. The only use cases I've ever seen of it is in specific contexts (such as for-loops) where suitable, relatively confined, syntax extensions would take care of everything without the invasiveness of having an entire operator. T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sun, 23 Sep 2012 21:30:08 -0700 "H. S. Teoh" wrote: > On Sun, Sep 23, 2012 at 04:40:34PM -0400, Andrei Alexandrescu wrote: > > I discussed this with Walter, and we concluded that we could > > deprecate the comma operator if it helps tuples. So I started with > > this: > > > > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 > > +1 to getting rid of the comma operator. (OK, just deprecation, but > that's a good step.) I always felt it's one of those unnecessary > holdovers from C. We don't need a comma operator. The only use cases > I've ever seen of it is in specific contexts (such as for-loops) where > suitable, relatively confined, syntax extensions would take care of > everything without the invasiveness of having an entire operator. > I saw it once in an earlier revision of RDMD from about a year ago. It was an awkward usage (IMO) and isn't there anymore. So basically, I agree that it's not particularly useful ;)
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sun, 23 Sep 2012 18:48:22 -0400 Andrei Alexandrescu wrote: > > Once a one-element tuple becomes equivalent to the actual item, > there's an explosion of trouble and special cases in the language and > in code that uses it. For example, divide and conquer code that > manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would > suddenly get to cases in which the slices are no longer tuples, and > so on. And that's only the beginning. > I think one of us is missing something, and I'm not entirely sure who. As I explained (perhaps poorly), the zero- and one-element tuples *would still be* tuples. They would just be implicitly convertible to non-tuple form *if* needed, and vice versa. Do you see a reason why that would *necessarily* not be the case? > I think it's safe to just not even discuss it. A nice way to put it :/ Part politician perhaps? ;)
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Glad to hear that comma operator won't be depreciated.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 23/09/12 22:40, Andrei Alexandrescu wrote:
I discussed this with Walter, and we concluded that we could deprecate
the comma operator if it helps tuples. So I started with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The analysis in
there fails to construct a case even half strong that deprecating the
comma operator could significantly help tuples. Well it essentially
concludes that tuples are mostly fine as they are, and attempts to
embellish them syntactically are marred with unexpected problems.
Nevertheless, I sure have missed aspects all over, so contributions are
appreciated.
Thanks,
Andrei
Regarding the comma operator: I'd love to deprecate it, but even if we
don't, could we at least ensure that this kind of rubbish doesn't compile:
void main()
{
int x;
x > 0, x += 5;
}
At present, because comma expressions are expressions, not statements,
the "x > 0" doesn't generate a "statement has no effect" error, despite
the fact that it is meaningless and gets completely discarded.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 21:51:35 UTC, Nick Sabalausky
wrote:
Ok, here's a crazy idea:
Do the reasons for explicit tuple-expansion necessarily apply to
zero- and one-element tuples? I'm not so sure. Suppose we
allowed
implicit expansion on those...
Now I know what you're thinking: That would be an ugly
inconsistency
between tuples of sizes >1 vs <=1. Well, *mechanically* yes, but
consider this:
*Logically* speaking, is there really any difference between a
one-element tuple and an ordinary single value? I don't think
so, and
here's why: What is a tuple, logically speaking? Multiple
values being
handled as if they were a single value. So what's a one-element
tuple?
*One* value being handled as if it were one value - which is
*is*.
Similarly, a zero-element tuple is logically equivalent to void
(or the
one value a void can have: the value void, a concept which has
been
argued in the past that might be useful for D, particularly in
metaprogramming). (I admit this is a little weaker than my
argument
for one-element tuples.)
So perhaps zero- and one-element tuples should be implicitly
convertible back and forth with void and ordinary non-tuple
values,
respectively (polysemous values?), because that's what they
essentially
are.
That means (at least I think it means) that things like () or
(1) or
((1)) require no way to disambiguate between tuple and
expression,
because either way they're the same thing (or at least freely
convertible).
Nope.
One of the ways in math to "build" the positive numbers based on
set theory is via singletons:
n := |tuple of empty tuples|
so "1" is defined as { {} } whereas "0" is simply {}. That does
not work with the above suggestion. Now, I realize this is an
arguably convoluted math example but it does show that the
treating { {} } as {} is limiting the expressive power of tuples.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 07:01, Nick Sabalausky wrote: I think one of us is missing something, and I'm not entirely sure who. As I explained (perhaps poorly), the zero- and one-element tuples *would still be* tuples. They would just be implicitly convertible to non-tuple form *if* needed, and vice versa. Do you see a reason why that would *necessarily* not be the case? Would that mean you could start doing things like: int a = 3; int b = a[0]; That feels very weird. -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-23 22:40, Andrei Alexandrescu wrote: I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 +1 -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 00:11, bearophile wrote: This is a complex topic, and in this post I am not able to discuss everything that needs to be discussed. So I will discuss only part of the story. First: tuples are important enough. I think they should be built-in in a modern language, but maybe having them as half-built-in will be enough in D. Currently in D we have (deprecated) built-in complex numbers that I use only once in a while, and half-usable library defined tuples that I use all the time. Second: removing comma operator from D has some advantages unrelated to tuple syntax. Even disallowing bad looking C-like code that uses commas is an improvement by itself (but maybe it's not a big enough improvement...). Third: replacing the packing syntax tuple(x,y) with (x,y) is nice and maybe even expected in a partially functional language as D, but that's _not_ going to improve D usability a lot. What I am asking for is different: I'd like D tuples to support handy unpacking syntax: 1) In function signatures; 2) In foreach; 3) At assignment points; 4) In switch cases. +1 -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 10:56:40 +0200
Jacob Carlborg wrote:
> On 2012-09-24 07:01, Nick Sabalausky wrote:
>
> > I think one of us is missing something, and I'm not entirely sure
> > who.
> >
> > As I explained (perhaps poorly), the zero- and one-element tuples
> > *would still be* tuples. They would just be implicitly convertible
> > to non-tuple form *if* needed, and vice versa. Do you see a reason
> > why that would *necessarily* not be the case?
>
> Would that mean you could start doing things like:
>
> int a = 3;
> int b = a[0];
>
> That feels very weird.
>
No, because there's nothing typed (int) involved there. But you could do
this:
int a = 3;
(int) b = a;
a = b;
Or this:
void foo((int) a)
{
int b1 = a[0];
int b2 = a;
}
int c = 3;
foo(c);
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 10:47:38 +0200
"foobar" wrote:
>
> Nope.
> One of the ways in math to "build" the positive numbers based on
> set theory is via singletons:
> n := |tuple of empty tuples|
> so "1" is defined as { {} } whereas "0" is simply {}. That does
> not work with the above suggestion. Now, I realize this is an
> arguably convoluted math example but it does show that the
> treating { {} } as {} is limiting the expressive power of tuples.
>
And int's are limiting compared to mathematical integers. So what?
So ok, maybe this is limiting from a theoretical standpoint. But
practically speaking? I dunno. We're not making tuples to emulate
set theory here, we're just looking for ad-hoc anonymous structs.
Besides, I only said they were logically the same thing, not
mechanically. I'm only suggesting that a one-element tuple be implicitly
convertible to/from the type of its element. So there would likely
still be the different types, it just makes sense that you should be
able to use one as the other.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 06:20:55 -0400
Nick Sabalausky wrote:
> On Mon, 24 Sep 2012 10:47:38 +0200
> "foobar" wrote:
> >
> > Nope.
> > One of the ways in math to "build" the positive numbers based on
> > set theory is via singletons:
> > n := |tuple of empty tuples|
> > so "1" is defined as { {} } whereas "0" is simply {}. That does
> > not work with the above suggestion. Now, I realize this is an
> > arguably convoluted math example but it does show that the
> > treating { {} } as {} is limiting the expressive power of tuples.
> >
>
> And int's are limiting compared to mathematical integers. So what?
> So ok, maybe this is limiting from a theoretical standpoint. But
> practically speaking? I dunno. We're not making tuples to emulate
> set theory here, we're just looking for ad-hoc anonymous structs.
>
> Besides, I only said they were logically the same thing, not
> mechanically. I'm only suggesting that a one-element tuple be
> implicitly convertible to/from the type of its element. So there
> would likely still be the different types, it just makes sense that
> you should be able to use one as the other.
>
I guess what I mean is: If you really need a strict separation between
a "tuple of one" and a non-tuple, then maybe it's an indication
that you're just using the wrong tool?
That said, I'm not necessarily opposed to the strict separation if we
had a good candidate for built-in tuple literal syntax. But *if* the
best we have is parens (and maybe there *is* something better?) then
maybe this would be an acceptable way to achieve it?
Ie:
// (3) is polysemous: Either int or (int)
int a = (3); // Normal value
(int) b = (3); // One-element tuple
auto c = (3); // Default to normal "int"?
void foo(int z) {}
void foo((int) z) {}
void takeInt(int z) {}
void takeTuple((int) z) {}
foo(a); // Calls first overload
foo(b); // Calls second overload
takeInt(a); // ok
takeInt(b); // ok
takeTuple(a); // ok
takeTuple(b); // ok
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 12:06, Nick Sabalausky wrote: No, because there's nothing typed (int) involved there. But you could do this: int a = 3; (int) b = a; a = b; But you said: "They would just be implicitly convertible to non-tuple form *if* needed, and vice versa." To me that sounds like a tuple of one element of the type int would be implicitly convertible to an int. And, an int would be implicitly convertible to a tuple of one element. -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 05:25 AM, Andrei Alexandrescu wrote: On 9/23/12 9:31 PM, deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Currently probably neither :o). I used to oppose it, then I figured it's actually nice because of things like: int[int] stuff; stuff[42] = stuff.length; Andrei So you are arguing for computing the arguments for a method call before the receiver is computed? (What about UFCS?) Or should opAssign behave specially?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 14:15, Jacob Carlborg a écrit : On 2012-09-24 12:06, Nick Sabalausky wrote: No, because there's nothing typed (int) involved there. But you could do this: int a = 3; (int) b = a; a = b; But you said: "They would just be implicitly convertible to non-tuple form *if* needed, and vice versa." To me that sounds like a tuple of one element of the type int would be implicitly convertible to an int. And, an int would be implicitly convertible to a tuple of one element. I understand your example, but in it, no (int) are involved. So no conversion have to be done (and you get an error). You see in example above that conversion is done when int is given where (int) is expected or vice versa, not whenever the compiler feels to.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
wrote:
> That said, I'm not necessarily opposed to the strict separation if we
> had a good candidate for built-in tuple literal syntax. But *if* the
> best we have is parens (and maybe there *is* something better?) then
> maybe this would be an acceptable way to achieve it?
If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
element tuples), then maybe *for once* a simple syntax change could
solve them? I know syntax proposals are a dime a dozen in this
newsgroup, but why not here, to avoid the ((1)) problem?
For example choosing { 1, 2} to represent a tuple? { } blocks in D
enclose semi-colon terminated declarations or expressions, but here
it's enclosing comma-separated expressions. And, since { } is probably
dangerous without a completly integrated type systems giving a type to
all expressions ( (){} anyone?) , why not use (| 1, 2 |), or whatever
syntax strikes our collective fancy? (I propose *not* to use < , >)
Then, the compiler has to change the way it prints its internal tuple,
to follow the new syntax.
> Ie:
>
> // (3) is polysemous: Either int or (int)
> int a = (3); // Normal value
> (int) b = (3); // One-element tuple
> auto c = (3); // Default to normal "int"?
For the third case, I'd say it defaults to a tuple. But then again,
using another syntax solves this problem.
auto c = (| 3 |); // or c = { 3 };
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 8:18 AM, Timon Gehr wrote: On 09/24/2012 05:25 AM, Andrei Alexandrescu wrote: On 9/23/12 9:31 PM, deadalnix wrote: Le 24/09/2012 03:14, Andrei Alexandrescu a écrit : On 9/23/12 7:20 PM, Adam D. Ruppe wrote: On Sunday, 23 September 2012 at 22:55:33 UTC, Timon Gehr wrote: I believe it is currently left-to-right for D, in all kinds of expressions, but DMD does not implement it yet. Yeah, I thought it was already defined. Actually it's right to left for assignments. In expr1 = expr2, expr2 gets evaluated first. Andrei Is it by implementation or by design ? Currently probably neither :o). I used to oppose it, then I figured it's actually nice because of things like: int[int] stuff; stuff[42] = stuff.length; Andrei So you are arguing for computing the arguments for a method call before the receiver is computed? (What about UFCS?) Or should opAssign behave specially? Ha, good point about opAssign! Probably we should go with left-to-right everywhere, including in assignment. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
The analysis in there fails to construct a case even half
strong that deprecating the comma operator could significantly
help tuples.
That is because it does not base the discussion on the right
limitations of built-in tuples:
auto (a,b) = (1,"3");
(auto a, string b) = (1, "3");
Agreed, this is the key thing missing from D.
There is also no consideration in the DIP of what I consider one
of D's most confusing "features": "pre-expanded tuples" or in
other words, type tuples. These beasts can be very confusing when
first encountered, and they do not behave like any data type in
any other language I know of:
import std.typecons; // Contains Tuple!(...), which reminds me,
// how do I know which module contains a given feature?
// http://dlang.org/phobos/index.html doesn't mention it.
void call() { humm(1, 2); }
void humm(T...)(T x) // x, a pre-expanded tuple
{
//auto c = [x.expand]; // ERROR, expand undefined
// (it's already expanded!)
auto a = x;// a is also pre-expanded
auto b = [ a, a ]; // int[], not Tuple!(int,int)[]
//int d = derr(x); // ERROR, have to un-expand it
writeln(a);// "12"
writeln(b);// "[1, 2, 1, 2]"
}
int derr(Tuple!(int,int) a) { return a[0] + a[1]; }
I know you guys are all used to this behavior but I'm telling
you, pre-expanding is very weird. It would be nice if type tuples
could somehow be unified with library tuples and behave like the
latter.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 01:01:29 -0400, Nick Sabalausky
wrote:
On Sun, 23 Sep 2012 18:48:22 -0400
Andrei Alexandrescu wrote:
Once a one-element tuple becomes equivalent to the actual item,
there's an explosion of trouble and special cases in the language and
in code that uses it. For example, divide and conquer code that
manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would
suddenly get to cases in which the slices are no longer tuples, and
so on. And that's only the beginning.
I think one of us is missing something, and I'm not entirely sure
who.
As I explained (perhaps poorly), the zero- and one-element tuples *would
still be* tuples. They would just be implicitly convertible to
non-tuple form *if* needed, and vice versa. Do you see a reason why
that would *necessarily* not be the case?
(int[]) x;
int a = x.length;
is a == 0 or 1?
I agree with Andrei, we need something different.
I don't profess to be even close to an expert on tuples, but I feel they
should be built-in to the language, since they are actually language
constructs that we are declaring types for.
Without any research or investigation, what about using a different set of
delimiters for tuples? Like {1,2,3}
Right now, I think that is reserved for static struct initializers. But
can't those be considered a tuple also? Someone will probably destroy
this 10 milliseconds after I send it :)
-Steve
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, 24 September 2012 at 10:05:18 UTC, Nick Sabalausky
wrote:
On Mon, 24 Sep 2012 10:56:40 +0200
Jacob Carlborg wrote:
On 2012-09-24 07:01, Nick Sabalausky wrote:
> I think one of us is missing something, and I'm not entirely
> sure
> who.
>
> As I explained (perhaps poorly), the zero- and one-element
> tuples
> *would still be* tuples. They would just be implicitly
> convertible
> to non-tuple form *if* needed, and vice versa. Do you see a
> reason
> why that would *necessarily* not be the case?
Would that mean you could start doing things like:
int a = 3;
int b = a[0];
That feels very weird.
No, because there's nothing typed (int) involved there. But you
could do
this:
int a = 3;
(int) b = a;
a = b;
Or this:
void foo((int) a)
{
int b1 = a[0];
int b2 = a;
}
int c = 3;
foo(c);
What's the point than?
here's equivalent code without this "feature":
int a = 3;
(int) b = (a); // explicitly make 1-tuple
(a) = b; // unpacking syntax
void foo((int) a) {
int b1 = a[0];
(int b2) = a; // one possible syntax
}
int c = 3;
foo ((c));
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, 24 September 2012 at 10:20:01 UTC, Nick Sabalausky
wrote:
On Mon, 24 Sep 2012 10:47:38 +0200
"foobar" wrote:
Nope.
One of the ways in math to "build" the positive numbers based
on set theory is via singletons:
n := |tuple of empty tuples|
so "1" is defined as { {} } whereas "0" is simply {}. That
does not work with the above suggestion. Now, I realize this
is an arguably convoluted math example but it does show that
the treating { {} } as {} is limiting the expressive power of
tuples.
And int's are limiting compared to mathematical integers. So
what?
So ok, maybe this is limiting from a theoretical standpoint. But
practically speaking? I dunno. We're not making tuples to
emulate
set theory here, we're just looking for ad-hoc anonymous
structs.
Besides, I only said they were logically the same thing, not
mechanically. I'm only suggesting that a one-element tuple be
implicitly
convertible to/from the type of its element. So there would
likely
still be the different types, it just makes sense that you
should be
able to use one as the other.
I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to >1 elements? *This* I'm
against for practical as well as completeness reasons. Andrei
already provided one example, and another would be a proper unit
type. e.g.
void foo(int a) {}
void bar (int b) { return foo(b); }
- Is the suggestion to allow implicit conversion between (T) and
T?
This brings almost no benefit - (you save two keystrokes?) and
adds a special case to the language. The added complexity really
does not justify this.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 1:01 AM, Nick Sabalausky wrote: On Sun, 23 Sep 2012 18:48:22 -0400 Andrei Alexandrescu wrote: Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. I think one of us is missing something, and I'm not entirely sure who. As I explained (perhaps poorly), the zero- and one-element tuples *would still be* tuples. They would just be implicitly convertible to non-tuple form *if* needed, and vice versa. Do you see a reason why that would *necessarily* not be the case? It just creates endless little problems and confusion coming outta the woodwork, as others have pointed out in response to this. There are languages that have also explored a similar approach - a value can be automatically converted to a one-element array and vice versa. It's problematic, especially in a language with generics and function overloading. I think it's safe to just not even discuss it. A nice way to put it :/ Part politician perhaps? ;) I meant it in a simple and forward way - all I want is to save time and trouble in exploring a no-win design. From sheer experience gathered from years at hacking at this stuff I know this can be done but is not worth the trouble. Since it can be done, there's no argument that would definitively close the discussion, and that demotivates me from coming up with explanations. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 4:17 AM, Don Clugston wrote:
Regarding the comma operator: I'd love to deprecate it, but even if we
don't, could we at least ensure that this kind of rubbish doesn't compile:
void main()
{
int x;
x > 0, x += 5;
}
At present, because comma expressions are expressions, not statements,
the "x > 0" doesn't generate a "statement has no effect" error, despite
the fact that it is meaningless and gets completely discarded.
Interesting. The comma operator is probably the only one in which an
expression is evaluated only for the sake of its side effects. So
eliminating the comma operator would just get rid of that case by design.
Of course, there's always the option of adding more checks or rewriting
the comma operator from "expr1, expr2, expr3" to "{ expr1; expr2; return
expr3; }()".
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, 24 September 2012 at 14:52:21 UTC, Steven
Schveighoffer wrote:
(int[]) x;
int a = x.length;
is a == 0 or 1?
I agree with Andrei, we need something different.
This is exactly the question I was going to ask ...
I don't profess to be even close to an expert on tuples, but I
feel they should be built-in to the language, since they are
actually language constructs that we are declaring types for.
Without any research or investigation, what about using a
different set of delimiters for tuples? Like {1,2,3}
... and exactly the syntax I was going to propose! {} is already
used in C languages for heterogeneous data
structures(structs/classes, JSON etc). Using () creates too many
special cases, especially in generic programming and seeing how
other languages are dealing with them we'd rather avoid them from
the very beginning.
Right now, I think that is reserved for static struct
initializers. But can't those be considered a tuple also?
Someone will probably destroy this 10 milliseconds after I send
it :)
-Steve
It would be awesome if we could make tuples generic initializers
for various data types in D. Not just structs but for instance
arrays:
int[] a = {1, 2, 3, 4};
Compiler possesses enough type information to know that this
tuple could be converted to the int[].
P.S. The only collision I see with {} is a delegate literal, but
to be honest it's not worth the merit and quite confusing in
fact. There are 3 other ways to define a delegate in D which will
cover all of the user's needs.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 9:27 AM, Philippe Sigaud wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
wrote:
That said, I'm not necessarily opposed to the strict separation if we
had a good candidate for built-in tuple literal syntax. But *if* the
best we have is parens (and maybe there *is* something better?) then
maybe this would be an acceptable way to achieve it?
If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
element tuples), then maybe *for once* a simple syntax change could
solve them? I know syntax proposals are a dime a dozen in this
newsgroup, but why not here, to avoid the ((1)) problem?
For example choosing { 1, 2} to represent a tuple? { } blocks in D
enclose semi-colon terminated declarations or expressions, but here
it's enclosing comma-separated expressions. And, since { } is probably
dangerous without a completly integrated type systems giving a type to
all expressions ( (){} anyone?) , why not use (| 1, 2 |), or whatever
syntax strikes our collective fancy? (I propose *not* to use< ,>)
Then, the compiler has to change the way it prints its internal tuple,
to follow the new syntax.
Ie:
// (3) is polysemous: Either int or (int)
int a = (3); // Normal value
(int) b = (3); // One-element tuple
auto c = (3); // Default to normal "int"?
For the third case, I'd say it defaults to a tuple. But then again,
using another syntax solves this problem.
auto c = (| 3 |); // or c = { 3 };
I think my main problem with this is that I'm perfectly happy with the
baseline, which has "tuple(" as the left delimiter and ")" as the right
delimiter. I'd be more excited to invent notation if there was
overwhelming or at least considerable evidence that the notation
considerably helps certain use cases, or is very frequent. As things
are, I'd be quite "meh" about suddenly adding lenses.
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and exactly the syntax I was going to propose!
Assume you had this syntax working today. So instead of writing
"tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code
be better? (Honest question. Don't forget that adding the => syntax for
lambda /did/ make for better code.)
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 11:29 AM, Andrei Alexandrescu wrote:
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and exactly the syntax I was going to propose!
Assume you had this syntax working today. So instead of writing
"tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code
be better? (Honest question. Don't forget that adding the => syntax for
lambda /did/ make for better code.)
Andrei
Hrm, I meant "tuple(a, b, c)".
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, September 24, 2012 16:00:06 David Piepgrass wrote: > There is also no consideration in the DIP of what I consider one > of D's most confusing "features": "pre-expanded tuples" or in > other words, type tuples. That's a completely separate issue. The DIP doesn't even introduce normal tuples into the language. It merely proposes that the comma operator be deprecated and uses the _possibility_ of introducing tuples into the language as an argument for that deprecation. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu
wrote:
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer
wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and exactly the syntax I was going to propose!
Assume you had this syntax working today. So instead of writing
"tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code
be better? (Honest question. Don't forget that adding the => syntax for
lambda /did/ make for better code.)
I can't honestly say I've used either tuple(a, b, c), or tuples in other
languages very much.
I can say that I have *avoided* tuples as return values because I don't
want to type Tuple!(x, y) as the return type. But I haven't come across
that need very much. You can say "yeah, but what about auto?" Cases I'm
referring to were to make interface declarations -- can't use auto.
I can similarly say I have never had need to type x, b (i.e. use the
current comma operator), except in for statements.
I'd be fine with getting rid of comma operator and not doing tuples in the
language, but it certainly feels weird that we have a tuple type in the
language, without any formal type unless you alias it (as std.tuple does).
It's almost like instead of saying:
int[] x;
you had to do:
typeof([1,2]) x;
Yeah, with alias, we could arrive at:
Array!int x;
But really, it seems odd that the language has a type for something that
doesn't have a name/syntax. Odd, but not unworkable.
I just wanted to point out that it seems the largest trouble,
implementation-wise, for DIP19 is the choice of parentheses to denote a
tuple. If we do want to add built-in tuples, maybe we should be looking
at a different delimiter.
-Steve
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 11:47:09 -0400, Steven Schveighoffer
wrote:
I can say that I have *avoided* tuples as return values because I don't
want to type Tuple!(x, y) as the return type. But I haven't come across
that need very much. You can say "yeah, but what about auto?" Cases
I'm referring to were to make interface declarations -- can't use auto.
To further this, I would love to see something where "quick POD structs"
can be constructed using some builtin syntax.
For example:
{valid:bool, value:int}
which would be equivalent to Tuple!(bool, "valid", int, "value")
I would *definitely* like to see that. This might be on par with the =>
addition.
-Steve
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, Sep 24, 2012 at 5:24 PM, Andrei Alexandrescu
wrote:
>
> I think my main problem with this is that I'm perfectly happy with the
> baseline, which has "tuple(" as the left delimiter and ")" as the right
> delimiter.
I found it a bit long compared to other languages in the beginning,
but I've been using them heavily since you added them to Phobos and
I'm now quite happy with them. I even like the .expand thingy.
(I have a few nitpicks, about std.typecons.tuple, but those would be
the subject of another thread)
> I'd be more excited to invent notation if there was overwhelming
> or at least considerable evidence that the notation considerably helps
> certain use cases, or is very frequent. As things are, I'd be quite "meh"
> about suddenly adding lenses.
OK.
One standard use for tuples is assignment:
a,b = someTuple; // a and b already exist in this scope
auto (c,d) = someTuple; // creates c and d
and similar variations, which Phobos' tuples do not provide.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
If tuples are ever introduced, I hope parentheses will not be used. I would prefer something like this: tuple<2,1,8>
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Caligo: If tuples are ever introduced, I hope parentheses will not be used. I would prefer something like this: tuple<2,1,8> That both breaks code, doesn't improve the syntax, but makes it worse. Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 11:47 AM, Steven Schveighoffer wrote:
On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu
wrote:
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer
wrote:
Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}
and exactly the syntax I was going to propose!
Assume you had this syntax working today. So instead of writing
"tuple(a. b. c)" you write "{ a, b, c }". To what extent would your
code be better? (Honest question. Don't forget that adding the =>
syntax for lambda /did/ make for better code.)
I can't honestly say I've used either tuple(a, b, c), or tuples in other
languages very much.
I can say that I have *avoided* tuples as return values because I don't
want to type Tuple!(x, y) as the return type. But I haven't come across
that need very much. You can say "yeah, but what about auto?" Cases I'm
referring to were to make interface declarations -- can't use auto.
Yah, after writing DIP19 I was like, "creating tuples is nice and easy,
but expressing function returns is less so". Besides, the comma operator
does not hurt the syntax for types all that much.
I just wanted to point out that it seems the largest trouble,
implementation-wise, for DIP19 is the choice of parentheses to denote a
tuple. If we do want to add built-in tuples, maybe we should be looking
at a different delimiter.
Indeed. The question is what mileage we get out of it.
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, September 23, 2012 16:40:34 Andrei Alexandrescu wrote: > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 My #1 concern here is that for loops do _not_ ever change how they function with regards to commas (which the DIP seems to do, but it also seems to imply that we might want to get rid of that later - which I do _not_ agree with). The comma operator is occasionally useful beyond for loops, but it's usually considered bad practice to do so, so if we want to get rid of it aside from for loops, then I have no problem with that. If anything, I'd argue that bringing tuples into the mix is muddying matters, since I think that there's a solid argument for deprecating the comma operator based solely on the problems that it causes even if we never add any other syntax which uses commas in a way that the comma operator prevents. As to whether we add tuples or not, I don't know. Being able to do something like. int i; string s; (i, s) = foo(); or (auto i, string is) = foo(); would be useful, but I can live without it. std.typecons.tuple takes care of most of what you need from tuples IMHO. So, if we can find a way to cleanly add tuples to the language, I'm fine with that, but I'm also fine with leaving tuples as they are. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 15:05, deadalnix wrote: I understand your example, but in it, no (int) are involved. So no conversion have to be done (and you get an error). What has that to do with anything. Example: auto a = 3; There's no mention of "int" in that example, yet "a" is still an int. You see in example above that conversion is done when int is given where (int) is expected or vice versa, not whenever the compiler feels to. int b = 4; b[0] Why isn't that an example of where a (int) is expected? I'm no expert on how the compiler does semantic analyze but if it sees something like "b[0]" then it thinks: it's either an array, a pointer, an associate array, opAssign or now a tuple. Then it thinks: hey an int is implicitly convertible to a one element tuple, I do that. -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 17:24, Andrei Alexandrescu wrote:
I think my main problem with this is that I'm perfectly happy with the
baseline, which has "tuple(" as the left delimiter and ")" as the right
delimiter. I'd be more excited to invent notation if there was
overwhelming or at least considerable evidence that the notation
considerably helps certain use cases, or is very frequent. As things
are, I'd be quite "meh" about suddenly adding lenses.
Declaring a tuple is still quire verbose can could really benefit from a
shorter syntax.
(int, int) foo ();
Vs
import std.typecons;
Tuple!(int, int) foo (); // or what the correct syntax is
--
/Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
foo(<11,2,8>, a, b) vs foo((11,2,8), a, b) Parentheses are everywhere in D. Sometimes it looks like Lisp. On Mon, Sep 24, 2012 at 11:37 AM, bearophile wrote: > > That both breaks code, doesn't improve the syntax, but makes it worse. > > Bye, > bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 21:51:35 UTC, Nick Sabalausky wrote: *Logically* speaking, is there really any difference between a one-element tuple and an ordinary single value? I don't think so, and here's why: What is a tuple, logically speaking? Multiple values being handled as if they were a single value. So what's a one-element tuple? *One* value being handled as if it were one value - which is *is*. Similarly, a zero-element tuple is logically equivalent to void (or the one value a void can have: the value void, a concept which has been argued in the past that might be useful for D, particularly in metaprogramming). (I admit this is a little weaker than my argument for one-element tuples.) So perhaps zero- and one-element tuples should be implicitly convertible back and forth with void and ordinary non-tuple values, respectively (polysemous values?), because that's what they essentially are. It's informative to look a bit at the Ocaml language: - no distinction between 1-tuple and single value: # 1;; - : int = 1 # (1);; - : int = 1 - "void" type is called unit and its notation is the empty tuple: # ();; - : unit = () - for some reason tuples can't be indexed in Ocaml
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 21:16:06 +0200 Jacob Carlborg wrote: > On 2012-09-24 15:05, deadalnix wrote: > > > I understand your example, but in it, no (int) are involved. So no > > conversion have to be done (and you get an error). > > What has that to do with anything. Example: > > auto a = 3; > > There's no mention of "int" in that example, yet "a" is still an int. > Of course there is, it's the default type for the literal you have there. > > You see in example above that conversion is done when int is given > > where (int) is expected or vice versa, not whenever the compiler > > feels to. > > int b = 4; > b[0] > > Why isn't that an example of where a (int) is expected? Because 'b' is neither being assigned to an (int) nor passed into a template/func parameter that's expecting an (int).
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 16:50:47 +0200
"foobar" wrote:
> On Monday, 24 September 2012 at 10:05:18 UTC, Nick Sabalausky
> wrote:
> > On Mon, 24 Sep 2012 10:56:40 +0200
> > Jacob Carlborg wrote:
> >
> >> On 2012-09-24 07:01, Nick Sabalausky wrote:
> >>
> >> > I think one of us is missing something, and I'm not entirely
> >> > sure
> >> > who.
> >> >
> >> > As I explained (perhaps poorly), the zero- and one-element
> >> > tuples
> >> > *would still be* tuples. They would just be implicitly
> >> > convertible
> >> > to non-tuple form *if* needed, and vice versa. Do you see a
> >> > reason
> >> > why that would *necessarily* not be the case?
> >>
> >> Would that mean you could start doing things like:
> >>
> >> int a = 3;
> >> int b = a[0];
> >>
> >> That feels very weird.
> >>
> >
> > No, because there's nothing typed (int) involved there. But you
> > could do
> > this:
> >
> > int a = 3;
> > (int) b = a;
> > a = b;
> >
> > Or this:
> >
> > void foo((int) a)
> > {
> > int b1 = a[0];
> > int b2 = a;
> > }
> > int c = 3;
> > foo(c);
>
> What's the point than?
> here's equivalent code without this "feature":
>
> int a = 3;
> (int) b = (a); // explicitly make 1-tuple
My understanding is that *can't* be made to work in the general
case (without those ugly trailing commas) because, in general, how's the
compiler supposed to know if (a) is a parenthesis expression or a tuple
literal?
That's exactly what my suggestion was attempting to solve: The '(a)'
would be a paren expression (with type 'int') just as right now, but
then in order to make it still assignable to '(int)', just as you've
done, we say "Ok, you can assign an 'int' to an '(int)' and it
implicitly converts."
All the stuff I said earlier about one-element tuples being
conceptually the same as non-tuples was just my way of explaining that
it's not too much of an unintuitive inconsistency if we allow implicit
packing/unpacking of one-element tuples, but not two-or-more-element
tuples.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 15:27:19 +0200
Philippe Sigaud wrote:
> On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
> wrote:
>
> > That said, I'm not necessarily opposed to the strict separation if
> > we had a good candidate for built-in tuple literal syntax. But *if*
> > the best we have is parens (and maybe there *is* something better?)
> > then maybe this would be an acceptable way to achieve it?
>
> If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
> element tuples), then maybe *for once* a simple syntax change could
> solve them? I know syntax proposals are a dime a dozen in this
> newsgroup, but why not here, to avoid the ((1)) problem?
>
I'm all for that. In fact, I was was just about to post the same
suggestion.
My bikeshed is colored one of these:
(:1,2)
(|1,2)
Minimal syntax (one extra character), no ambiguities with anything
else AFAIK. Looks kinda funny, but so did !() at first and we all got
used to that.
> For example choosing { 1, 2} to represent a tuple?
I like it, but what about zero-element tuples vs empty code blocks?
(Or is it ok because code blocks can't be used inside, or as,
expressions?)
Also, it may be too easy to accidentally get mixups between one-element
tuples and certain one-statement blocks:
{ foo(); } // Block
vs
{ foo() } // Either a tuple or a forgotten semicolon
Not sure if that's a big enough deal, though.
> > Ie:
> >
> > // (3) is polysemous: Either int or (int)
> > int a = (3); // Normal value
> > (int) b = (3); // One-element tuple
> > auto c = (3); // Default to normal "int"?
>
> For the third case, I'd say it defaults to a tuple. But then again,
> using another syntax solves this problem.
>
My reasoning for defaulting to non-tuple was minimizing code breakage
and simplifying the handling of general expresssions that happen to
involve parens (ie, it's always a mere expression until it gets
assigned/passed-in to a tuple). But I agree, just using a syntax that's
unambiguous from the start is better.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 10:53:14 -0400 "Steven Schveighoffer" wrote: > > (int[]) x; > > int a = x.length; > > is a == 0 or 1? > It'd be 1, but I agree that's a pretty solid counter-argument.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 12:51:18 -0400 Andrei Alexandrescu wrote: > On 9/24/12 11:47 AM, Steven Schveighoffer wrote: > > I just wanted to point out that it seems the largest trouble, > > implementation-wise, for DIP19 is the choice of parentheses to > > denote a tuple. If we do want to add built-in tuples, maybe we > > should be looking at a different delimiter. > > Indeed. The question is what mileage we get out of it. > Since the issues with current tuples tend to discourage their use (at least for me anyway), it's hard to say without having them. Maybe it would help to look at languages that do have good tuples and see what kind of mileage they get out of them?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 11:22 PM, Nick Sabalausky wrote:
On Mon, 24 Sep 2012 15:27:19 +0200
Philippe Sigaud wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
wrote:
That said, I'm not necessarily opposed to the strict separation if
we had a good candidate for built-in tuple literal syntax. But *if*
the best we have is parens (and maybe there *is* something better?)
then maybe this would be an acceptable way to achieve it?
If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
element tuples), then maybe *for once* a simple syntax change could
solve them? I know syntax proposals are a dime a dozen in this
newsgroup, but why not here, to avoid the ((1)) problem?
I'm all for that. In fact, I was was just about to post the same
suggestion.
My bikeshed is colored one of these:
(:1,2)
(|1,2)
At that point you might as well just use
import std.typecons : q = tuple, Q = Tuple;
Q!(int, int) foo(){
return q(1, 2);
}
If built-in tuples are not going to look like
(1, 2)
then imho we might as well leave them out, while still addressing
unpacking in the locations bearophile has designated.
Minimal syntax (one extra character), no ambiguities with anything
else AFAIK. Looks kinda funny, but so did !() at first and we all got
used to that.
For example choosing { 1, 2} to represent a tuple?
I like it, but what about zero-element tuples vs empty code blocks?
(Or is it ok because code blocks can't be used inside, or as,
expressions?)
Also, it may be too easy to accidentally get mixups between one-element
tuples and certain one-statement blocks:
{ foo(); } // Block
vs
{ foo() } // Either a tuple or a forgotten semicolon
Not sure if that's a big enough deal, though.
...
q(foo())
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 09:50 PM, Caligo wrote: On Mon, Sep 24, 2012 at 11:37 AM, bearophile wrote: That both breaks code, doesn't improve the syntax, but makes it worse. Bye, bearophile foo(<11,2,8>, a, b) vs foo((11,2,8), a, b) I don't spot a significant difference. Parentheses are everywhere in D. Sometimes it looks like Lisp. Lisp is beautiful.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Timon Gehr:
My bikeshed is colored one of these:
(:1,2)
(|1,2)
At that point you might as well just use
import std.typecons : q = tuple, Q = Tuple;
Q!(int, int) foo(){
return q(1, 2);
}
If built-in tuples are not going to look like
(1, 2)
then imho we might as well leave them out,
But the banana syntax doesn't look bad:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
It's short enough, it's not visually noisy, it's simple enough to
type, it consistently avoids the problems with literals for
0-tuples and 1-tuples, and it's sufficiently intuitive once you
have seen it one time. It's just a bit longer to type than the
syntax with simple (), that has problems with the shorter tuples.
The now dead Fortress language used several similar syntaxes,
like (|...|), {|...|}, [|...|], etc.
Bye,
bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 21:50:34 +0200, Caligo wrote: foo(<11,2,8>, a, b) vs foo((11,2,8), a, b) Parentheses are everywhere in D. Sometimes it looks like Lisp. And <> is ambiguous, ugly, an affront before Walter, and an abomination born in the fiery depths of hell. Can we please just leave it behind? -- Simen
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/25/2012 12:28 AM, bearophile wrote:
Timon Gehr:
My bikeshed is colored one of these:
(:1,2)
(|1,2)
At that point you might as well just use
import std.typecons : q = tuple, Q = Tuple;
Q!(int, int) foo(){
return q(1, 2);
}
If built-in tuples are not going to look like
(1, 2)
then imho we might as well leave them out,
But the banana syntax doesn't look bad:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
It's short enough,
It's not shorter than q()
it's not visually noisy,
It adds more noise than q()
it's simple enough to type,
It is harder to type than q().
it consistently avoids the problems with literals for
0-tuples and 1-tuples, and it's sufficiently intuitive once you
have seen it one time. It's just a bit longer to type than the
syntax with simple (), that has problems with the shorter tuples.
I still think any built-in special syntax that differs from (1,2,3) is
not worth it.
The now dead Fortress language used several similar syntaxes,
like (|...|), {|...|}, [|...|], etc.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 6:28 PM, bearophile wrote:
Timon Gehr:
My bikeshed is colored one of these:
(:1,2)
(|1,2)
At that point you might as well just use
import std.typecons : q = tuple, Q = Tuple;
Q!(int, int) foo(){
return q(1, 2);
}
If built-in tuples are not going to look like
(1, 2)
then imho we might as well leave them out,
But the banana syntax doesn't look bad:
(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)
tuple()
tuple(1)
tuple(1, 2)
tuple(1, 2, 3)
also arguably enjoys the same advantages and in fact is much more
intuitive. Like, totally intuitive. Like, it says "tuple" to create a
tuple. And one advantage is, there's never ever going to be butt jokes
about tuple() as there'd be with "(||)".
It's short enough, it's not visually noisy, it's simple enough to
type, it consistently avoids the problems with literals for
0-tuples and 1-tuples, and it's sufficiently intuitive once you
have seen it one time. It's just a bit longer to type than the
syntax with simple (), that has problems with the shorter tuples.
The now dead Fortress language used several similar syntaxes,
like (|...|), {|...|}, [|...|], etc.
Well let's not take inspiration from dead languages :o).
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 17:31:27 -0400, Nick Sabalausky wrote: On Mon, 24 Sep 2012 10:53:14 -0400 "Steven Schveighoffer" wrote: (int[]) x; int a = x.length; is a == 0 or 1? It'd be 1, but I agree that's a pretty solid counter-argument. It would be if it were valid code :) d complains (and rightly so) that you can't use C-style casts anymore! This is what I really meant: int[] x; int a = (x).length; But I think you got the point. However, this brings up another issue, what about porting C code? All of a sudden c style casts are no loner errors, but are type tuples! -Steve
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12, Steven Schveighoffer wrote: > However, this brings up another issue, what about porting C code? All of > a sudden c style casts are no loner errors, but are type tuples! I think they're still errors: int x = (int)foo; Maybe the compiler could figure out if a cast was attempted rather than a tuple, and could print out the ol' "Can't use C shenanigans in D" error.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 22:45, Nick Sabalausky wrote:
Because 'b' is neither being assigned to an (int) nor passed into a
template/func parameter that's expecting an (int).
Either I'm just stupid or I've failed completely to understand "implicit
convertible to".
Another example:
struct Foo
{
int[] arr;
alias arr this;
}
void main ()
{
auto foo = Foo([3, 4]);
auto i = foo[0];
}
Have a look at the last line. In that line "foo" is implicitly converted
to "int[]" with the help of the "alias this" in Foo, because the context
requires something "indexable". Since you cannot index a struct the
implicit conversion kicks in. What's the difference?
--
/Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-25 00:28, bearophile wrote: (||) (|1|) (|1, 2|) (|1, 2, 3|) What about: || |1| |1, 2| -- /Jacob Carlborg
