www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - if (int x=..) but no while(int x=..) ?

reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
I like the fact that we can do

# if (int recvd = ts.receive(buffer)) {...}

but is there any reason why this shouldn't apply to "while" also?

# while (int recvd = ts.receive(buffer)) {...}

main.d(26): found 'recvd' when expecting '.' following 'int'
main.d(26): found '=' when expecting identifier following 'int.'
main.d(26): found 'ts' when expecting ')'
main.d(26): found ')' when expecting ';' following 'statement' 
Mar 14 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lionello Lunesu" <lio remove.lunesu.com> wrote in message 
news:dv5vgr$2eh0$1 digitaldaemon.com...
I like the fact that we can do

 # if (int recvd = ts.receive(buffer)) {...}

 but is there any reason why this shouldn't apply to "while" also?

 # while (int recvd = ts.receive(buffer)) {...}

Vote.
Mar 14 2006
prev sibling next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Lionello Lunesu wrote:
 I like the fact that we can do
 
 # if (int recvd = ts.receive(buffer)) {...}
 
 but is there any reason why this shouldn't apply to "while" also?
 
 # while (int recvd = ts.receive(buffer)) {...}
 
 main.d(26): found 'recvd' when expecting '.' following 'int'
 main.d(26): found '=' when expecting identifier following 'int.'
 main.d(26): found 'ts' when expecting ')'
 main.d(26): found ')' when expecting ';' following 'statement' 
 
 

Seems an obvious next step, are there any drawbacks that people can think of?
Mar 14 2006
parent reply kellywilson nowhere.com writes:
Hey Kyle and Lionello,

In article <dv8b3l$2109$4 digitaldaemon.com>, Kyle Furlong says...
Lionello Lunesu wrote:
 I like the fact that we can do
 
 # if (int recvd = ts.receive(buffer)) {...}
 
 but is there any reason why this shouldn't apply to "while" also?
 
 # while (int recvd = ts.receive(buffer)) {...}
 
 main.d(26): found 'recvd' when expecting '.' following 'int'
 main.d(26): found '=' when expecting identifier following 'int.'
 main.d(26): found 'ts' when expecting ')'
 main.d(26): found ')' when expecting ';' following 'statement' 
 
 

Seems an obvious next step, are there any drawbacks that people can think of?

PLEASE read the CAVEAT at the end of the post concerning the following rule! The grammar for D does not allow a "Declarator = Expression" inside the braces of a while statement. The "IfCondition" rule does allow this for the if statements, however. Now, can the grammar be modified to accept the "Declarator = Expression" rule? Yes, I just modified my grammar and it works without conflicts. As for any deeper questions about the validity/usability/maintainability of this...well that is for Walter to decide, I guess. By the way: Each of the "IfStatement"/"WhileStatement"/"DoStatement" rules are explained with the following in the documentation: "Expression is evaluated and must have a type that can be converted to a boolean." This would seem to indicate that each of these constructs can use the "Declarator = Expression" rule I mentioned above. Thanks, Kelly Wilson CAVEAT:::: The rule "Declarator = Expression" should ACTUALLY read "Basic_Type Declarator = Expression". The dmd frontend (version 0.149) uses this rule instead of the rule I keep quoting above....I just didn't want to confuse anyone following along in the documentation online. I also use the "Basic_Type...." rule as the Basic_Type is needed before Declarator.
Mar 16 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
kellywilson nowhere.com wrote:
 Hey Kyle and Lionello,
 
 In article <dv8b3l$2109$4 digitaldaemon.com>, Kyle Furlong says...
 Lionello Lunesu wrote:
 I like the fact that we can do

 # if (int recvd = ts.receive(buffer)) {...}

 but is there any reason why this shouldn't apply to "while" also?

 # while (int recvd = ts.receive(buffer)) {...}

 main.d(26): found 'recvd' when expecting '.' following 'int'
 main.d(26): found '=' when expecting identifier following 'int.'
 main.d(26): found 'ts' when expecting ')'
 main.d(26): found ')' when expecting ';' following 'statement' 


PLEASE read the CAVEAT at the end of the post concerning the following rule! The grammar for D does not allow a "Declarator = Expression" inside the braces of a while statement. The "IfCondition" rule does allow this for the if statements, however. Now, can the grammar be modified to accept the "Declarator = Expression" rule? Yes, I just modified my grammar and it works without conflicts. As for any deeper questions about the validity/usability/maintainability of this...well that is for Walter to decide, I guess. By the way: Each of the "IfStatement"/"WhileStatement"/"DoStatement" rules are explained with the following in the documentation: "Expression is evaluated and must have a type that can be converted to a boolean." This would seem to indicate that each of these constructs can use the "Declarator = Expression" rule I mentioned above. Thanks, Kelly Wilson CAVEAT:::: The rule "Declarator = Expression" should ACTUALLY read "Basic_Type Declarator = Expression". The dmd frontend (version 0.149) uses this rule instead of the rule I keep quoting above....I just didn't want to confuse anyone following along in the documentation online. I also use the "Basic_Type...." rule as the Basic_Type is needed before Declarator.

My point was not that it should be able to support it currently, but that it would be symmetric to support it in a while statement as well.
Mar 16 2006
parent kellywilson nowhere.com writes:
Hey Kyle,


In article <dvctqg$269v$1 digitaldaemon.com>, Kyle Furlong says...
My point was not that it should be able to support it currently, but that it
would be symmetric to support it in a while 
statement as well.

I see what you are saying. I simply replied that it was possible to change the grammar at this point and that I had a concern about the validity/usability/maintainability.
 "Declarator = Expression" rule? Yes, I just modified my grammar and it works
 without conflicts. As for any deeper questions about the
 validity/usability/maintainability of this...well that is for Walter to decide,
 I guess.


I was also pointing out that Ithink that the Do/While/If constructs could and/or should be symmetric below.
 By the way:
 
 Each of the "IfStatement"/"WhileStatement"/"DoStatement" rules are explained
 with the following in the documentation:
 
 "Expression is evaluated and must have a type that can be converted to a
 boolean."
 
 This would seem to indicate that each of these constructs can use the
 "Declarator = Expression" rule I mentioned above.


As for the rest...I was just being a little verbose and pointing out that the grammar is lagging behind the actual parser in this case ;) Thanks, Kelly Wilson
Mar 16 2006
prev sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
 The grammar for D does not allow a

 "Declarator = Expression"

 inside the braces of a while statement. The "IfCondition" rule does allow 
 this
 for the if statements, however. Now, can the grammar be modified to accept 
 the
 "Declarator = Expression" rule? Yes, I just modified my grammar and it 
 works
 without conflicts. As for any deeper questions about the
 validity/usability/maintainability of this...well that is for Walter to 
 decide,
 I guess.

Nice test, thanks. So with no grammatical conflicts and the added symmetry, it should be easy to get Walter's backing on this : ) Lionello.
Mar 17 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Lionello Lunesu wrote:
 The grammar for D does not allow a

 "Declarator = Expression"

 inside the braces of a while statement. The "IfCondition" rule does allow 
 this
 for the if statements, however. Now, can the grammar be modified to accept 
 the
 "Declarator = Expression" rule? Yes, I just modified my grammar and it 
 works
 without conflicts. As for any deeper questions about the
 validity/usability/maintainability of this...well that is for Walter to 
 decide,
 I guess.

Nice test, thanks. So with no grammatical conflicts and the added symmetry, it should be easy to get Walter's backing on this : )

Yes, an easy-to-use grammar checker would probably reduce the amount of totally pointless syntax proposals. One other thing I don't understand is the "Expression -> Expression | AssignExpression , Expression" -rule. C++ seems to support this, but Java doesn't. The comma-operator is mostly used inside the if -->(...)<-- {} -part of if/while -loops. There can be a lot of uses for commas inside other statements, e.g. multidimensional arrays: int[][] a a.length = 4,5; or return 1,2,3; Currently these operations don't work as expected, thus causing code obfuscation. I'm not saying these examples are well designed, but I cannot see why we should prevent potential future extensions. What do you think? -- Jari-Matti
Mar 17 2006
parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Jari-Matti Mäkelä wrote:
 Lionello Lunesu wrote:
 The grammar for D does not allow a

 "Declarator = Expression"

 inside the braces of a while statement. The "IfCondition" rule does allow 
 this
 for the if statements, however. Now, can the grammar be modified to accept 
 the
 "Declarator = Expression" rule? Yes, I just modified my grammar and it 
 works
 without conflicts. As for any deeper questions about the
 validity/usability/maintainability of this...well that is for Walter to 
 decide,
 I guess.

it should be easy to get Walter's backing on this : )

Yes, an easy-to-use grammar checker would probably reduce the amount of totally pointless syntax proposals. One other thing I don't understand is the "Expression -> Expression | AssignExpression , Expression" -rule. C++ seems to support this, but Java doesn't. The comma-operator is mostly used inside the if -->(...)<-- {} -part of if/while -loops. There can be a lot of uses for commas inside other statements, e.g. multidimensional arrays: int[][] a a.length = 4,5; or return 1,2,3; Currently these operations don't work as expected, thus causing code obfuscation. I'm not saying these examples are well designed, but I cannot see why we should prevent potential future extensions. What do you think?

This has been discussed several times, and I believe* most people are if favor of depreciating and removing the , operator in preparation for a future tuple syntax. With foreach, he for-syntax is much less common in D code than in C code. Perhaps , in the for syntax should be made a special case, as it is in Java. /Oskar *) based on responses to previous occurrences of the same suggestion.
Mar 17 2006
prev sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Lionello Lunesu wrote:
 I like the fact that we can do
 
 # if (int recvd = ts.receive(buffer)) {...}
 
 but is there any reason why this shouldn't apply to "while" also?
 
 # while (int recvd = ts.receive(buffer)) {...}
 
 main.d(26): found 'recvd' when expecting '.' following 'int'
 main.d(26): found '=' when expecting identifier following 'int.'
 main.d(26): found 'ts' when expecting ')'
 main.d(26): found ')' when expecting ';' following 'statement' 

*BUMP* What's the status on this issue? Is there any reason why the syntax of "while" is different from the syntax of "if" ? According to tests done by Kelly Wilson it's trivial to support. Sorry for the bump, but this seems like a forgotten issue. L.
May 02 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Lionello Lunesu wrote:
 Lionello Lunesu wrote:
 I like the fact that we can do

 # if (int recvd = ts.receive(buffer)) {...}

 but is there any reason why this shouldn't apply to "while" also?

 # while (int recvd = ts.receive(buffer)) {...}

 main.d(26): found 'recvd' when expecting '.' following 'int'
 main.d(26): found '=' when expecting identifier following 'int.'
 main.d(26): found 'ts' when expecting ')'
 main.d(26): found ')' when expecting ';' following 'statement' 

*BUMP* What's the status on this issue? Is there any reason why the syntax of "while" is different from the syntax of "if" ? According to tests done by Kelly Wilson it's trivial to support. Sorry for the bump, but this seems like a forgotten issue. L.

This needs implementing.
May 02 2006
parent "charles" <admin tdjonline.com> writes:
The only reason if ( ) is allowed assignment is for support for RegEx.

Hmm after some tests assignment is only allowed if there is a declared type
in their also, so the '=  / ==' bug is no longer a concern, I vote we add
it.

Charlie

"Kyle Furlong" <kylefurlong gmail.com> wrote in message
news:e378qo$2n1c$1 digitaldaemon.com...
 Lionello Lunesu wrote:
 Lionello Lunesu wrote:
 I like the fact that we can do

 # if (int recvd = ts.receive(buffer)) {...}

 but is there any reason why this shouldn't apply to "while" also?

 # while (int recvd = ts.receive(buffer)) {...}

 main.d(26): found 'recvd' when expecting '.' following 'int'
 main.d(26): found '=' when expecting identifier following 'int.'
 main.d(26): found 'ts' when expecting ')'
 main.d(26): found ')' when expecting ';' following 'statement'

*BUMP* What's the status on this issue? Is there any reason why the syntax of "while" is different from the syntax of "if" ? According to tests done by Kelly Wilson it's trivial to support. Sorry for the bump, but this seems like a forgotten issue. L.

This needs implementing.

May 02 2006