View mode: basic / threaded / horizontal-split · Log in · Help
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
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
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
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
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
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
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
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
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
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home