Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!caen!spool.mu.edu!uunet!mcsun!ukc!cf-cm!cybaswan!cslaurie
From: cslaurie@cybaswan.UUCP (Laurie Moseley )
Newsgroups: comp.lang.pascal
Subject: Pascal Puzzle: what is a standard compiler
Keywords: Scope, Loop control variables
Message-ID: <2581@cybaswan.UUCP>
Date: 27 Jun 91 20:21:42 GMT
Lines: 87

<(* 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 ?"
===========================================================================