Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.misc
Subject: Re: Late Bloomers Revisited
Summary: Algol: NO pointers, NO structures, etc...
Message-ID: <1560@aber-cs.UUCP>
Date: 1 Jan 90 21:52:35 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 51

In article <85180@linus.UUCP> gmitchel@mitre.org (George Mitchell) writes:
    In article <18510@netnews.upenn.edu> farber@linc.cis.upenn.edu (David Farber)
    wrote:
    >In hinesight it was the right path; PL/1 was not a easy
    >language to compile for but there was NO other route.

Actually PL/1 is not a bad language. Exception handling is revolting,
arithmetic is *CRAZY*, and I/O and tasking a bit less so, syntax at times
odd, but for systems programming is not bad at all.

Based pointers, areas, reducible procedures (nonstandard), records, UNSPEC(),
etc... The only thing I really ever missed was a type naming facility,
because LIKE only applies to records (yes, I used to create dummy BASED
records as type prototypes...). The macro processor was an incredible beast,
better stay out of that.

The real problem with PL/1 for system programming is that some of the
ridiculous parts of the language, notably exceptions, greatly complicate the
procedure call protocol, slowing it down quite a bit, all the funny parts
make the compiler slow and bulky, and that in the flagship implementation,
IBM's, these problems were especially bad.

The IBM PL/I implementations, both optimizing and debugging, are easily the
worst around, both as to compiler quality and compiled code quality; the
best PL/1s IMNHO are the Multics one (of course!), and the Univac 1100 one.
    
    Why not ALGOL?

I assume you mean Algol 60; Algol 68 (which is later than Multics, so could
not have been used) has been used with great success to write several
operating systems.

Well, the reasons are obvious: no pointers, no records (BCPL has no records,
that's why C exists... :->), no "unsafe" operations, etc... Just not a
systems programming language.

Let me immediately defuse a counterexample: the "Algol" used to write the
Burroughs kernel is not really Algol 60, actually there are two Algols, one
for user programs and the other for systems programs; also the hardware is
*very* Algol oriented -- Multics is not an Algol like system at all; it is
all about dynamic allocation, shared memory, sophisticated pointer mangling.

As a fun note, people have been using Fortran for systems programming, e.g.
PR1MOS (they switched to a kind of PL/1 later on), and a very good Algol 68
compiler from France. They were both heroic efforts, given the lack of
pointers and records.

-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk