John Max Skaller (maxtal@physics.su.OZ.AU) wrote:
: In article <2qtu6s$gdt@iris.mbvlab.wpafb.af.mil> renner@ctis.af.mil writes:
: >   if (X)
: >      if (Y)
: >         Statement_A;
: >      else
: >         Statement_B;

:       Error -- misplaced else. BOTH the if() control only a single
: statement. The else statement is not controlled.

?? My Stroustrup tells me in r.6.4.1 "The else ambiguity is resolved by
connecting an else with the last encountered else-less if.". Do I miss
something here?

:         JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au

--
Heinz Wrobel        Edotronik GmbH: heinz@edohwg.adsp.sub.org
                    Private Mail:   heinz@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email

In article <rfgCpx65K.D4L@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <CprD40.8BI@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>>In article <2qtu6s$gdt@iris.mbvlab.wpafb.af.mil> renner@ctis.af.mil writes:
>>>
>>>---
>>>   if (X)
>>>      if (Y)
>>>         Statement_A;
>>>      else
>>>         Statement_B;
>>
>> Error -- misplaced else. BOTH the if() control only a single
>>statement. The else statement is not controlled.
>
>Sorry John, but you should take at least one class in compiler construction
>(where the classical `dangling else' problem is discussed) before you go
>about making rash statements (like the one above).
>
>> This is clear...
>
>Yes.  It is altogether clear that you don't understand how the C or C++
>grammars work, or about LR parsing, or about resolutions of shift/reduce
>conflicts.
>
>(Sorry to be so harsh, but you really put your foot in it this time.)

 I did, and apologised. Sorry again. I was wrong.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <Cq0Bpy.EL5@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:

> >>>   if (X)
> >>>      if (Y)
> >>>         Statement_A;
> >>>      else
> >>>         Statement_B;


> >(Sorry to be so harsh, but you really put your foot in it this time.)

>  I did, and apologised. Sorry again. I was wrong.

Well, if you read the example carefully, you will see that you are
right -- provided that the strings `Statement_A' and `Statement_B'
are intended to denote statements.

The point is that a statement is usually a self-contained thing
and most statements already end in semicolons.  Thus, for example

 a = 0;

is a statement (assuming that `a' is an object of appropriate type).

If we do the appropriate substitution, then, we get

 if (X)
     if (Y)
  a = 0;;
     else
  b = 0;;

and in this example the `else' truly doesn't pair with anything.
--
    --Andrew Koenig
      ark@research.att.com

In article <DAG.94May17075438@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes:
>>>>>> "R" == Ronald F Guilmette <rfg@netcom.com> writes:
>
>For everybody's enlightment:
>
> Aho, Sethi and Ullman: "Compilers - Principles, Techniques,
>  and Tools," Addison-Wesley, 1986.
>
>Pages 174-175 describe the problem and the solution.

Do you mean:

 "The Dragon Book".


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <CprD40.8BI@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In article <2qtu6s$gdt@iris.mbvlab.wpafb.af.mil> renner@ctis.af.mil writes:
>>
>>---
>>   if (X)
>>      if (Y)
>>         Statement_A;
>>      else
>>         Statement_B;
>
> Error -- misplaced else. BOTH the if() control only a single
>statement. The else statement is not controlled.

Sorry John, but you should take at least one class in compiler construction
(where the classical `dangling else' problem is discussed) before you go
about making rash statements (like the one above).

> This is clear...

Yes.  It is altogether clear that you don't understand how the C or C++
grammars work, or about LR parsing, or about resolutions of shift/reduce
conflicts.

(Sorry to be so harsh, but you really put your foot in it this time.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

>>>>> "R" == Ronald F Guilmette <rfg@netcom.com> writes:

R> Sorry John, but you should take at least one class in compiler
R> construction (where the classical `dangling else' problem is
R> discussed) before you go about making rash statements (like the one
R> above).

For everybody's enlightment:

 Aho, Sethi and Ullman: "Compilers - Principles, Techniques,
  and Tools," Addison-Wesley, 1986.

Pages 174-175 describe the problem and the solution.

    -- Dag

---

If you have the statments below is Statement_A in the same
scope as Statement_B?  Is Statement_C in the same scope as
Statement_A.  I have compiled this on a couple of different
compilers with the Statments being for loops, i.e.
for(int i = 0; i < 10; i++).  Some of the compilers accept
the code, others raise an error saying that that i is being
redefined.

   if (X)
      if (Y)
         Statement_A;
      else
         Statement_B;
   else
      if (Z)
         Statement_C;
      else
         Statement_D;

Thanks,


------------------------------------------------------------
Ray Renner                      11th ACW/OC
GTE Government Systems          6900 9th St., Suite 301
Ph. (907)552-3358               Elmendorf AFB, AK 99506
Fax.(907)552-1120               email - renner@ctis.af.mil

In article <2qtu6s$gdt@iris.mbvlab.wpafb.af.mil> renner@ctis.af.mil writes:
>
>---
>   if (X)
>      if (Y)
>         Statement_A;
>      else
>         Statement_B;

 Error -- misplaced else. BOTH the if() control only a single
statement. The else statement is not controlled.

 This is clear. But the Working Paper, although clear,
is probably wrong in its description. Try this:

 if(1)int x;
 int x; // different x

 This is legal at present due to the 'rewriting' rule :

 if(1) { int x; }
 int x;

Now, if you think that is fine, you are wrong. Try this:

 if(int x)int x;

Now, the WP says some incomprehensible stuff about not being
allowed to redefine the control variable 'in the outer
most block' of the controlled statement. Try this:

 if(int x){int x;}

If you think this is illegal because of the above rule, you are
wrong. Because the rule is mentioned after, and applies after,
the rewriting occurs:

 if(int x){{int x;}}

and now 'x' is no longer in the outermost block.
If you think the rule should be applied FIRST, before rewriting,
then

 if(int x) int x;

cannot be illegal because the controlled statement is not a block.
So which every way you read it, it doesnt say what you thought it
should.

The fault is easily rectified by changing the grammar slightly.

[But IMHO it is unlikely it will be rectified.]

Of course, I could be wrong that this is a fault. Maybe:

 if(int x){int x; }

is intended to be legal. Should it be?
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

renner@ctis.af.mil (Ray Renner) writes:

>If you have the statments below is Statement_A in the same
>scope as Statement_B?

No.

>Is Statement_C in the same scope as
>Statement_A.

No.  See ARM Chapter 19 (ANSI/ISO Resolutions), sections 6.4/6.5.
(But make sure that your ARM is dated >= 1992 or thereabouts -
this was not in the original ARM.)

>   if (X)
>      if (Y)
>         Statement_A;
>      else
>         Statement_B;
>   else
>      if (Z)
>         Statement_C;
>      else
>         Statement_D;

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>renner@ctis.af.mil writes:
>>
>>---
>>   if (X)
>>      if (Y)
>>         Statement_A;
>>      else
>>         Statement_B;
>
> Error -- misplaced else. BOTH the if() control only a single
>statement. The else statement is not controlled.

No, that is not an error.  ARM 6.4.1: "The else ambiguity is resolved
by connecting an `else' with the last encountered `else'-less `if'."

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <9413602.4539@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>>renner@ctis.af.mil writes:
>>>
>>>---
>>>   if (X)
>>>      if (Y)
>>>         Statement_A;
>>>      else
>>>         Statement_B;
>>
>> Error -- misplaced else. BOTH the if() control only a single
>>statement. The else statement is not controlled.
>
>No, that is not an error.  ARM 6.4.1: "The else ambiguity is resolved
>by connecting an `else' with the last encountered `else'-less `if'."

 My apologies.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA