🚀 go-pugleaf

In article <1124@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman)
writes:

>It will take a great deal of evidence to convince me that the Algol
>committee members were so ignorant that they actually argued over the
>implementability of anything in Algol 60.  There is nothing in the
>language that any knowledgeable person would doubt can be implemented.

	Whoa!  There are two different meanings of "implement" and three
different meanings of "Algol" that are being mixed up, if not actually
confused.  When this started, DG asserted that Algol was [essentially]
intended as a clever assembler, and that static typing was intended as
an efficiency hack.  In response to my queries, he asserted that he
intended the earliest Algol tradition [ie Algol 58, or IAL], denied
intending Algol 60, and couldn't remember whether he'd actually read
the Algol 58 report.  ["I rest my case m'lud."  However, I cannot resist.]

Algol 58:  Never [?] implemented, except in the Jovial realisation,
	probably unimplementable, certainly not designed with machine
	efficiency in mind.

Algol 60:  Intended primarily as a descriptive language, and certainly
	not efficient (call by name, dynamic typing [:-), but consider
	whether "2^-j" is integer or real, and whether "2" is an integer
	or a label], dynamic own arrays).  No "clever assembler" of the
	period would have included recursive procedures, or dynamic
	arrays, for example, as indeed Fortran didn't.  I deduce that
	it was not designed with efficiency in mind;  this is confirmed
	in the pages of Algol Bulletin and in histories of the period
	(where the whole venture sounds utterly chaotic).

Algol 68:  Designed to be *run* efficiently, with essentially *no*
	regard to compilability other than "possible in principle".
	No-one with a real compiler in mind would have designed a
	language that needs at least three passes and that cannot
	be adequately lexed by a finite state machine.  There is much
	in Algol 68 that would make any pre-doc compiler-writer despair;
	the committee satisfied itself that parsing was technically
	possible, that code generation was technically possible, and
	assumed that compiler technology would do the rest.  You only
	have to look at the coercion engines or at the operator
	identification to assure yourself that highly intelligent
	people could spend a long time wondering whether something
	was compilable, and indeed some ambiguities were detected only
	at a very late stage.  Results:  Algol 68 is a dream to write,
	a nightmare to compile, and a bat-out-of-hell to run (given a
	good compiler!).


>							     But it is
>just wrong to claim that they were trying to design a general notation
>for describing algorithms without regard to implementation.

	Well, they were thinking about *computing* algorithms, and
more specifically, *numerical* algorithms.  Having an eye on what
real computers were used for is different from having an eye on how
to turn a notation into practical code.

>							      If that
>were true they surely would have included sets, strings, graphs,
>concatenatable sequences and other useful things in the language.

	Strings and other useful things *are* in Algol 60 [2 out of 5
isn't bad!].  In 1960, the other things were scarcely recognised as
being useful:  my undergraduate degree [1961-64] included *no* mention
of sets or graphs or concatenation;  as an innovation, 5 or so lectures
on computing [Edsac Autocode] were included in the NA course.

	By 1968, the emphasis was on orthogonality and composition from
a small number of primitives.  Graphs, for example, scarcely count as
primitive -- but it is straightforward to write a graph-handling package
in Algol.

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