Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!warwick!nott-cs!piaggio!anw From: anw@maths.nott.ac.uk (Dr A. N. Walker) Newsgroups: comp.lang.misc Subject: Re: Re: Algol68 (and standards diatribe) Message-ID: <1991Apr29.172123.2904@maths.nott.ac.uk> Date: 29 Apr 91 17:21:23 GMT References: <1991Mar28.011025.16337@ico.isc.com> <2400045@otter.hpl.hp.com> Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker) Organization: Maths Dept., Nott'm Univ., UK. Lines: 107 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