Hi,

Consider this code:

if (condition)
    foo();
else
    bar(),

baz();

Notice the comma in the bar call. This will actually compile. Why? Because the program is really interpreted as:

if (condition)
{
    foo();
}
else
{
    bar();
    baz();
}

This is, honestly, ridiculous. On most European keyboard layouts, comma is on the same key as semicolon. This means that a typo such as the above can lead to an incorrect (but compiling) program easily, rather than a compile-time error.

I really do not see the value in allowing such syntax in the first place. I've been told that one argument was that generated code might use it, but I have no idea why it would be needed. Furthermore, this operator makes it very hard to introduce Python-style tuples in the language.

Why is this operator still kept around?

- Alex

It could be moved to use either the section character or one of the application-specific unicode points reserved for internal use by whatever an application wants.  This would eliminate confusing typing and, if using this for generated code, the generator can easily reference it by unicode ID when constructing the strings.

On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
> Hi,
>
> Consider this code:
>
> if (condition)
>      foo();
> else
>      bar(),
>
> baz();
>
> Notice the comma in the bar call. This will actually compile. Why?
> Because the program is really interpreted as:
>
> if (condition)
> {
>      foo();
> }
> else
> {
>      bar();
>      baz();
> }
>
> This is, honestly, ridiculous. On most European keyboard layouts, comma
> is on the same key as semicolon. This means that a typo such as the
> above can lead to an incorrect (but compiling) program easily, rather
> than a compile-time error.
>
> I really do not see the value in allowing such syntax in the first
> place. I've been told that one argument was that generated code might
> use it, but I have no idea why it would be needed. Furthermore, this
> operator makes it very hard to introduce Python-style tuples in the
> language.
>
> Why is this operator still kept around?

Take your pick:
1) So that legacy B/C/C++/D1/etc code can be trivially ported to D1/D2.
2) The comma operator is heavily used in regular old for loops.
3) It is frequently used internally by the compiler to effect syntactic lowerings. A decent portion of D's syntax is not transformed directly to instructions; instead it is converted to simpler code which is in turn processed. Technically the compiler doesn't need ',' in the language to do this.
4) D has a policy of 'If C/C++ code compiles in D without error, it must have the same syntactic meaning as in C.' So even if we remove the comma operator, we might not get comma-style tuples. (I don't know if anyone has looked at this issue in depth)
5) The comma and semicolon are on different keys on US style keyboards.
6) It is trivial to change your keyboard layout (I've hotkeyed Greek for fast math symbols)
7) We are trying to stabilize the language, so massive code-breaks are frowned upon.

Personally, I think real tuples outweigh the comma-operator, but real tuples don't necessarily need the ',' (we could use '..' or something else instead) and removing comma-expressions isn't without its problems.

P.S. I was going to suggest testing/looking into issue 4, but a quick test in D suggests that there are valid ',' and '(,)' style expressions in C/C++ that would remain valid in D with comma-tuples.

Alex Rønne Petersen Wrote:
> I really do not see the value in allowing such syntax in the first place. I've been told that one argument was that generated code might use it, but I have no idea why it would be needed.


Aside from the compiler's implementation, one possible use is something I ended up doing in Javascript recently.

I have a thing that takes an attribute and pastes it into a code string to check it.

given validate="this.value.length > 3"

it writes:

if(!(this.value.length > 3))
   return false; // failed validation

since the given string is inside an if statement, you can't put a semicolon in there.


So, if you have a check more complex than returning a boolean
and want to stuff it all in that string (so functions are out), the
comma lets you do it:

validate="do something, true"



This is pretty ugly style that I think I've only ever done in D inside
a for loop... but the point is sometimes something comes up, and
it's nice to have another option available, even if it is ugly.

"Adam Ruppe" <destructionator@gmail.com> wrote in message news:jbo8rr$rhh$1@digitalmars.com...
> Alex Rønne Petersen Wrote:
>> I really do not see the value in allowing such syntax in the first place. I've been told that one argument was that generated code might use it, but I have no idea why it would be needed.
>
>
> Aside from the compiler's implementation, one possible use is something I ended up doing in Javascript recently.
>
> I have a thing that takes an attribute and pastes it into a code string to check it.
>
> given validate="this.value.length > 3"
>
> it writes:
>
> if(!(this.value.length > 3))
>   return false; // failed validation
>
> since the given string is inside an if statement, you can't put a semicolon in there.
>
>
> So, if you have a check more complex than returning a boolean
> and want to stuff it all in that string (so functions are out), the
> comma lets you do it:
>
> validate="do something, true"
>
>
>
> This is pretty ugly style that I think I've only ever done in D inside
> a for loop... but the point is sometimes something comes up, and
> it's nice to have another option available, even if it is ugly.

Don't know about JS, but D can solve the same problem with anon delegates, which is less obscure anyway.

"Robert Jacques" <sandford@jhu.edu> wrote in message news:op.v54q04vd26stm6@sandford.myhome.westell.com...
> On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
>>
>> Why is this operator still kept around?
>
> Take your pick:
> 1) So that legacy B/C/C++/D1/etc code can be trivially ported to D1/D2.

That's a pretty weak counter-argument:

A. I'd think a lot of C/C++ code can't be trivially ported to D anyway.
B. "B", seriously? ;)
C. Being able to link to C/C++ makes it less likely to need to port C/C++
code anyway.
D. Outside of for loops (special-case-able), comma operator is rarely used
in C/C++/D.
E. Even among actual uses of the comma operator, I think it'd be rare (if
even possible) to have a use of it that isn't trivially convertable to
non-comma.

> 2) The comma operator is heavily used in regular old for loops.

That can be special cased.

> 3) It is frequently used internally by the compiler to effect syntactic lowerings. A decent portion of D's syntax is not transformed directly to instructions; instead it is converted to simpler code which is in turn processed. Technically the compiler doesn't need ',' in the language to do this.

Like you're saying, it can exist in the compiler's internal AST without having to exist in the parser.

> 4) D has a policy of 'If C/C++ code compiles in D without error, it must have the same syntactic meaning as in C.' So even if we remove the comma operator, we might not get comma-style tuples. (I don't know if anyone has looked at this issue in depth)

Meh, I still think it would be better to allow such situations on occasion and just provide a "--c-lint" switch to warn (or error) on any such code. Porting C/C++ to D is a much smaller use case than writing/maintaining D. I don't think it's a good idea to hamper the langauge for the sake of such an edge case when it's just as possible to simply handle that scenario with a special tool/switch. But I guess I'm outvoted by Walter on that :(

> 5) The comma and semicolon are on different keys on US style keyboards.
> 6) It is trivial to change your keyboard layout (I've hotkeyed Greek for
> fast math symbols)

Those are very weak counter-arguments.

> 7) We are trying to stabilize the language, so massive code-breaks are frowned upon.
>

Poo ;(

> Personally, I think real tuples outweigh the comma-operator, but real tuples don't necessarily need the ',' (we could use '..' or something else instead) and removing comma-expressions isn't without its problems.
>
> P.S. I was going to suggest testing/looking into issue 4, but a quick test in D suggests that there are valid ',' and '(,)' style expressions in C/C++ that would remain valid in D with comma-tuples.

On 12/07/2011 07:02 PM, Nick Sabalausky wrote:
> "Adam Ruppe"<destructionator@gmail.com>  wrote in message
> news:jbo8rr$rhh$1@digitalmars.com...
>> Alex Rønne Petersen Wrote:
>>> I really do not see the value in allowing such syntax in the first
>>> place. I've been told that one argument was that generated code might
>>> use it, but I have no idea why it would be needed.
>>
>>
>> Aside from the compiler's implementation, one possible use
>> is something I ended up doing in Javascript recently.
>>
>> I have a thing that takes an attribute and pastes it into a code
>> string to check it.
>>
>> given validate="this.value.length>  3"
>>
>> it writes:
>>
>> if(!(this.value.length>  3))
>>    return false; // failed validation
>>
>> since the given string is inside an if statement, you can't put
>> a semicolon in there.
>>
>>
>> So, if you have a check more complex than returning a boolean
>> and want to stuff it all in that string (so functions are out), the
>> comma lets you do it:
>>
>> validate="do something, true"
>>
>>
>>
>> This is pretty ugly style that I think I've only ever done in D inside
>> a for loop... but the point is sometimes something comes up, and
>> it's nice to have another option available, even if it is ugly.
>
> Don't know about JS, but D can solve the same problem with anon delegates,
> which is less obscure anyway.
>
>

I think Don said that DMD cannot currently inline any delegates. Imho the spec should even *require* inlining in the special case that such a delegate is immediately executed. (even for debug builds).

On Wednesday, December 07, 2011 23:10:53 Timon Gehr wrote:
> On 12/07/2011 07:02 PM, Nick Sabalausky wrote:
> > "Adam Ruppe"<destructionator@gmail.com> wrote in message news:jbo8rr$rhh$1@digitalmars.com...
> > 
> >> Alex Rønne Petersen Wrote:
> >>> I really do not see the value in allowing such syntax in the first
> >>> place. I've been told that one argument was that generated code
> >>> might
> >>> use it, but I have no idea why it would be needed.
> >> 
> >> Aside from the compiler's implementation, one possible use is something I ended up doing in Javascript recently.
> >> 
> >> I have a thing that takes an attribute and pastes it into a code string to check it.
> >> 
> >> given validate="this.value.length> 3"
> >> 
> >> it writes:
> >> 
> >> if(!(this.value.length> 3))
> >> 
> >> return false; // failed validation
> >> 
> >> since the given string is inside an if statement, you can't put a semicolon in there.
> >> 
> >> 
> >> So, if you have a check more complex than returning a boolean
> >> and want to stuff it all in that string (so functions are out), the
> >> comma lets you do it:
> >> 
> >> validate="do something, true"
> >> 
> >> 
> >> 
> >> This is pretty ugly style that I think I've only ever done in D inside
> >> a for loop... but the point is sometimes something comes up, and
> >> it's nice to have another option available, even if it is ugly.
> > 
> > Don't know about JS, but D can solve the same problem with anon delegates, which is less obscure anyway.
> 
> I think Don said that DMD cannot currently inline any delegates. Imho the spec should even *require* inlining in the special case that such a delegate is immediately executed. (even for debug builds).

lazy doesn't get inlined for the same reason (since it's essentially using a delegate), and that potentially has some nasty implications for performance with regards to stuff like enforce. In the recent thread on std.regex's performance, while enforce was definitely not at the top of the list of functions in the profiler (listed descending by running time), it was definitely a decent portion of the running time of the program. The cost of enforce should be comparable to the cost of assert, but with the issues of inlining lazy and delegates, it definitely isn't that efficient. These sorts of things need to be inlinable.

- Jonathan M Davis

On Wed, 07 Dec 2011 13:19:31 -0500, Nick Sabalausky <a@a.a> wrote:

> "Robert Jacques" <sandford@jhu.edu> wrote in message
> news:op.v54q04vd26stm6@sandford.myhome.westell.com...
>> On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen
>> <xtzgzorex@gmail.com> wrote:
>>>
>>> Why is this operator still kept around?
>>
>> Take your pick:
>> 1) So that legacy B/C/C++/D1/etc code can be trivially ported to D1/D2.
>
> That's a pretty weak counter-argument:
>
> A. I'd think a lot of C/C++ code can't be trivially ported to D anyway.
That statement implies that there is a lot of code that can be trivially ported to D.

> B. "B", seriously? ;)
Yes, the poster was (in part) asking about where the comma operator came from. C did a lot of stupid things to be portable with B and we have all inherited that legacy.

> C. Being able to link to C/C++ makes it less likely to need to port C/C++
> code anyway.
Sure, for code that's in reasonably complete libraries that full fill your use cases and are supported by someone else. That's not always the case.

> D. Outside of for loops (special-case-able), comma operator is rarely used
> in C/C++/D.
Special casing is a big and dangerous hammer. Generally, it introduces extra work for the compiler and cognitive load for the programmer. Now, we have used special casing to detect common errors to great effect, but these don't add cognitive load to the programmer.

> E. Even among actual uses of the comma operator, I think it'd be rare (if
> even possible) to have a use of it that isn't trivially convertable to
> non-comma.
True, but that still implies extra work on the part of the programmer.

>> 2) The comma operator is heavily used in regular old for loops.
>
> That can be special cased.
Ahem. So are you suggesting that (a,b) means a tuple everywhere but in a for loop, where it is used to separate two statements?

>> 5) The comma and semicolon are on different keys on US style keyboards.
>> 6) It is trivial to change your keyboard layout (I've hotkeyed Greek for
>> fast math symbols)
>
> Those are very weak counter-arguments.
I don't disagree, but the poster's original argument was (essentially) that EU keyboards put ; and , on the same key, so it was easy to mistype between the two. I was just suggesting that maybe the poster might want to fix their keyboard before trying to 'fix' the language.

On 12/07/2011 08:49 AM, Alex Rønne Petersen wrote:
> I really do not see the value in allowing such syntax in the first
> place. I've been told that one argument was that generated code might
> use it, but I have no idea why it would be needed. Furthermore, this
> operator makes it very hard to introduce Python-style tuples in the
> language.

IIRC the generated code argument was actually made with regards to the compiler doing internal rewriting of the AST. If I'm remembering correctly, this make it even weaker as, at that point, there is no reason that the form of the AST need match the syntax.