View mode: basic / threaded / horizontal-split · Log in · Help
December 07, 2011
Comma operator = broken design
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
December 07, 2011
Comma operator = broken design
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.
December 07, 2011
Re: Comma operator = broken design
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.
December 07, 2011
Re: Comma operator = broken design
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.
December 07, 2011
Re: Comma operator = broken design
"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.
December 07, 2011
Re: Comma operator = broken design
"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.
December 07, 2011
Re: Comma operator = broken design
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).
December 08, 2011
Re: Comma operator = broken design
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
December 08, 2011
Re: Comma operator = broken design
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.
December 08, 2011
Re: Comma operator = broken design
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home