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'

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

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?

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.

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

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

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

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

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