scl@virginia.acc.virginia.edu (Steve Losen) (03/30/88)
The following pascal program compiles and outputs "10" with the Berkeley
pascal compiler "pc".
program test(output);
const c = 10;
procedure junk;
const c = c; { Shouldn't this be an error ? }
begin
writeln(c)
end;
begin
junk
end.
According the the ISO pascal standard:
"The occurrence of an identifier in a constant-definition of a
constant-definition-part of a block shall constitute its defining-point
for the region that is the block. The constant in a constant-definition
shall not contain an applied occurrence of the identifier in the
constant-definition."
constant-definition-part = [ "const" constant-definition ";"
{ constant-definition ";" } ] .
constant-definition = identifier "=" constant .
constant = [ sign ] ( unsigned-number | constant-identifier ) |
character-string .
constant-identifier = identifier .
As far as I can tell, then, the pascal fragment
const c = c;
should not be allowed even if c is a constant defined in an enclosing
block. Is my interpretation of the pascal standard correct? Since I'm
writing a pascal compiler, I need to have this issue cleared up.
A further note:
The Berkeley pascal compiler also accepts fragments like this:
type thing = array [1..10] of thing; { where "thing" is a type defined
in an enclosing block }
This also appears to be illegal according to the ISO pascal standard.
Does anyone out there agree/disagree/care?
--
Steve Losen scl@virginia.edu
University of Virginia Academic Computing Centerdjones@megatest.UUCP (Dave Jones) (03/31/88)
in article <718@virginia.acc.virginia.edu), scl@virginia.acc.virginia.edu (Steve Losen) says:
)
) The following pascal program compiles and outputs "10" with the Berkeley
) pascal compiler "pc".
)
) program test(output);
) const c = 10;
)
) procedure junk;
) const c = c; { Shouldn't this be an error ? } [Yep.]
^ applied occurance
^ defining point
) begin
) writeln(c)
) end;
)
) begin
) junk
) end.
)
) According the the ISO pascal standard:
)
Yep. That is an error. It is, as you pointed out, an applied occurance
of c is before the defining point.
-- Dave J.R_Tim_Coslet@cup.portal.com (03/31/88)
Steve Losen scl@virginia.edu University of Virginia Academic Computing Center Writes: >The following pascal program compiles and outputs "10" with the Berkeley >pascal compiler "pc". [.... deleted text ....] >As far as I can tell, then, the pascal fragment > >const c = c; > >should not be allowed even if c is a constant defined in an enclosing >block. Is my interpretation of the pascal standard correct? Since I'm >writing a pascal compiler, I need to have this issue cleared up. > >A further note: > > The Berkeley pascal compiler also accepts fragments like this: > >type thing = array [1..10] of thing; { where "thing" is a type defined > in an enclosing block } > >This also appears to be illegal according to the ISO pascal standard. > >Does anyone out there agree/disagree/care? I definitely agree that the above examples are potentially ambigious... I tend to agree with your interpretation of the ISO standard... However I don't know as it makes alot of difference, as such code does not seem to have any useful purpose (perhaps you could suggest one). When compiled by a compiler meeting the ISO standard as you have discribed it, the compiler should probably flag such lines as: Error - Self Referential Declaration, unable to determine value. Hmm... interesting idea: Self Referential Declarations... :-)
douglas@reed.UUCP (P Douglas Reeder) (04/01/88)
In article <718@virginia.acc.virginia.edu> scl@virginia.acc.virginia.edu (Steve Losen) writes: >The following pascal program compiles and outputs "10" with the Berkeley >pascal compiler "pc". > >program test(output); > const c = 10; > >procedure junk; > const c = c; { Shouldn't this be an error ? } >[rest of program deleted] > >As far as I can tell, then, the pascal fragment > >const c = c; > >should not be allowed even if c is a constant defined in an enclosing >block. Is my interpretation of the pascal standard correct? Since I'm >writing a pascal compiler, I need to have this issue cleared up. > >-- >Steve Losen scl@virginia.edu >University of Virginia Academic Computing Center In the line const c = c; the reference to c on the right refers to the previously defined constant c and the reference on the left refers to the newly defined constant c. In procedure junk, before this statement (that is, in previous constant declarations), c refererred to the first c. After, c refers to the local c. In some sense, the right side of the statement is compiled before the left hand side. The following code does exactly the same thing, using slightly different names: program test(output); const c1 = 10; procedure junk; const c2 = c1; [rest of program ] The same thing happens with your second example [not shown]. My book does not make clear if this is ISO standard. Either way, its meaning is unambiguous. -- Doug Reeder USENET: ...!tektronix!reed!douglas 10 Cyclopedia Square from BITNET: douglas@reed.UUCP Terminus City from ARPA: !tektronix!reed!douglas@Berkley Terminus,The Foundation Box 502 Reed College,Portland,OR 97202
shankar@hpclscu.HP.COM (Shankar Unni) (04/01/88)
/ hpclscu:comp.lang.pascal / (Steve Losen) / 11:40 am Mar 29, 1988 / > program test(output); > const c = 10; > > procedure junk; > const c = c; { Shouldn't this be an error ? } > begin > writeln(c) > end; This is simply a case of the general class of scoping violations that should be detected by a conforming implementation (redefining an inherited item after using it). Consider: program foo; type blah = <...>; procedure bar; type blahptr = ^blah; (* quick, which blah does this point to? *) blah = <...>; Shankar. (Obviously, the berkeley pc does not conform to the standard. Of course, *nothing* that Berkeley does conforms to standards :-) whirrr... (shields up, captain) ) --scu