Thread overview | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
September 23, 2012 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 |
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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++) {}
|
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 9/23/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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)) |
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to foobar | 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.
|
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to foobar | 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"
|
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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.
|
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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. |
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to foobar | 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. |
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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). |
September 23, 2012 Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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. |
Copyright © 1999-2021 by the D Language Foundation