Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!otter.hpl.hp.com!otter!sfk
From: sfk@otter.hpl.hp.com (Steve Knight)
Newsgroups: comp.lang.misc
Subject: Re: Re: Algol68 (and standards diatribe)
Message-ID: <2400047@otter.hpl.hp.com>
Date: 3 May 91 10:54:46 GMT
References: <1991Mar28.011025.16337@ico.isc.com>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 65

Well, I'll make this my last posting on Algol68, methinks, to comment on a
few small points made by Andy Walker.

> He flippantly (his claim) tosses more brickbats at the Algol committee,

This certainly wasn't my intention -- the language, yes, the committee, no.
Apologies to all concerned if my message read that way.

> The complexity of coercions is inherent. [Argument deleted]

The obvious comparison is with Standard ML.  It implements variables as
refs, exactly as Algol68, without the coercions.  It is a good, workable
system.  In the case of arithmetic, interestingly enough, SML does implement
a form of type coercion through overloading the arithmetic operators.  

So whilst the general point Andy makes is valid, SML is working proof that
you don't require the complicated coercion rules in strongly typed languages.
I don't think this has anything to do with SML's polymorphic type 
system -- which would make this an invalid comparison.

On the topic of procedural results, Andy states:
> There is no such restriction (as I stated in my previous posting).
He supplies this program:
	(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)))))
This indeed shows that I overstated the restriction (whoops!).  However, the
salient feature of this program is that the procedure is invoked within the
scope of "x".  The restriction I was trying to capture should be extended
to include an invocation of the procedure outside the scope of the variable it
"captures".  A simple example in ML would be
    fun K x = fn y => x;
    val one = K 1;
Any invocation of "one" would involve referring to an out-of-scope local.
As I understand it, this is the serious restriction in Algol68 -- although 
I didn't accurately state it.

> 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.

True.  The comparison that people should make is with Standard ML, which
is formally specified, also.  Draw your own conclusions.

Incidentally, I sincerly hope that no other readers of my
letters thought it belittled the work of the Algol68 committee!  I also hope
it is fair to criticise a language like Algol68 for being "apparently 
complex" without being thought to take pot-shots.

> 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. 

A cheap shot.  The point I was making is one of "apparent" complexity rather
than genuine complexity.  Berating me with my own point makes me feel
rather tired.  Sure, in real use the complexity of Algol68 rarely bites.
Just like in Lisp, the parentheses quickly fade from view.  But Lisp gets
knocked for its visual ugliness & Algol for its complex rules.  Whether you
think this is "fair" depends on whether you are trying to promote the 
language or understand its relative lack of success.

Steve