www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [grammar] ambiguity on parenthized clauses

reply Manfred Nowak <svv1999 hotmail.com> writes:
The `debug' and `synchronized' statements both have the options to 
be followed immediately by a statement
  `synchronized stmt'
or have a parenthesed item between the keyword and the statement
  `synchronized( expr ) stmt'.

Because a statement can derive to an expression statement 
consisting of an expression that starts with a left parenthesis 
  `(*(new int))* *y;'
there is an ambiguity introduced if such a statement is turned into 
a `synchronized' statement
  `synchronized (*(new int))* *y;'

In fact the current dmd resolves this ambiguity in favor of
  `synchronized( expr ) stmt'
by implementing the rules
  `synchronized stmtThatDoesNotStartWithLeftParenthesis'
  `synchronized ( expr ) stmt'

So there are at least three choices:

1. Holding up the status quo, which means that some statements are 
not synchronizable
2. Requiring an empty pair of parenthesis between the keyword and 
the statement
   `synchronized ( ) stmt'
   `synchronized ( expr ) stmt'
3. Changing the parentheses to something else
   `synchronized stmt'
   `synchronized !( expr ) stmt'

Similar arguments hold for the debug statement.

-manfred
Apr 28 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:d4qdg2$eij$1 digitaldaemon.com...
 The `debug' and `synchronized' statements both have the options to
 be followed immediately by a statement
   `synchronized stmt'
 or have a parenthesed item between the keyword and the statement
   `synchronized( expr ) stmt'.

 Because a statement can derive to an expression statement
 consisting of an expression that starts with a left parenthesis
   `(*(new int))* *y;'
 there is an ambiguity introduced if such a statement is turned into
 a `synchronized' statement
   `synchronized (*(new int))* *y;'

 In fact the current dmd resolves this ambiguity in favor of
   `synchronized( expr ) stmt'
 by implementing the rules
   `synchronized stmtThatDoesNotStartWithLeftParenthesis'
   `synchronized ( expr ) stmt'

 So there are at least three choices:

 1. Holding up the status quo, which means that some statements are
 not synchronizable

I agree it is ambiguous, but statements that start with ( are generally contrived as the () are redundant. The example you gave can also be written as: *(new int) * *y; with no change in meaning. So option (1) works.
Apr 28 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
"Walter" <newshound digitalmars.com> wrote:

[...]
 statements that start with ( are generally contrived as the ()
 are redundant.

May I remind on the fact that the evaluation order of expressions in general is not specified. Therefore one might very well be forced to introduce parentheses. And I do not think, that in `( a + b) * c' the parentheses are truly redundandent.
 The example you gave can also be written as:
     *(new int) * *y;
 with no change in meaning. So option (1) works.

Agreed, if there are no overloads. One can always rewrite the statement by turning it into a blockstatement. However, the drawnback of option (1) is, that forgetting the need to rewrite may introduce subtle errors. Again the probability is extremely low because the contents of the clauses must meet semantic constraints. However, is this suitable for a language which' design goal is to shield the programmer from unnecessary bugs? -manfred
Apr 28 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:d4rfg7$1lme$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote:
 statements that start with ( are generally contrived as the ()
 are redundant.

general is not specified. Therefore one might very well be forced to introduce parentheses. And I do not think, that in `( a + b) * c' the parentheses are truly redundandent.

Correct, they aren't redundant in that case, but the expression also has no effect and so one would not see: debug (a + b) * c; Furthermore, the argument to debug must be either an identifier or an integer literal. Anything else will give a syntax error. The argument to synchronize must resolve to an object reference. Add these up, and the chances are remote that there'd be any confusion not caught at compile time.
Apr 28 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
"Walter" <newshound digitalmars.com> wrote:

[...]
 Correct, they aren't redundant in that case, but the expression
 also has no effect and so one would not see:
 
     debug (a + b) * c;

ICNR. <code> import std.stdio; class Int{ Int opAdd(Int p){ writef("Paradise"); return new Int; } void opAdd(Object* P){ writefln("Forget what I just wrote!"); } Object* opMul(Object* p){ writefln(" turned into hell. Red alert!"); return null;} } void main(){ Int x=new Int,y=new Int; Object o; Object* z= &o; synchronized (x + y) * z; } </code> [...]
 Add these up, and the chances are remote that there'd be any
 confusion not caught at compile time. 

Agreed. But it really took not much time to construct the example above. -manfred
Apr 29 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Manfred Nowak wrote:
<snip>
 1. Holding up the status quo, which means that some statements are 
 not synchronizable

What is there to stop you from doing synchronized { (*(new int))* *y; } ? Besides that this code would be a complete nop? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Apr 29 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Stewart Gordon <smjg_1998 yahoo.com> wrote:

 What is there to stop you from doing
 
      synchronized { (*(new int))* *y; }
 
 ?  Besides that this code would be a complete nop?

Thanks for the confirmation of my posting digitalmars.D.bugs/3836 where I already mentioned the possibility to wrap each statement by a blockstatement. However, have a look at our own docs: <cite href="http://www.digitalmars.com/d/expression.html#NewExpression"> There is an ambiguity in the grammar, however. Consider: (foo) - p; Is this a cast of a dereference of negated p to type foo, or is it p being subtracted from foo? </cite> Do you agree that the fact that there _is_ an ambiguity can serve as an argument against a language? And both of your arguments hold here too: 1. The statement _can_ be rewritten as (foo / 1) - p to make clear that a cast is not wanted. 2. This staement in C is doubtless a NOOP in both possible interpretations. However in D this might be an OP because the operators are overloadable and therefore may have side effects. Can you prove, that this argument does not hold?
Apr 29 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Manfred Nowak wrote:
<snip>
 However, have a look at our own docs:
 
 <cite 
 href="http://www.digitalmars.com/d/expression.html#NewExpression">
 
 There is an ambiguity in the grammar, however. Consider: 
 		(foo) - p;
 	
 Is this a cast of a dereference of negated p to type foo, or is it 
 p being subtracted from foo?
 </cite>

If you had bothered to read what you just quoted, you would've noticed that it's talking about C(++) there. And that this isn't part of the NewExpression section.
 Do you agree that the fact that there _is_ an ambiguity can serve 
 as an argument against a language?
 
 And both of your arguments hold here too:
 1. The statement _can_ be rewritten as 
            (foo / 1) - p
 to make clear that a cast is not wanted.

This has been completely unnecessary since DMD 0.119. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
May 03 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Stewart Gordon <smjg_1998 yahoo.com> wrote:

[...]
 If you had bothered to read

Hey, Stewart. We are now getting into troubles because the limitations of this medium! I know very well, that the example referenced is talking on C(++). All I wanted to say is, that Walter himself uses the pure existence of an ambiguity in C(++) as an argument against C(++). So, if he is not too self contained, after the above he also _must_ use the pure existence of an ambiguity in D as an argument against D. Once more: all I want to express is that by prepending the synchronized keyword before a statement nobody would expect that the semantic of that statement may change. That is the same thing as with the preepnding of a cast: a cast is also not expected to change the semantic value of the expression casted. So if D prevents the programmer from unforseeable bugs by introducing a syntactical element for casts, the kywaord `cast', to eliminate this ambiguity, it is reasonable to prevent every programmer from this ambiguity introduced by the specs of D itself also. As a fourth possibilty I would reclaim, that the synchronized keyword must be followed by a blockstatement directly or after the parenthized clause. -manfred
May 03 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Manfred Nowak wrote:
<snip>
 I know very well, that the example referenced is talking on C(++).
 
 All I wanted to say is, that Walter himself uses the pure existence 
 of an ambiguity in C(++) as an argument against C(++).

Yes. In as far as it's a weakness of these languages, but I wouldn't consider it as telling anyone "don't use C(++)".
 So, if he is not too self contained, after the above he also _must_ 
 use the pure existence of an ambiguity in D as an argument against 
 D.

Some people do admit that their creations aren't perfect. And since this particular imperfection doesn't exist in current D, this section doesn't have to influence when/where Walter admits it. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
May 03 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Stewart Gordon <smjg_1998 yahoo.com> wrote:

[...]
 And since this particular imperfection doesn't exist in current D,
 this section doesn't have to influence when/where Walter admits
 it. 

I'm giving up. I am not talking of the cast ambiguity of C(++) is existing in D, but an ambiguity on the synchronized/debug statement. But now it seems hopeless to me, that only a gloom of understanding will enlighten your horizont. Thanks for your patience. -manfred
May 03 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 4 May 2005 00:19:33 +0000 (UTC), Manfred Nowak wrote:

 Stewart Gordon <smjg_1998 yahoo.com> wrote:
 
 [...]
 And since this particular imperfection doesn't exist in current D,
 this section doesn't have to influence when/where Walter admits
 it. 

I'm giving up. I am not talking of the cast ambiguity of C(++) is existing in D, but an ambiguity on the synchronized/debug statement. But now it seems hopeless to me, that only a gloom of understanding will enlighten your horizont. Thanks for your patience.

If it helps, Manfred, I understood your concerns. And your proposed solutions were reasonable too. There does exist an ambiguity in the language. With the 'debug', as Walter points out, it probably doesn't matter because bad expressions could be caught at compile time. With the synchronized statement, as you point out, ambiguities can be resolved by placing the 'target' statement inside braces. So in the end, I guess it would not be a high priority need to address these ambiguities prior to v1.0 -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build/ v2.05 released 02/May/2005 http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage 4/05/2005 10:36:58 AM
May 03 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Derek Parnell wrote:
 On Wed, 4 May 2005 00:19:33 +0000 (UTC), Manfred Nowak wrote:

I'm giving up. I am not talking of the cast ambiguity of C(++) is 
existing in D, but an ambiguity on the synchronized/debug statement.


Sorry if I misunderstood. We must have been talking at cross purposes from the moment the C(++) cast ambiguity was mentioned on the thread.
But now it seems hopeless to me, that only a gloom of understanding 
will enlighten your horizont.

Thanks for your patience.

If it helps, Manfred, I understood your concerns. And your proposed solutions were reasonable too. There does exist an ambiguity in the language. With the 'debug', as Walter points out, it probably doesn't matter because bad expressions could be caught at compile time.

I suppose it's OK for some ambiguities to be resolved by "if it's parseable as X, it's X, otherwise it's Y" rules. In these cases, X would be synchronized ( Expression ) Statement debug ( IntegerLiteral ) Statement debug ( Identifier ) Statement which would make synchronized (qwert) - yuiop; equivalent to synchronized (qwert) { -yuiop; } but synchronized (qwert) / yuiop; equivalent to synchronized { (qwert) / yuiop; } Is this how DMD behaves at the moment? Or does it simply fail once it's tried to parse / yuiop; as a statement?
 With the synchronized statement, as you point out, ambiguities can be resolved
by
 placing the 'target' statement inside braces. So in the end, I guess it
 would not be a high priority need to address these ambiguities prior to
 v1.0

I still consider this case worth doing something about: digitalmars.D.bugs/1955 (see followups for how it could be resolved) Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
May 04 2005