Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!pt!zog.cs.cmu.edu!tgl
From: tgl@zog.cs.cmu.edu (Tom Lane)
Newsgroups: comp.lang.pascal
Subject: Re: Pointer problem ?  (once again)
Message-ID: <1033@zog.cs.cmu.edu>
Date: Thu, 30-Jul-87 20:55:24 EDT
Article-I.D.: zog.1033
Posted: Thu Jul 30 20:55:24 1987
Date-Received: Sat, 1-Aug-87 11:30:16 EDT
References: <254@askja.UUCP> <4020004@nucsrl.UUCP> <3529@ihlpg.ATT.COM>
Reply-To: tgl@zog.cs.cmu.edu (Tom Lane)
Distribution: world
Organization: Carnegie-Mellon University, CS/RI
Lines: 70
Keywords: pointers Pascal standards

The people who knew what they were talking about on this subject haven't
made themselves very clear, so I'll have a go at it.  Hit 'n' if you're
bored...

The issue here is whether two Pascal types are assignment compatible.
There are two different rules for determining compatibility, called "name
equivalence" and "structure equivalence".  In the original example (which
was simplified to the point of uselessness), we had:

	type 
	  p1 = ^p1;
	  p2 = ^p1;
	  p3 = ^p2;

Under the "structure equivalence" rule, type p2 is "the same as" p1,
because both are pointers to the same thing.  Then by induction, p3 is
also "the same as" p1.

Under "name equivalence", all three types are distinct.  You can only
get equivalence of two types under this rule by saying
	type p2 = p1;
i.e. only by equating the second type to the name of the first.

Hence the example program compiles under structure equivalence and is
rejected under name equivalence; there's no compiler bug involved.

There are some exceptions dealing with subranges and real-to-integer
conversion, but that's the basic idea.

Now, why have you got one compiler that enforces name equivalence and one
that enforces structure equivalence?  Basically, because Wirth screwed up.
His Revised Report on Pascal was a bit vague, but SPECIFIED name
equivalence.  (I think... it depends on what you assume "identical type"
means.)  But Wirth's original, widely distributed Portable P-compiler
IMPLEMENTED structure equivalence.  Nearly all its descendants, including
UCSD Pascal, Turbo Pascal, and most flavors of Pascal for the Macintosh,
still contain that code.  Various other people wrote compilers from scratch,
following the Report.  Most of them implemented name equivalence; that's
what you get if you use the simplest meaning of "identical type" within the
compiler's symbol table.

The new ISO Standard clearly specifies name equivalence.  Aside from being a
whole lot easier to implement, it is stricter, hence "safer" in the view of
strong-typing-makes-better-programs proponents.  (I tend to agree, but there
is room for argument.)  I believe Wirth himself argued for name equivalence
in the Standard, blithely ignoring his own large contribution to the existence
of the other interpretation.

So there you have it.  The compilers that have structure equivalence aren't
likely to change, because of all the existing programs they'd break.  Name
equivalence is officially sanctioned, so *those* compilers aren't going to
change either.  The people who lose are the ones who try to compile
structure-equivalence-needing programs with name-equivalence-enforcing
compilers.  I presume the original question came from someone who got bitten
that way...

About the only thing you can do is to make sure your own programs are
written to the name-equivalence standard; then they'll compile on both
kinds of compilers.

There's a moral here somewhere about the dangers of defining something
in two ways (in this case, Pascal was defined by both a book and a
widely-given-away compiler).  By the time you notice the discrepancies,
it's too late to give up EITHER definition without inflicting pain.

				tom lane
-----
ARPA: lane@ZOG.CS.CMU.EDU
UUCP: ...!seismo!zog.cs.cmu.edu!lane
BITNET: lane%zog.cs.cmu.edu@cmuccvma