As my motion to create a split of the current comp.lang.pascal group into
subsections winds to a close, I would like to cover Pascal's "situtation"
in general for interested readers. Please excuse the spelling errors.
PASCAL: HISTORY AND STANDARDS
This note gives a brief history of Pascal and the associated standards. Some
of the common misconceptions about Pascal are addressed.
Pascal was designed and created by Niklaus Wirth, currently a professor at the
Institute for Computersystems Eidgenossische Technische Hoschschule (ETH) in
Zurich, Switzerland.
Professor Wirth might be described as a professional language designer, and
has created Sail, Pascal, Modula, Oberon and other languages. Wirth was
involved in the Algol projects, and the history of Pascal could be said to
be that of Algol, which traces it's roots back to the beginnings of software
design.
ALGOL
At the time of Algol's start, the predominant language was Fortran. Fortran
was the first "real language", but was suffering from both old age, and
also limited scope of design. Produced to enable scientists and engineers to
efficiently program computers, fortran was never designed for general system
problems. At the time, "real programmers" still used assembly language for
efficiently, and indeed, even many heavily used business applications were
programmed in assembly for speed reasons. Fortran and other HLLs (High Level
Languages) were reserved for applications that would find the answer to a
given problem, or on applications that needed to be created quickly.
Algol was designed specifically to represent programming algorithims
efficiently. Thus the name, ALGOrithmic Language (first called IAL, or
International Algorithmic Language). Algol would be designed by programmers,
for programmers, and would be implemented by international agreement.
So Algol began as something of an idealistic project. As originally discussed,
Algol would be a programming "notation", or simply a means of publishing
algorithims, and actual implementation as a computer language would
follow as a matter of course. Specifically, Algol lacked any means of
handling I/O.
Algol was also the first language to be implemented by committee (an
international one at that). It was also the first language which had attempts
made to describe its appearance in a mathematical type notation (BNF, or
Backus Normal Form).
Algol united several language "features" that together made Algol a major
advance on previous languages, including:
- Support for recursion
- Block structure format
- Procedures with parameters
- free format (not line structured)
The appearance of an Algol program will be very familiar to Pascal programmers:
procedure problem(a, b);
value a, b;
integer a, b;
begin
integer k;
real e;
for k := 2*(a/2)+1 step 2 until b do
begin
e := if prime (k) then sqrt(3*k+sin(k))
else sqrt(4*k+cos(k));
if prime(k) then putlist(k, e, ' prime')
else putlist(k, e, ' noprime')
end
end
(from [sammet] "Programming Languages: History and Fundamentals").
This example looks very much like Pascal. And look at the declarations of
k and e inside the main block ! This is the notation borrowed for the C
language !
The first paper describing Algol was produced in 1958, and the "definitive"
specification for Algol was produced in 1960. Algol 60 became the benchmark
version of Algol, and was widely implemented, copied, and changed.
In particular, since Algol did not specifically define I/O statements, these
varied widely from implementation to implementation (the C language also has
no built-in I/O statements, but observance of a standard procedure set
was much better).
Pascal is a direct decendant of Algol 60 (as written by N. Wirth himself).
In a way, this is a redundant claim, because virtually every modern language
in use today owes it's basic structure to Algol. Not until the advent of
objects did languages significantly change the basic plan from the Algol
model.
Algol proceeded through other versions. There was Algol 68 and Algol W.
In these versions, the commitees responsible for the language incorporated
increasingly wild constructs into the language. As a result, Algol ceased
to represent mainstream program language design (one of the constructs of
later Algols, incidentally, was the treatment of assign as just another
operator, one of the more famous features of the C language).
Wirth, serving on the Algol commitees, became frustrated with the endless
addition of features to the language, and in his own words "felt a yearning
for simplicity".
PASCAL
In 1971, Professor Wirth proposed the first version of the language Pascal,
as a direct decendant of Algol 60. It was designed to be a carefull compromise
to take Algol 60, clean up and unify the language, and add the nessary features
to bring it to "state of the art" status. Indeed, Wirth would later decry
features of Pascal formed to appeal to Algol 60 users, such as the lack of an
"endif" statement on an "if".
Pascal extended Algol with records (borrowed from COBOL), sets, files, and
many would say most importantly of all, pointers.
After Pascal's introduction in 1971, it was revised in 1973 to it's final
form (under Wirth). The first implementation of Pascal was on the CDC 6000
computer. In later years, the charge would be made that Pascal was in fact
designed to be efficient specifically on that computer, and in fact there are
at least two features of Pascal that work suspicously well on that computer.
CDC 6000
The CDC 6000 was a 64 bit computer, and featured a unification of integer
and floating point operations. This is how it worked. The working registers
of the machine were 64 bits long, and would hold either a floating point or
integer operand. Floats were 64 bits long, with 48 bit mantissas, and 16 bit
exponents. However, integers were not nessarily 64 bits ! in fact, only 48
bits were garanteed to be usefull in operations on integers, with the
noted exception of comparisions. In other words, the CDC 6000 essentially
had a 48 bit integer ALU, which also participated in mantissa calculations
on floats (instead of the split ALU/FPU combinations common today).
Besides being architecturally simple, this sytem also had a few very desirable
"side effects":
- Most overflow situations could be detected by checking if the
result was greater than 2**48 (i.e., the CDC could not operate on
such values, but could compare to see if a prior operation had
delivered such an overrange operation).
- The mantissa as extracted from a floating point operand could
allways be represented as an integer without overflow. Indeed,
the extracted mantissa can be found by zeroing the top 16 bits
of an operand.
These effects show up in Wirth's early examples of Pascal programming. The
overflow capability gives Pascal a defacto way to detect integer overflows
without requiring any language constructs to do so. The mantissa equivalence
allowed the easy convertion of numbers to and from floating point format.
The result of this was that Wirth's examples in the "report" were overly
simplistic, and did not translate well to other machines.
The other famous oddity of the CDC 6000 was that a special character set
was used with that computer that gave 64 characters (no lower case). This
meant that there were as many characters as bits in a machine word, and
meant that the pascal type:
set of char;
Fit exactly in a single machine word. This fact, and the fact that the CDC
was practically the only machine to be designed this way, caused many
implementors of Pascal to cry "foul" over the design, since virtually no
other machines in existance would allow such an efficient representation
of character sets.
THE "REPORT"
Pascal followed in the steps of Algol in being announced by means of a
"report" on the language. The report, by N. Wirth and K. Jensen, featured
both a concise document on the features of Pascal and a full BNF of the
language (which absolutely described the SYNTAX of the language). Wirth
later followed up with "the Axiomatic Definition of Pascal", which
introduced a mathematical definition of the FUNCTION of the language).
The "Users Manual and Report" was a deliberately short and simple book
that nonetheless described the complete language, and continued Wirth's
"minimalist" ideas for language contruction (and description).
After the report, Pascal was essentially in motion. Towards the end of
the 1970's, Pascal became a runaway press phenomenon, and became the
"must have" compiler of the 70s. The culmination of this trend was when
Both Motorola and Intel actually designed instructions into their new
16 bit processors that were aimed specifically at Pascal implementations.
THE P-MACHINE
Pascal began to be badly fragmented. The
The original group at ETH decided that Pascal needed a new technology, known
as a "portable intermediate form" to ensure the rapid spread of Pascal.
The idea was to create a compiler that compiled only up to the point of
creating code for a low level hypothetical stack based computer (although
hidden from the user, this is actually how most compilers operate
internally). The compiler and it's toolset could be compiled to that
intermediate form, and that would be distributed. Then, the compiler
could be quickly ported to another machine by either translating that
form to actual machine code for the target machine, or even by simply
emulating the hypothetical stack machine and running the intermediate
form directly. The result was called Pascal-P, the intermediate form
dubbed P-code, and the hypothetical machine a P-machine.
RISE AND FALL
What happened next could be argued as pivotal for the future of Pascal.
UCSD (The University of California at San Diego) adopted Pascal as their
language of choice (as many universities were doing at the time), and
used the Pascal-P kit as their starting basis. However, UCSD wanted to
run it on the microcomputers that were appearing at the time (this is
still prior to the IBM-PC). Instead of using Pascal-P as a porting
kit, UCSD proclaimed that "Microprocessors were incapable of running
a complex language such as Pascal", and based their implementation of
Pascal on microprocessors entirely on the interpretation of the P-code
on such machines. UCSD created an entire operating system with editor,
compiler and even an elementary visual debugging system to be
interpreted on a microcomputer using P-code.
The result was the rapid spread of the UCSD implementation to the
various microprocessors avialable, at a time when the only real
competition for the system was CP/M on the 8080/Z80. Unfortunately,
it also created the vast misconception that Pascal was an interpreted
language (just as BASIC was widely used for interpretation only at
the time). This misinformation was spread even by such promenent
magazines such as BYTE (which printed misinformation about Pascal
with regularity over late 70's/early 80's).
The P-code controversy continued to a head when UCSD made the outrageous
claim that P-code and UCSD's implementation actually represented the
future of computing. P-code, it was said, would be far more efficient
than normal machine language if only a machine was designed to directly
implement the P-machine in hardware.
The proof of this came through a very roundabout route. Western Digital
Corporation, which now is a major maker of hard disk drives, began life
as a small, independent, but very high technology chip designer/maker
(originally they specialized in disk chipsets, hence the entry to the
disk business). When DEC wanted to create a cheap, highly integrated
version of the PDP-11, they tapped Western Digital to implement it,
which they did (as a three chip set). But Western Digital also got
the rights to produce the chip for other purposes (the offical rumor
I remember is that DEC did not like the result, and declined to buy
it, freeing the design rights to Western Digital - corrections invited).
The PDP-11 chipset was a very unusual processor (for the time) in that
it's "personality" or microcode could be changed (in fact, the 8086
was the first single chip processor to use microcode). Western Digital
used this ability to accomplish what they thought would be a market
scoop -- the implementation of a P-machine in hardware ! Finally, the
UCSD assertion would be put to the test !
THE CHILDREN OF PASCAL-P
Much like Michelson-morley, things in the P-code world would have been
much nicer if they had not been put to the ultimate test. The "processor
to end all processors" turned in miserable benchmarks verses ordinary
general purpose processors, and undoubtedly left a lot of folks scratching
their heads.
But the end of the 70's also marked the start of a whole new phylosophy
that explained why the experiment did not work. This was the RISC
(Reduced Instruction Set Computer) phylosophy, which stated that CPU
silicon was better spent making a simple instruction set run faster
than making the instruction set more complex, to get more bang for your
buck. And the P-machine was a CISC (Complex Instruction Set Computer).
In fact, it was "the mother of all CISCs", and unfortunately proved
the RISC point all to well.
UCSD's Pascal system continued to do well even in the early 80's. Upon
the introduction of the IBM-PC, it was offered as an alternate operating
system, along with CP/M, to IBM-PC DOS.
In 1981-1982, however, everything changed yet again. There was never any
particular barrier to other (competing) implementations of the P-code
based system. And several providers suddenly leap to front stage with
full page articles in BYTE and other rags offering cheap Pascal-P
systems (for about $50).
And in 1982, another system appeared that was different. This one actually
compiled elementry code for Z80 CPUs under CP/M, and so provided orders
of magnitude improvments in speed for the price (it was NOT the first
true compiler for Pascal on a microcomputer, an honor that probally
belongs to MT+ Pascal, followed by me in 1980).
In a wild story of american entrepenurisim, the new Pascal system was
marketed for mail order by a French illegal immigrant, who had to dodge
the INS while collecting orders for the product. It is my pet theory that
the name "Borland" was designed to disassociate the company from
Philippe Kahn, and allow it to continue undisturbed by the INS, who
continued to seek out Philippe.
Borland followed the introduction of Pascal on CP/M with Pascal for
the IBM-PC running under DOS (and Phil did finally make peace with
the INS).
Borland Pascal shows it's UCSD heritage in the implementation of UNITs
and string processing.
THE PASCAL STANDARD AND THE STANDARD MYTH
Because of the rapidly diverging implementations of Pascal, a standards
process was begun with both the ISO (International Standards Organization)
and the ANSI (American National Standards Institute). To be fair, many of
the features of Pascal that were decried as problematic in Pascal had been
worked out by the advent of the standards process. The two biggest
stumbling blocks were:
- The fact that Pascal files were designed to operate under
a batch (non-interactive) system.
- That the most common character set, ANSI, required at least
128 bits to form a "set of char", and thus required
multiword set implementations.
The first problem was solved by a technique known as "lazy I/O", which
simply means to defer all I/O until it is absolutely required. The second
was solved by compilers that optimized set handling to the exact size of
set required.
Because of this, the standards bodies decided that Pascal should be
standardized "as is", by simply clarifying the implementation as required.
In fact, there was only a single functional change made to the original
Pascal as described by J&W. And that was that procedures or functions
that get passed as parameters themselves must have a complete parameter
list specified (instead of the insecure method of omiting the list as
in original Pascal). This change was requested by Wirth himself.
This did not, however, stop another widespread myth about Pascal from
forming. And that was that significant changes occured in pascal to make
it a standard language. In fact, I believe that the PC software makers
themselves encouraged this myth. I was told as late as 1988 my Microsoft
that their Pascal did not meet the standard "because the standard was
not out when they designed it". This is completely bogus, since any
Pascal implementation that reasonably obeyed the standard would have
either automatically been compatible with the standard, or compatible
with minor changes (and many Pascal makers did just that, including me).
As a good example, Borland in their first users manual claimed to be
compatible with J&W Pascal, but later dropped that claim when it was
clear they had no chance of meeting the standard.
PASCAL MEETS THE STANDARD: MISCONCEPTIONS
Another myth that made the rounds even during the standards process was
that Pascal as specified by J&W was substantially incorrect or inprecise.
In fact, the REPORT contained only a few errors or omissions, most being
simple typos. What the standards makers wanted most of all was a
precise definition of the Pascal language, and thereby lies a tale.
Wirth designed Pascal to be an interface of conservative programmers
to liberal compilers. In places the REPORT deliberately left the results
as "undefined" or "implementation dependent". As a programmer, you were
not supposed to lean on these features. The compiler writers would,
in fact, create a perfectly reasonable outcome for the situation.
For example:
case x of
1: { stuff };
2: { more stuff };
.
.
end;
In the case statement, the outcome if x did not match any of the cases
was "undefined". In fact, every compiler would do something reasonable
with it (the most common being to simply do nothing, and continue
withe the next statement). But leaving it undefined left the compiler
writer an out. If the unltimate in efficency was needed, the compiler
would not generate checks for x out of range (by option). The result
is the same as leaving array index checks off. The program is more
efficient, but may crash if not correct.
Wirth believed that such things should be left undefined, so that the
compiler writer had the maximum ability to create efficent code.
Unfortunately, the report had many such "grey areas", including some
things that were not even left "undefined" in the REPORT:
var a: array [1..10] of char;
b: array [1..10] of char;
begin
if a = b then....
Here we attempt to compare to identical arrays, but whose types are
declared separately. This situation was left entirely uncovered by
the REPORT. But in the first implementation on the CDC-6000, the
compiler was very generous with this situation, and would try it's
best to match two different types to each other and forgive such
an equivalence on the programmers part. This is a classic example
of conservative/liberal design. If the programmer does not push it
and specifically declares types as identical that he will attempt
to use with each other, there will be no problem. Similarly, if
the compiler maker does his job correctly, it will forgive this,
and again there is no problem.
Rightly or wrongly, the standard creators decided that this kind
of grey area was wrong, and eliminated them. In fact, given a compiler
that strictly interprets the standard and outputs specific errors for
any such violation, it may be difficult to create a program that is
not portable ! But of course, programmers have had a lot of experience
defeating "portable" languages.
In 1982, the ANSI standard was issued, and about the same time, the
ISO standard came out. These two standards where identical by design,
with one exception. In the ISO, a single official extention had been
defined, known as Level 1 Pascal (with "ordinary" Pascal being Level 0).
This extention defined "conformant arrays" or a method of passing
variable length arrays to a single procedure or function).
THE "DEATH" OF PASCAL
Even when Pascal was at it's peak of interest in the late 70's/early
80's, another language made continuous inroads to the microprocessor
world. Started originally on the PDP-11, C was designed to the
proposition that a language could be made simple and have a greater
ability to be portable by putting more of the work on the programmer's
shoulders, and at the same time get better access to lower level
details of the computer and operating system. But what began the
widespread use of C was that a poorly performing compiler could be
written quickly for a microprocessor. Since this was at the same time
that the most popular Pascal implementation was interpreted (UCSD),
the early C compilers essentially went uncontested, even though most
were very poor performers. Although Pascal stayed on as the application
language of choice, C began a virtual takeover in the 80's as it was
used to implement virtually all system functions, beginning with
Windows.
Pascal, and especailly standard Pascal, got a second (and perhaps final)
wind on the PC with the advent of the 386 CPU. Up to that time, the
principal barrier to proper Pascal compiler implementation was the
segmentation model. When the 386 began hosting Unix and Unix clones,
porting of existing standard Pascal compilers was relatively easy.
These ports were followed by ports to VCPI/DMPI extended DOS, and even
to Windows via extender. These 32 bit compilers are still the most
efficient compilers available for the IBM-PC, typically turning in
speeds double that of Borland and other compilers.
Unfortunately, of the at least 4 compiler makers for 32 bit standard
Pascal, virtually all have dropped out of business, dropped the Pascal
side of their product line, or are maintaining the compilers so
poorly as to acomplish the same result.
As for the Borland version of Pascal, never very compatible with
either the original or the standard Pascal version, it has collected
huge sections of Basic, C, C++ and other codes, and now bears little
resemblence to standard Pascal.
PASCALS FUTURE
One of the odd facts of the programming world is that the "language of
choice" tends to change every 10 years or less. At the rate of software
design discoveries, this does not seem to be out of character. But it
does have an odd implication. And that is that the entire base of existing
programs are recoded into that "new" language every 10 years or so.
If not, you would be postulating that software has a total usefull life
of 10 years or less.
But of course, this is not true. Windows is nearing 10 years old, and
there is no indication that microsoft is recoding it into C++.
The reason that software language progress does not halt is twofold:
- New programmers enter the profession willing and able to
use the new languages exclusively.
- Existing programs tend to be maintained for long periods of
time even as new programs or even new sections of old
programs are rewritten in the new language.
So it basically comes down to a personal decision: are you going to
throw away all your existing programs and start over because you may
be out of date for not using C++/C++++/C++*4 ?
These kinds of factors account for the fact that FORTRAN is still in
wide use (and yes, even being used in visual applications) long after
being "dead".
------------------------------------------------------------------------------
| JUST SAY NO -- TO THE GIF (Greed Is Fundamental) FORMAT. |
| SEND "STEALTH STANDARDS" BACK TO HELL WHERE THEY CAME FROM. |
------------------------------------------------------------------------------
| Get slip access for shell prices with TIA ! |
| Microwave: Def: Device used in the manufacture of rubber goods. |
| Fuzzy logic: Def: Method of engineering taught by several universities. |
| Segmentation: Def: A small box used to keep programmers in. |
| Get a life ! Now available for very reasonable terms and prices. |
| |
| SAM is s...@ccnet.com |
------------------------------------------------------------------------------
- How can a history of Pascal not mention Object Pascal or Extended Pascal?
- How can you claim that Turbo Pascal shows its UCSD heritage in its units,
when the units didn't arrive in Turbo Pascal until 5 years after the original
release? I suspect that they were inspired by both UCSD and Modula-2, but
there may well be other influences I'm unaware of.
- How can you claim that Pascal reached its peak in popularity around
1980, when Turbo Pascal, released 2 years later, was for many years the most
popular compiler ever sold in any language (and may still be)?
- Why did you you reply to a bunch of "myths" I've never heard of before, but
not address the claim that Pascal was designed as a teaching language, never
intended for real world use?
Duncan Murdoch
What can I say ? I got tired of writing.
> - How can you claim that Turbo Pascal shows its UCSD heritage in its units,
>when the units didn't arrive in Turbo Pascal until 5 years after the original
>release? I suspect that they were inspired by both UCSD and Modula-2, but
>there may well be other influences I'm unaware of.
From what I have seen, units are almost a direct copy of the UCSD way. And I'm
for that. The unit system was a pretty good way to do it, and in fact the
compiler I use has a version of units that is also close to UCSD units.
Modula, incidentally, is completely different.
>
> - How can you claim that Pascal reached its peak in popularity around
>1980, when Turbo Pascal, released 2 years later, was for many years the most
>popular compiler ever sold in any language (and may still be)?
The history document was about Wirth's Pascal. I invite you to write a
"history of Borland Pascal" document.
>
> - Why did you you reply to a bunch of "myths" I've never heard of before, but
>not address the claim that Pascal was designed as a teaching language, never
>intended for real world use?
I did, and now I will expand on it.
In fact, those myths are in wide use, and you just used one ! Here ya go
Duncan, from the book "Pascal: User Manual and Report" [K. Jensen& N. Wirth],
the original master document on Pascal:
"The introduction of record and file structures should make it
possible to solve commercial type problems with Pascal..."
To be fair, Wirth mentions several times that he designed Pascal for teaching
use (by stunning coincidence, he IS a teacher). But nowhere does he nor
anyone else reputable state that pascal was "never intended for real world use"
(your quote).
Pascal obviously IS applicable for real world use. Borland did so.
>
>Duncan Murdoch
The CDC 6000 series machines had 60 bit words. The 6000 character set at
the time was neither fish nor fowl: 6 bit characters packed 10 to a word.
Sets of characters were never hard for anyone to implement, just not very
efficient. Sets of integers or reals, however were a problem ;-).
The C language was brought to us by the good folks at AT&T, who used it for
the earliest (1976 comes to mind) implementations of Unix on early DEC
hardware like the PDP-8. "Windows" wasn't even a glimmer in anyone's eye
at the time, because personal computers were beyond most folks event
horizons then.
Just as most of the net's offerings, the Pascal history article seems to
suffer from a collective two-week memory. I was on the Pascal X3J9 and WG2
standard committees. Before that, I used both P6000 and UCSD's stuff. The
P6000 compiler was pretty good and didn't have many bugs, but couldn't
outrun a similar algorithm written in MNF because MNF optimized and P6000
didn't. The UCSD P-machine was never a serious contender for commercial
success because it was interpreted. IBM offered a really good "Pascal/VS"
compiler that seemed to use highly extended p-code as an intermediate
language, but had to put a real p-code to BAL optimizing assembler in the
package before it could be made into a product. A number of ISO and ANSI
standard Pascal compilers are still offered by any number of vendors these
days, however not many of these implement all of the "Extended Pascal"
standard, nor many of Borland's quirks.
A validation suite for "Classic Pascal" and Extended Pascal, approved by
the various standards committees, is available for sale. When last I
checked, the validation suite also included a reference p-code compiler and
interpreter which passed all the tests. Don't believe this to be the case
for either C, C++, or Fortran (77 or 90, but "FCVS" [the "Navy tests" to
the really old-timers] may qualify as a validation suite in someone's
eyes).
Sad but true: "Serious" scientific computation is _still_ done in Fortran;
"serious" business applications are _still_ written in COBOL; and serious
systems work is now done mostly in C (or its variants).
If you like Pascal, great. Use it when and where possible. Except for
certain exceptions for the PC world, if you want to make money in software,
learn another language. In all likelihood, something will come along in
another year or two to eventually replace C and C++. To some of us, this
will be a good thing. To others, a disaster. Regardless, the only
constant in computing is change. Get used to it.
Rooting-for-Add_One_to_COBOL_Giving_COBOL'idly yours,
======================================================================
/| | Fleam's LAW: |
\'o.O' | You can add titanium wheels to the | Steve Siegfried
=(___)= | ox-cart of technology, but it's | s...@skypoint.com
U | _still_ gonna be an ox-cart. |
======================================================================