🚀 go-pugleaf

In article <2400045@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight)
writes:
[Lots of things.  He previously compared Algol unfavourably to Pascal;
 he then grumbles that my reply only compared Algol with languages he
 "cordially dislikes" (including ML, which is his "benchmark").  He
 flippantly (his claim) tosses more brickbats at the Algol committee,
 and five times refers to Algol's "apparent" complexity.]

The complexity of coercions is inherent.  As a mathematician, I want to
"add" all sorts of things:  integer, real and complex numbers, fractions,
vectors, matrices, sets, strings, sequences, etc....  As a computer
programmer, I want to use the addition operator for constants of all
these different types, in many combination, variables, functions returning
pointers to such variables, etc., and I want to be able to define such
an operator [either as a variant of "+", or at least as a function
called "add_vect" or similar] in order to "add" other things that may
occur in my code.

	The *situation* is complicated.  If the complication is put into
the language and the compiler, then the user can be given a nice simple
interface, so that as well as

	2 + 2

I can write (for instance)

	j + k		[where "j" and "k" are integer variables],
	A + B		[where "A" and "B" are conformable matrices],
	x + i y + 1	[where "x" and "y" are real variables] and
	"hello" + world [where "world" is a function returning a pointer
		to a function returning a string]

As you remove the ability to declare operators, and to coerce objects,
the rules become simpler, and the programming gets correspondingly more
tedious, until you have to write the penultimate example above as

	complex_add (complex (deref (x), deref (y)), complex (real (1), 0.0))

Algol is easy to use only because its formalisation is complicated.

>I remarked on the dual control construct syntax.  I intended the remark to
>be applied for the strange IF/CASE syntax [...]

	What's strange about it [except that "end_if" is spelled "fi"]?

>			 The necessity for "begin" and "end" is an artifact
>or poorly chosen syntax.

	Historical necessity of the days when most programs were prepared
on card punches which had only upper case letters, digits, +, - and a few
punctuation symbols, and only one style of parenthesis.  These days, when
almost every terminal has parentheses, brackets and braces, several quote
symbols, and much punctuation, it is much easier to design languages which
use few words.  Whether one *should* do so is a matter of taste.

>I also commented on the well-known limitation of Algol68 of being unable to
>return general procedures as results.  [...] I was alluding to
>the restriction in Algol68 of being unable to return procedures whose scope
>includes non-global variables declared in a wider scope.

	There is no such restriction (as I stated in my previous posting).
The following program [in which "q" returns a procedure which involves the
non-global "x" declared in a wider scope;  this procedure is assigned to
"p", which is invoked after "q" has gone out of scope] compiles and prints
3.2 on this computer [Sun 3/260]:

	(REAL dummy;
	   (REAL x;
	      (PROC (REAL) REAL p;
		 (PROC q = PROC (REAL) REAL: (REAL a) REAL: x + a; p := q);
	       x := 1.2; print (p (2)))))

It is true that Algol is cautious about scope-safety of assignments, and
about scopes in general.  As a very large fraction of the non-trivial bugs
that I see as a teacher would be caught by this caution if it applied to
other languages, I have no objection to it.  Charles Lindsey, in another
reply to SFK, has pointed out that the utility could be extended with no
loss of safety by partial parametrisation.

>My criticisms come from working with languages that adhere to the same overall
>design principles as Algol68 without the seeming complexity.  Given this
>experience one can't help but ask "why is Algol68 so different & so apparently
>complex?"  There doesn't appear to be any answer beyond the historical
>details of who was on the committee & their personal aims.

	Almost all languages start out as one- or two-person projects,
"defined by DMR's compiler", so to speak.  If the language becomes popular,
as did C, then DMR's compiler is no longer enough;  the language is ported
to a wide variety of computers, and used for a wide variety of purposes,
many of them unintended by DMR.  If the language remains popular, then
discrepancies between implementations start to loom large, and an effort
is made to standardise the language.  At this point, what may have seemed
to be a nice, simple language suddenly becomes more apparently complex;
C is again a good example.  If you compare *any* language which has been
properly standardised with Algol, and especially *any* language whose
standard is expressed formally, you might start to appreciate the [now
23 years old] achievement of Algol.  A few other languages have started
out as committee efforts;  Ada is the prime example.  Compare and discuss.

	Of course, if you persist in comparing the formal definition of
Algol with a glossy brochure describing the best side of your favourite
language, you get a misleading impression.  Try reading some Algol
glossy brochures.

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