robertd@tektronix.UUCP (Bob Dietrich) (02/06/85)
There's been quite a bit of discussion about Pascal standardization recently.
I'll try to answer briefly the points that I think have been raised, and, if
need be, follow with more detail later. Although I am heavily involved in the
ANSI/IEEE committee, the following are my own opinions and do not represent
any official position (standard ANSI disclaimer).
1. Separate compilation using 'external'.
The current Pascal standards (ANSI/IEEE and ISO, see below) have a NOTE in
the section (6.1.4) that defines the directive 'forward'. The note begins:
"NOTE: Many processors provide, as an extension, the directive
"external" [italics], which is used specify that ... "
Two points about this. First, this is a note, which is supplementary text
that is NOT a part of the standard per se. The second point is the phrase
"as an extension", which should be self-explanatory.
This note was added due to the realization that this is most common form of
Pascal separate compilation. (Neither "external" nor "forward" appear in the
Jensen & Wirth Pascal Report, only in the User Manual section). However, many
people are uncomfortable with this method, since the way it is normally
implemented bypasses type checking. A more secure method for separate
compilation was recently agreed upon in the Joint ANSI X3J9/IEEE Pascal
Committee (JPC), and may make it into an extended Pascal standard. More on this
later.
In spite of this, it certainly is possible to do separate compilation anyway,
albeit the language definition doesn't provide explicit mechanisms to help out.
2. Variable length arrays.
In Pascal, the definition of array types includes as part of the type the index
type of the array. This leads to the problem of not having variable or flexible
length arrays. The ISO Pascal Standard attempted to solve this problem (for
parameters only) with the extension called conformant arrays. Again, many
people feel that this approach has many technical flaws. It did not become
part of the American standards for this reason.
Recently JPC has approved for the candidate extension library an extension
called schemas. Schemas solve the parameter passing problem as a subset of
their functionality. Schemas define a family of types (or parameterized types
if you will) that can be instantiated with a particular size. One of the major
benefits of schemas is that they fit into Pascal's name type compatibility
rules.
3. Pascal standards vs. Jensen & Wirth.
There are many technical problems with the definition of Pascal contained in
the J&W Pascal Report, not to mention the fact that many people have taken
both the User Manual and the Report to be the definition. The problems and
ambiguities have been documented many times, but they include confusion about
"name" vs. "structural" type compatibility, definition of procedural
parameters, and various others. The goal of standardization was to define
Pascal essentially as it existed in J&W with no extensions, just clarifications.
The job turned out to be much more work than we anticipated, and an extra year
was added by an international debate over whether to add the conformant array
extension.
It's interesting to note that the same sorts of ambiguities have appeared with
C and Modula-2, which have the same style of specification as J&W Pascal.
There's an added problem when you talk about J&W. Which version? When the
second edition first came out, the 'dispose' procedure was accidently dropped
from the Report (thus the CORRECTED second edition). This is a major reason
many Pascal compilers don't have 'dispose', along with its absence from the
P2/P4 compilers.
4. American and international standards.
( My dates may not be perfectly accurate here)
In 1977 the British Standards Institute (BSI) began a standardization effort
for Pascal. The way international standards work is that a national body such
as BSI or ANSI declares that it is working on a particular standard, and that
body wishes to serve as a host for developing an international (ISO) standard.
This is what BSI did. By the way, such national bodies are NOT part of the
government; at least ANSI is not and I don't think any others are.
BSI's action was unusual for language standards. Previously, most (all?)
of the programming language standards were produced by American ANSI X3Jx
committees and then adopted by ISO. Usually the ISO documents are cover pages
and then a reference to the appropriate national standard. The ISO standard
for Pascal is a pointer to the BSI document.
In late 1977 the IEEE started a standards effort for Pascal, and shortly after
ANSI did the same. (Who was really first was a subject for hot debate, but this
was the order their organizational meetings were held). After much political
maneuvering, the two bodies agreed to run a committee under ANSI rules, and
thus was born the Joint Pascal Committee, another first.
JPC is charged with producing standards for the IEEE and for ANSI (as X3J9).
Since IEEE procedures take less time than ANSI, the IEEE version was approved
before the ANSI, September 17, 1981 for the IEEE and December 16, 1982 for
ANSI. The differences between the two versions are confined to the cover pages.
Also, JPC has the responsibility for forming the technical vote on ISO Pascal
matters.
5. ANSI/IEEE and ISO Pascal Standards differences.
To summarize a very lengthy process, JPC did not feel it could accept the
conformant array feature into an American standard. Thus the ANSI/IEEE
standard is ISO level 0. ISO level 1 is the conformant array extension. The
only other differences are minor: different wording about implementation-
dependent features, ANSI/IEEE allows end-of-line to be generated by a value
of type char, and the ANSI/IEEE Standard more explicitly defines the binding
of the file parameter for read, readln, write, and writeln.
6. Extending the Pascal standards.
JPC was created with two programs of work. The first was to standardize Pascal
as it existed. This project is now in maintenance mode. The second project was
to create an extended Pascal standard. Most of JPC's work in the last few years
has gone into creating what is called the Candidate Extension Library (CEL).
The CEL is intended to serve as a source for creating an extended Pascal
standard. The contents of the CEL are individual proposals for extensions that
include syntax, semantics, examples, costs, etc. Each proposal is heavily
scrutinized and refined before it makes it into the CEL. The majority of
proposals have not made it. However, inclusion in the CEL is no guarantee that
the extension will make it into an extended standard. Currently, there are 28
extensions in the CEL, from underlines in identifiers to separate compilation
and schemas.
JPC is now taking this collection of features and trying to turn it into a
language that is consistent and useful. In my own opinion, the result of this
will be a new Extended Pascal Standard, separate from the existing ANSI/IEEE
Pascal Standard. This will minimize impact on existing compilers. JPC is also
attempting to get ISO approval for working on such a new standard.
7. Implementors and standards.
I actively participate on JPC when I'm not working on Pascal and other
compilers, so I feel I can address this issue. Several factors are involved
here. 1) The Pascal standards came out after many Pascal compilers were already
in existence, with the author gone on to other projects. 2) It costs money to
correct and update the compiler and associated documentation. 3) It takes time,
discipline, and thought to implement all of Pascal.
The last point is one of my pet peeves. There are many compilers (not just for
Pascal) that leave out 10 standard parts of the language and add 30 extensions.
This is the "extended subset" mentality. The implementor runs out of schedule
time, has a "neat" feature to add and so sets are left out, can't figure out
how to do "set of char" for a particular processor, or all of the above. This
results in a less than quality implementation. The less careful buyer suffers.
Since people associate the language with particular implementations (see
the comment by a certain magazine columnist a while back that lamented a
compiler not having "standard error message 104"), the language itself is
lambasted.
8. Your responsibility as a Pascal user.
The fate of substandard Pascal implementations is in your hands. Don't buy
them. If you do or have already, pressure the vendor to improve the quality.
The Pascal standards REQUIRE that for a Pascal processor to conform to the
standard, it must have a "compliance statement" available, which lists the
ways the Pascal processor does not conform to the standard. Additionally, the
processor must be able to reject programs using implementation-defined
extensions, or else document its failure to do so. In many countries (but not
the U.S.), standards have the weight of law. Making a statement that the
processor conforms when it does not can have serious consequences.
In addition to the documentation that should accompany an implementation, the
Pascal Validation Suite is available to help both the implementor and the user.
While testing is never complete assurance that a program is correct, the Vali-
dation Suite can be used to help point out many of the common errors in Pascal
implementations.
Whew! That was a lot to read, wasn't it? That's what I get for trying to cover
several discussions that have taken place over the last couple of weeks.
Bob Dietrich
Tektronix, Inc.
(503) 629-1727
{ucb or dec}vax!tektronix!robertd uucp address
robertd@tektronix csnet address
robertd.tektronix@rand-relay arpa address