[comp.lang.pascal] Pascal Puzzle: what is a standard compiler

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.