Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Algol 60 vs Algol 68 (was "stack machines (Burroughs)")

65 views
Skip to first unread message

Bakul Shah

unread,
Jun 11, 1988, 11:07:54 PM6/11/88
to
In article <10...@tekecs.TEK.COM> Andrew Klossner writes:
> ...
>There really isn't any "beyond" to Algol 68 since the 1975 Revised
>Report. It's a dead language. And that's too bad; while its model of
>computation is distant from that of real machines (making it an
>inappropriate language for most low level systems programming), it does
>an admirable job in its stated domain of algorithmic description, and
>is great for applications programming.

Actually Algol 68's model quite closely matches real machines and
the language can be compiled to generate code as efficient as
compiled C; though I doubt there are any modern, optimizing
compilers for it. The language is verbose and the its syntax
rather od (!) but it can be used quite effectively for systems
programming. I recall the CAP operating system (for the Cambridge
CAP computer) was written in Algol 68.

I wonder how much of C design was influenced by Algol 68 as most
of K&R C seems to map almost directly to Algol 68 and where C
differs is usually where the compiler's job is simplified. Come
to think of it, a major subset of Algol 68 with a new and concise
syntax (sort of like C's) can make a very elegant, type safe and
well rounded language.

-- Bakul Shah <..!{sun,pyramid,ucbvax}!amdcad!light!bvs>

n

unread,
Jun 14, 1988, 12:54:13 PM6/14/88
to
In article <1988Jun11.2...@light.uucp> b...@light.UUCP (Bakul Shah) writes:
>In article <10...@tekecs.TEK.COM> Andrew Klossner writes:
>> ...
>>There really isn't any "beyond" to Algol 68 since the 1975 Revised
>>Report. It's a dead language. And that's too bad; while its model of
>>computation is distant from that of real machines (making it an
>
>I wonder how much of C design was influenced by Algol 68 as most
>of K&R C seems to map almost directly to Algol 68 and where C
>differs is usually where the compiler's job is simplified. Come
>to think of it, a major subset of Algol 68 with a new and concise
>syntax (sort of like C's) can make a very elegant, type safe and
>well rounded language.


(speaking as someone who once wrote an Algol 68 compiler ...) in actual fact
the language was ahead of its time in terms of compiler technology, nowdays
languages are usually designed so that the are relatively easy to generate
code for (this is because most language designers are also compiler writers
and don't add things they know are going to be excessively inefficient or
difficult to implement - smart people). Algol 68 is of a similar complexity
to Ada, in fact Ada is one of the few 'modern' languages to include many of
the features of Algol 68 (user defined operators etc etc), it was quite
entertaining reading the Ada implementation papers a few years ago and
comparing them with the Algol 68 implementation papers from 10 years
previously (the same things being rediscovered all over again).
Probably the main success story from the Algol 68 effort was Pascal, Wirth
was one of Algol 68's designers (he was on the committee) and in Pascal he
implemented all the things in Algol 68 (plus a few extras) that were easy
to implement using the existing technology, the result was a language that
flourished ....


Paul Campbell

PS: Back to the original topic: I spent a lot of my time on my Algol68 compiler
trying to figure out how to put it on our Burroughs 6700, my conclusion
was that it was not possible to implement any of the pointer code
on the 6700 without interpreting everything and making the result too
slow to be usefull. One of the main 'problems' with the Burroughs
environment is that system security and integrety depends on the
security of code files, ie only a privileged program (a compiler) can
make a code file and bad code can crash the whole system, this tends
to discourage system administrators from letting people develop
compilers on their systems ..... needless to say a real C was out of
the question ....

--
Paul Campbell, UniSoft Corp. 6121 Hollis, Emeryville, Ca
E-mail: ..!{ucbvax,hoptoad}!unisoft!paul
Nothing here represents the opinions of UniSoft or its employees (except me)
"Nuclear war doesn't prove who's Right, just who's Left" (ABC news 10/13/87)

Piet van Oostrum

unread,
Jun 16, 1988, 11:46:23 AM6/16/88
to

I wrote major parts of both an Algol 68 and an Algol 60 compiler, so I
assume I know a bit of the difficulties. Regarding ALGOL 68 and C, I think
there are a lot of ideas from Algol 68 in C, but -- as in Pascal -- C left
out a lot of the hard things. The syntax of C is much closer to Algol 68
than Pascal. Also some Algol 60 syntax crept into C, e.g. function headers.

Now any of the left out features from Algol 68 (e.g. heap variables,
dynamic arrays) are not very difficult to add to implement, BUT if you add
two or more features at the same time they are going to interact in a
terrible manner. The complexity of the resulting compiler is almost
exponential to the number of added features. One example: dynamic arrays
are easy: Algol 60 had it, see also the discussion on alloca in this
newsgroup. Unions are easy: C has them. The combination of dynamic arrays
and union however forces you to use the heap, and hence garbage collection.

Although I must say I like garbage collection very much, it assumes that
you have a perfectly secure language, which C isn't.

--
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands
Telephone: +31-30-531806 UUCP: ...!mcvax!ruuinf!piet

Richard A. O'Keefe

unread,
Jun 17, 1988, 4:40:14 PM6/17/88
to
In article <4...@ruuinf.UUCP> pi...@ruuinf.UUCP (Piet van Oostrum) writes:
>I wrote major parts of both an Algol 68 and an Algol 60 compiler, so I
>assume I know a bit of the difficulties. Regarding ALGOL 68 and C, I think
>there are a lot of ideas from Algol 68 in C, but -- as in Pascal -- C left
>out a lot of the hard things. The syntax of C is much closer to Algol 68
>than Pascal.

I do not understand why people claim a relationship between C and Algol 68.
C is BCPL + Pascal types. The only thing that C's "struct"s have in common
with Algol 68 is the name, the _semantics_ is Pascalish. C's "unions" are
not Algol 68's secure unions (e.g. there is no discrimination case statement)
but semantically identical to Pascal's variant records with no tag variable.
The set of operations in C is exactly the BCPL set. I think we can explain
the function headings by C's descent from BCPL, when types were added to C,
it would have been easiest to add new lines to programs than to change old
lines. Compare
still_legal_c(i, j) LET BCPL_VERSION(I, J) BE
{ $(
return i+j; RESULTIS I+J
} $)
Even alloca() has a BCPL equivalent (VECTOR N) rather than an Algol 68 one.
Just about the only thing in C which I can find in Algol 68 but not in BCPL
or Pascal is "long int" and "short int". (Algol 68 uses "long real" and
"real", not "double" and "float".) Examples could be multiplied: C's "switch"
statement comes from BCPL and has very little in common with Algol 68's "case"
statement, C's scoping comes from BCPL, not Algol 68, &c &c &c.

It's not that C left anything out from Algol 68, it's that the languages C
really is descended from never had them.

James Jones

unread,
Jun 18, 1988, 9:29:52 AM6/18/88
to
In article <1...@quintus.UUCP>, o...@quintus.UUCP (Richard A. O'Keefe) writes:
> I do not understand why people claim a relationship between C and Algol 68.
> C is BCPL + Pascal types.

I would think that C coercions were inspired somewhat by Algol 68 (but with
considerable sleaze added--Algol 68 wouldn't let you do many of the coercions
that C swallows without a peep.)

James Jones

Bakul Shah

unread,
Jun 18, 1988, 4:30:05 PM6/18/88
to
In article <1...@quintus.UUCP> o...@quintus.UUCP (Richard A. O'Keefe) writes:
>
>I do not understand why people claim a relationship between C and Algol 68.
>C is BCPL + Pascal types. ...

My mistake. I know C is based on B (based on BCPL (based on CPL].
I didn't say it well but I was wondering if any Algol 68 ideas had
influenced C. Some private mail from people who should know seems
to indicate there was no direct influence. My apologies for
causing any confusion.

-- Bakul Shah <..!{sun,ucbvax,pyramid}!amdcad!light!bvs>

Isaac Rabinovitch

unread,
Jun 19, 1988, 7:12:19 PM6/19/88
to
In article <11...@unisoft.UUCP>, pa...@unisoft.UUCP (n) writes:
> Probably the main success story from the Algol 68 effort was Pascal, Wirth
> was one of Algol 68's designers (he was on the committee) and in Pascal he
> implemented all the things in Algol 68 (plus a few extras) that were easy
> to implement using the existing technology, the result was a language that
> flourished ....
Hm, it's been a long time since I read about this, but I think you have
your history wrong. I understand that Wirth thought Algol 68 was a
disaster, but was overruled the the rest of the committee. He then went
off and did Algol W, Pascal, and Modula, languages which use concepts he
couldn't sell to the Algol 68 commitee. Correct me if I have this
wrong.
I used to love reading the Algol 68 report. All those complicated,
interlocking concepts (the version I read arranged the chaptersin a
2-dimensional matrix for easy cross reference) has a lovely, terrible
charm. Rather like the Indian Juggernaut ceremony.

Isaac Rabinovitch.

a...@nott-cs.uucp

unread,
Jun 20, 1988, 2:29:38 PM6/20/88
to
> == pa...@unisoft.UUCP (Paul Campbell) in <11...@unisoft.UUCP>
>> == b...@light.UUCP (Bakul Shah) in <1988Jun11.2...@light.uucp>
>>> == Andrew Klossner in <10...@tekecs.TEK.COM>

>>>There really isn't any "beyond" to Algol 68 since the 1975 Revised

>>>Report. It's a dead language. And that's too bad; [ ... ]

Mostly agreed. Yet there were several good ideas that didn't quite
make it into the 1975RR (modals, partial parametrisation, imported/exported
variables, etc), but were much discussed in Algol Bulletin, and are only
just making it into `modern' languages. And it's not quite as dead as
most computing scientists might think. We still have several large
applications running on the Univ mainframe; I still use it on our
PDP 11/44 [only language available with semaphores, :-(]. Sadly, it will
probably die locally if we ever manage to upgrade our hardware.

>>I wonder how much of C design was influenced by Algol 68 as most

>>of K&R C seems to map almost directly to Algol 68 [...]

Well yes, but almost any algorithmic language mostly maps pretty
directly to Algol 68. Only K&R could tell you exactly how much K&R were
influenced by Algol 68; some things probably were (assignment operators),
some things obviously weren't (for statements), and some things ought to
have been more so (unification of expressions and statements).

>> [...] Come


>>to think of it, a major subset of Algol 68 with a new and concise

>>syntax (sort of like C's) ...

What? The *full* syntax of A68 fits easily as structure diagrams
into one side of A4 (the `Watt-Peck-Sintzoff' diagram), or as sort-of
BNF rules into a side-and-a-bit (Woodward and Bond rules). Both A68 and
its syntax are more concise than C; that was the source of many people's
complaints over the years.

>> ... can make a very elegant, type safe and
>>well rounded language.

Yeah!

> Probably the main success story from the Algol 68 effort was Pascal, Wirth
>was one of Algol 68's designers (he was on the committee) and in Pascal he
>implemented all the things in Algol 68 (plus a few extras) that were easy
>to implement using the existing technology, the result was a language that
>flourished ....

Which committee? There were lots. I don't think Wirth (or many of
the other `survivors' from the Algol 60 days) had much affinity with A68
as it emerged. The developing schisms, as reported in Algol Bulletin, make
highly entertaining reading, and make anything we've seen on the Net about
C or Fortran standardisation look like a vicarage tea party. If Wirth had
indeed made Pascal an easily implemented A68, we would all be deeply in his
debt. Unfortunately, Pascal was a clear step back in language design;
and also now a moribund language.

Examples of easily implemented A68 features that didn't make it
into Pascal:

Assignment operators
Generalised FOR statement
Closures
Initialised declarations
Declarations "as needed" instead of in a rigid format at top of block
Complex numbers
Dynamic arrays, and other array features such as UPB
SKIP (visible empty statement)
etc, etc.

IMHO, the Algol thread of language development could be revived, if
only someone, somewhere, had a compiler, any compiler, that they were willing
to make freely and widely available, eg on the Net. Pascal flourished
because compilers and books about it were made easily available. A68 has
the books (just about), but not the compilers.

--
Andy Walker, Maths Dept., Nott'm Univ., UK.
a...@maths.nott.ac.uk

Richard A. O'Keefe

unread,
Jun 20, 1988, 11:19:33 PM6/20/88
to
In article <9...@gethen.UUCP> is...@gethen.UUCP (Isaac Rabinovitch) writes:
>I understand that Wirth thought Algol 68 was a
>disaster, but was overruled by the rest of the committee.

Not the whole of the committee. There was a "Minority Report".
Ah, if only the committee had heeded the concerns of the Minority Report;
we might have had ADA _years_ earlier (:-).

>He then went
>off and did Algol W, Pascal, and Modula, languages which use concepts he
>couldn't sell to the Algol 68 commitee.

Algol W came *before* Algol 68. There are no concepts in Algol W or Pascal
that I can think of that aren't in Algol 68, and the main concept in Modula
(did you mean Modula or Modula-2? they are quite different) not in Algol 68
is modules. The irony of it all is that Pascal is significantly crippled
with respect to Algol W.

The essential ideas of Algol 68 were that the whole language should be
precisely defined and that all the pieces should fit together smoothly.
The basic idea behind Pascal was that it didn't matter how vague the
language specification was (it took *years* to clarify) or how many rough
edges there were, as long as the CDC Pascal compiler was fast.

Steven Ryan

unread,
Jun 21, 1988, 4:31:05 PM6/21/88
to
>Algol W came *before* Algol 68. There are no concepts in Algol W or Pascal
>that I can think of that aren't in Algol 68, and the main concept in Modula
>(did you mean Modula or Modula-2? they are quite different) not in Algol 68
>is modules. The irony of it all is that Pascal is significantly crippled
>with respect to Algol W.

- A unified loop clause that permits counting and while-conditions. (I
understand Oberon dropped the for-statement because so many programs
need this combination rather either/or.)
- Permits a series in the predicate position.
- A safe way to include unsafe predicates: if (guard|unsafepredicate|false)...
- Collateral clause which can be structure-display or row-display, or
just a nondeterministic construct.
- Parallel clause.
- A safe union mode (can't diddle the tag field to play silly bit games).
- Array bounds are not part of syntax so that formal arrays and actual arrays
are easily reconciled. (How long has Pascal struggled with that one?)
- Expression language.
- Initialised declarations.
- Ref ref modes (?).
- A mode system that does not require hand waving to cover the difference
between variable and value.
- Declaration can be near the point of use--no need to introduce a new range
for each joined declaration.
- Identity declarations.
- Operator declarations.
- Priority declarations.
- Procedures as first class objects.

That's all I can think of now right now. Somebody pointed out "Algol does the
hard parts and lets the programmer do the easy parts. Pascal does the easy
part and makes the programmer do the hard parts."



>The essential ideas of Algol 68 were that the whole language should be
>precisely defined and that all the pieces should fit together smoothly.
>The basic idea behind Pascal was that it didn't matter how vague the
>language specification was (it took *years* to clarify) or how many rough
>edges there were, as long as the CDC Pascal compiler was fast.

And the Pascal method of language definition is unfortunately the accepted
and acceptable norm.

Bakul Shah

unread,
Jun 24, 1988, 2:46:10 PM6/24/88
to
Seeing Dr. A. N. Walker's article reminds me...

In my opinion, a programming language student should atleast
understand Algol 68 but reading the Revised Report can be
daunting. An excellent introduction to A68 is ``Introductory
Algol 68 Programming'' by D. F. Brailsford and A. N.
Walker (Ellis Horwood Publishers). You may not find it in
bookstores as it was first published in 1979 but a good
library should have it.

Isaac Rabinovitch

unread,
Jun 26, 1988, 12:11:11 AM6/26/88
to
In article <1...@quintus.UUCP>, o...@quintus.uucp (Richard A. O'Keefe) writes:
> In article <9...@gethen.UUCP> is...@gethen.UUCP (Isaac Rabinovitch) writes:
> Not the whole of the committee. There was a "Minority Report".
> Ah, if only the committee had heeded the concerns of the Minority Report;
> we might have had ADA _years_ earlier (:-).
Hmm, I'm not too familiar with Ada, and it's been a long time since I
used Algol W, but it seems to me that Algol W was a far simpler
language. Perhaps the two have crucial features in common, but most of
the controversy with Ada seems to be not with the quality of ideas
involved but the *quantity*.

>
> The irony of it all is that Pascal is significantly crippled
> with respect to Algol W.
Could you expand on that point? I don't remember enough Algol W to
understand what you mean, but I do remember enough to be intriqued by
your argument. I used to like to like Algol W for its elegance of
semantic and syntactic elegance (every block had a value, for example),
but everybody else I knew thought that "elegance" made the language
kludgy.

Anecdotal (and probably not persuasive) counterexample: I once
participated in a class project in which we were trying to implement a
large program with Algol W running on an IBM 360/40 with half a meg of
memory. (Gad, the AT clone I'm using now is more powerful.) Because of
intrinsic limitations with Algol W, we tried to switch to Pascal --
which required more memory than we had! So I had to wait a decade to
try Pascal.


>
> The essential ideas of Algol 68 were that the whole language should be
> precisely defined and that all the pieces should fit together smoothly.

Then they went and came up with the most complicated language definition
ever, ruining any hopes of achieving that goal.


> The basic idea behind Pascal was that it didn't matter how vague the
> language specification was (it took *years* to clarify) or how many rough
> edges there were, as long as the CDC Pascal compiler was fast.

It's worth remembering that Wirth never meant the language to be *used*.
It was supposed to be a language for *thinking* about computing, not
implementing systems. I've got early 70s Pascal books that use dialects
of Pascal that were never even implemented, and never meant to be.

The main reason Pascal is so popular today is the same reason BASIC is:
micro programmers were hungry for high-level (relatively) languages, and
vendors addressed the marketplace by adapting teaching tools. Thank
goodness they never got round to PILOT!


Isaac Rabinovitch

Steven Ryan

unread,
Jun 27, 1988, 6:59:44 PM6/27/88
to
> An excellent introduction to A68

Also, a Practical Guide to Algol 68, by Frank Pagan. Somebody else wrote
a book introducing vW2 grammars and concluding with a formal syntactic
and semantic definition of a small language. North Holland (of course) but
I don't remember authour or title.

Richard A. O'Keefe

unread,
Jun 27, 1988, 11:01:49 PM6/27/88
to
In article <9...@gethen.UUCP> is...@gethen.UUCP (Isaac Rabinovitch) writes:
>In article <1...@quintus.UUCP>, o...@quintus.uucp (Richard A. O'Keefe) writes:
>> Ah, if only the committee had heeded the concerns of the Minority Report;
>> we might have had ADA _years_ earlier (:-).
>Hmm, I'm not too familiar with Ada, and it's been a long time since I
>used Algol W, but it seems to me that Algol W was a far simpler language.

Just so. The Minority Report claimed that Algol 68 was directed at the
wrong issues and didn't provide the tools (modules &c) for building large
systems. These were the same concerns that led eventually to ADA, after
a wasted decade had shown that Pascal was _not_ the answer.

>> The irony of it all is that Pascal is significantly crippled
>> with respect to Algol W.
>Could you expand on that point?

Arrays. Algol W and Algol 68 were just about the last of the languages
whose designers thought that the "array" features of a language should
be influenced by the needs of "scientific" programmers rather than by
the addressing modes of the hardware. (Dijkstra has also resisted the
"hardware rules" mentality, but do you see D-arrays going into the next
revision of Pascal, or into Fortran 8X?) Even ADA basically just kludges
around Pascal's limits.

A digression on Algol 68 arrays. You can do things like
[1:n, 1:m] REAL a := read_array(n, m);
# ... #
[] REAL arow = a[i,:], acol = a[:,j];
# ... #
... arow[k] ... # same as a[i,k] #
... acol[k] ... # same as a[k,j] #
Why is this useful? After all, a good optimising compiler should notice
that a subscript remains constant and evaluate that part of the addressing
polynomial just once. The usefulness of the feature is nothing to do with
whether it helps the compiler generate better code, though it may, but with
that fact that something I didn't write in the code is something I didn't
get wrong. It's the same advantage that a[i,j,k] +:= 1 has; because I
didn't have to write the LHS twice, I missed one opportunity to make a mistake.

>> The essential ideas of Algol 68 were that the whole language should be
>> precisely defined and that all the pieces should fit together smoothly.
>Then they went and came up with the most complicated language definition
>ever, ruining any hopes of achieving that goal.

Nope, they didn't ruin any hopes whatsoever of achieving that goal.
Not a bit of it! What they ruined was any hope of having many people
_realise_ that the goal had been met. If you want to see a complicated
language definition, take the ANSI ADA specification and add the INRIA
formal definition of ADA (yet another definition which started by
inventing a new definition language). I believe that the reason that
the moderately complex definition of Algol 68 scared people off but that
the ferociously complex definition of ADA hasn't is that people were
_shown_ the _whole_ Algol 68 definition, but not so ADA. (Yes, the INRIA
definition never made it into the standard. If you read comp.lang.ada you
will see that the result is that ADA in practice is about as ill-defined
as C.)

David Keppel

unread,
Jun 28, 1988, 8:42:27 PM6/28/88
to

I would claim different: that the reasons that PASCAL are (was) so
popular include:
+ Simplicity: can be implemented reliablly.
+ Simplicity: can be understood effectively.
+ Quality: The language had years of thinking in it before it came
into an implementation.
+ Straightforward: A compiler can do little optimization and produce
good code.
+ Defintion: There is a good standard to adhere to.

I think that these reasons (and others) are responsible for the
vendors' choice of Pascal over Xyz. I'm not claiming that there
aren't problems with Pascal, there are many. As Issac (or somebody)
pointed out, Wirth designed it as an EDUCATIONAL language; it is an
accident of its careful design that it became so popular.

;-D on ( C++ is the Fortran of the 90's ) Pardo

Piet van Oostrum

unread,
Jun 29, 1988, 6:18:22 AM6/29/88
to
In article <8...@garth.UUCP> smr...@garth.UUCP (Steven Ryan) writes:

Somebody else wrote
a book introducing vW2 grammars and concluding with a formal syntactic
and semantic definition of a small language. North Holland (of course) but
I don't remember authour or title.

Cleaveland, J. Craig & Uzgalis, Robert C.
Grammars for programming languages
New York [etc.] : Elsevier, 1977 * XIV, 154 p. : ill. ; 24 cm
Elsevier computer science library * Programming languages series ; 4

The only relation between Elsevier and 'North Holland' is that they are
located in Amsterdam, which is in the province of North Holland. As far as
I know they have nothing to do with the publisher of that name.

You might also look into:

M. Marcotty and H.F. Ledgard,
A sampler of formal definitions,
Computing Surveys vol 8, no 2 (June 1976)

Peter da Silva

unread,
Jun 29, 1988, 9:16:14 AM6/29/88
to
In article ... pa...@june.cs.washington.edu (David Keppel) writes:
> I would claim different: that the reasons that PASCAL are (was) so
> popular include:
> + Simplicity: can be implemented reliablly.

This is definitely #1. It was designed to be easy to implement.

> + Defintion: There is a good standard to adhere to.

Why doesn't anyone adhere to it, then? The MOST popular Pascal out there
isn't a proper superset of *any* of the Pascal standards.
--
-- `-_-' Peter (have you hugged your wolf today) da Silva.
-- U Ferranti International Controls Corporation.
-- Phone: 713-274-5180. CI$: 70216,1076. ICBM: 29 37 N / 95 36 W.
-- UUCP: {uunet,academ!uhnix1,bellcore!tness1}!sugar!ficc!peter.

Nick Crossley

unread,
Jun 29, 1988, 4:17:03 PM6/29/88
to
In article <8...@garth.UUCP> smr...@garth.UUCP (Steven Ryan) writes:
>Somebody else wrote
>a book introducing vW2 grammars and concluding with a formal syntactic
>and semantic definition of a small language. North Holland (of course) but
>I don't remember authour or title.

It is "Grammars for Programming Lnaguages", by J Craig Cleaveland and
Robert C Uzgalis, number 4 in the Programming Languages Series published by
Elsevier North Holland, 1977. An excellent book for those wanting to see more
of what 2-level grammars can do.

--

<<< standard disclaimers >>>
Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA
Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick

Isaac Rabinovitch

unread,
Jul 1, 1988, 3:24:52 AM7/1/88
to
In article <51...@june.cs.washington.edu>, pa...@june.cs.washington.edu (David Keppel) writes:
(In response to my asserstions about why Pascal is so popular.)

> + Simplicity: can be implemented reliablly.
> + Simplicity: can be understood effectively.
> + Quality: The language had years of thinking in it before it came
> into an implementation.
> + Straightforward: A compiler can do little optimization and produce
> good code.
> + Defintion: There is a good standard to adhere to.
The first three maybe apply to Pascal, but they apply even more so to
LISP! As for the last, well, the most widely used Pascal compiler
knowadays is Turbo....

>
> I think that these reasons (and others) are responsible for the
> vendors' choice of Pascal over Xyz.
You sort of unintentionally make my point here when you can't remember
the name of any languages that were seriously in the running against
Pascal. You say they "chose" Pascal, but what did they choose it
against? As with BASIC before it, and MS-DOS after it, Pascal won out
because it was a kind of software lots of people understood, or thought
they did.

Dick Dunn

unread,
Jul 9, 1988, 3:37:27 AM7/9/88
to

Some recent comments about Pascal's early history stray pretty far from
fact. Let me see if I can kill off some folklore.

> It's worth remembering that Wirth never meant the language to be *used*.

Emphatically *not* true! In the *original* report on the language, Wirth
cites its intended usage "both as a convenient basis to teach programming
and as an efficient tool to write large programs..."

> It was supposed to be a language for *thinking* about computing, not

> implementing systems...

This might have been applied to Algol 60 (tenuously perhaps, but not
incorrectly). It's just plain wrong for Pascal. See above, but also note
that the first Pascal compiler that was distributed outside ETH was
written in Pascal. Actually, Pascal is best viewed as the antithesis of a
gedanken language; it is an attempt to validate in practice the theoretical
work (primarily of Wirth and Hoare) of that period.

>...I've got early 70s Pascal books that use dialects


> of Pascal that were never even implemented, and never meant to be.

Doubtful, unless somebody else went off and invented a dialect he didn't
implement! Wirth's *first* version of Pascal, as defined in the original
report on the language, was implemented and *widely* distributed. There
were two revisions of the language. All three (original and two
revisions) had corresponding implementations which came from ETH. In
other words: If Wirth wrote about it, it got implemented.

(If you think otherwise, I'd like to know some characteristics of the
"dialects of Pascal" that weren't implemented.)

There was a bootstrapping process to get Pascal going--obviously the first
whole compiler wasn't written in Pascal. Wirth describes the process in an
early article--I think it was in SP&E. But he is careful to make the points
that (a) he wanted to get a real compiler for Pascal very early on, and (b)
it turned out that the easiest way to get there was a fast bootstrap, to
get a minimal compiler which would let the rest of the work be done *in
Pascal*.

The earliest compiler that I know of in the US appeared here around 71 or
72. It compiled the language from the original report--this language can
be identified by the "class" mechanism and dynamic allocation with the
standard procedure "alloc", plus having "alfa" as a standard *scalar* type.
The compiler for this first version of Pascal was written in Pascal--the
compiler itself was about 4200 lines of Pascal, with an assembly-language
support package of about 3000 lines (for the CDC 6000 series).

As for why Pascal gained popularity early on, it's easy: teaching! Wirth
is an "academic", and the first implementation of the language was on a
machine widely available (then) at large universities. The compiler was
efficient and reliable. The other languages available on the machine were
a good FORTRAN (but a poor language for teaching), an execrable Algol 60
(with a compiler of nominally five passes, if it didn't bomb out
sooner!:-), an orphan COBOL (after all, the 6x00's were scientific
machines), and an assortment of minor unsupported languages. Imagine the
situation if you're trying to teach a computer science course that would
require some programming with sophisticated data structures (i.e., some-
thing other than arrays:-) and/or interesting control structures (other
than counted loops and non-recursive procedure calls). Pascal is the ONLY
sensible choice...and lo, not only does the compiler work but the code it
generates is fast.
--
Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870
...Are you making this up as you go along?

Eugene N. Miya

unread,
Jul 9, 1988, 3:44:58 PM7/9/88
to
Well, this is generally right. I know other Pascal implementers
from that time read this group and they can comment. I will just say
that if any language lawyers are interested, I still have copies of
Pascal News from Andy Mickle back to No. 4. (I left at 18).

Also note that Niklaus left ALGOL 68 development
just at Thompson and Ritchie came from Multics.

Another gross generalization from

--eugene miya, NASA Ames Research Center, eug...@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Send mail, avoid follow-ups. If enough, I'll summarize."

Eliot Lear

unread,
Jul 10, 1988, 5:20:26 PM7/10/88
to
Just out of curiosity, does anybody know of any implementation of
Pascal that does NOT contain extensions either the I/O system or
to the O.S.?
0 new messages