• Lionello Lunesu (8/8) Mar 14 2006 I like the fact that we can do
• Jarrett Billingsley (3/7) Mar 14 2006 Vote.
• Kyle Furlong (2/16) Mar 14 2006 Seems an obvious next step, are there any drawbacks that people can thin...
• kellywilson nowhere.com (25/41) Mar 16 2006 PLEASE read the CAVEAT at the end of the post concerning the following r...
• Kyle Furlong (3/59) Mar 16 2006 My point was not that it should be able to support it currently, but tha...
• kellywilson nowhere.com (11/27) Mar 16 2006 I see what you are saying. I simply replied that it was possible to chan...
• Lionello Lunesu (3/15) Mar 17 2006 Nice test, thanks. So with no grammatical conflicts and the added symmet...
• =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= (18/36) Mar 17 2006 Yes, an easy-to-use grammar checker would probably reduce the amount of
• Oskar Linde (8/47) Mar 17 2006 This has been discussed several times, and I believe* most people are if...
• Lionello Lunesu (7/19) May 02 2006 *BUMP*
• Kyle Furlong (2/26) May 02 2006 This needs implementing.
• charles (7/33) May 02 2006 The only reason if ( ) is allowed assignment is for support for RegEx.

"Lionello Lunesu" <lio remove.lunesu.com> writes:

I like the fact that we can do



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



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' 

"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



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



Vote. 

Kyle Furlong <kylefurlong gmail.com> writes:

Lionello Lunesu wrote:
 I like the fact that we can do
 

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

 
 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?

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
 

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

 
 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.

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



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



 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.
 
 
 

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.

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

"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. 

=?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

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.

 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?

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.

Lionello Lunesu <lio lunesu.remove.com> writes:

Lionello Lunesu wrote:
 I like the fact that we can do
 

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

 
 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.

Kyle Furlong <kylefurlong gmail.com> writes:

Lionello Lunesu wrote:
 Lionello Lunesu wrote:
 I like the fact that we can do



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



 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.

"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



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



 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.