cslaurie@cybaswan.UUCP (Laurie Moseley ) (06/28/91)
<(* this is an example why even clearly defined scopes can't help < sometimes; better: don't use duplicate variable name as long < as possible *) < <var < x,y : byte; < <procedure Outer; < var < y : byte; < < procedure Inner; (* show a multiplication table *) < begin < for x:=1 to 10 do begin < for y:=1 to y do < write(x*y:5); < writeln; < end; < end; < < begin (* of Outer *) < for y:=1 to 10 do (* 10 linefeeds *) < writeln; < Inner; < end; < <begin (* of why_ten? *) < Outer; <end. < <What you would expect to see on your screen on running this program <would perhaps be ten empty lines and then a multiplication tables <looking somehow like this: < 1 2 3 4 5 6 7 8 9 10 < 2 4 6 ... < 3 6 .. < : < 10 20 30 .. < <Peter Knoerrich, email: prknoerr@faui43.informatik.uni-erlangen.de ------------------------------------------------------------------------- We don't have the data-type <byte> so I tried it with <integer>. This puzzle seems to depend heavily upon non-standard compiler vagaries. Firstly, I am having some difficulty in thinking up situations in which I would wish to write: for y := 1 to y do Secondly one is also relying on the compiler to pick up the value of the loop termination variable (the second y) and storing it separately from the loop control variable (even though they should be identical - they have the same identifier and are within the same scope). Thirdly, I thought that after the execution of a for loop, the value of the loop control variable should be undefined. In that case, the whole thing should fall flat on its face, either with a syntax error, or with some horrible overflow or very long loop (depending on the interpretation of the undefined variable). To my horror, on our Pyramid this is not the case. Most worryingly, the loop control variable is not undefined when the 10 writelns have been output. Secondly, it does treat the loop control <y> and the loop termination <y> as separate identifiers. This means that this code actually runs on our machine. However, it does not produce just one line, it produces the "expected" 10 lines of output. This means that after the termination of the 10 writelns, the value of the for loop control variable must actually still be 10. It is not undefined. I shake my head in sadness. Surely compilers are there to prevent us doing silly things. You can't rely on anything these days ! ========================================================================== Laurie Moseley Computer Science, University College, Swansea SA2 8PP, UK Tel: +44 792 295399 JANET: cslaurie@uk.ac.swan.pyr ========================================================================= "Why does the Turing test set such abysmally low standards ?" ===========================================================================
mailman@telfon.enet.dec.com (Steven M. Mailman) (06/28/91)
In article <2581@cybaswan.UUCP>, cslaurie@cybaswan.UUCP (Laurie Moseley ) writes... >This puzzle seems to depend heavily upon non-standard compiler vagaries. > >Firstly, I am having some difficulty in thinking up situations in >which I would wish to write: > > for y := 1 to y do > >Secondly one is also relying on the compiler to pick up the value of the loop >termination variable (the second y) and storing it separately from >the loop control variable (even though they should be identical - they >have the same identifier and are within the same scope). It *is* depending on the compiler to pick up value and store it in a temporary variable. The Pascal standard specifies that a compiler MUST do this (or behave asif it saved value). Also, it *is* undefined after the loop is done. It may have the value 10 but it is still undefined, i.e. you should not depend on it being 10. With some compilers the value may be 11. The Pascal standard says that it is illegal to even look at that value. ------ Steve Mailman Digital Equipment Corporation mailman@tle.enet.dec.com Disclaimer: The opinions and statements expressed by me are not necessarily those of Digital Equipment Corporation.