🚀 go-pugleaf

In reply to some of Andy Walker's comments (which in turn were a reply to
my flippant remarks concerning the needless complexities of Algol68):

> The *formal* rules are complex.  Have you looked at the similar
> rules in C, Ada, PL/1, ML, ..., and even Pascal?

This remark assumes that C or Ada are proper comparisons to make.  I cordially
dislike all the languages mentioned in this comparison & would cheerful lob
brickbats at them, too.  But it doesn't make Algol68 a better language or less
complex.  (My benchmark would be ML.)

> They *did* focus on clean.

I guess this is just a matter of opinion.  Every Algol programmer I know
cheerfully concedes they don't understand the rules in detail or all their
probable interactions.  I don't call this clean.

I remarked on the dual control construct syntax.  I intended the remark to
be applied for the strange IF/CASE syntax rather than the begin/end 
abbreviation.  However, Andy comments:

> If it were not dual, which would you prefer?  Lots of parentheses,
> as in Lisp?  Or monstrosities like "2 * begin x+y end"? 

The answer is neither.  The necessity for "begin" and "end" is an artifact
or poorly chosen syntax.  The comparison I would use here is Pop11 which has
an Algol-like syntax without the dual control constructs or the necessity for
begin/end brackets.

I also commented on the well-known limitation of Algol68 of being unable to
return general procedures as results.  Andy asks:

> What limitations?  You are perhaps thinking instead of the fact
> that locally-constructed procedures tend to have narrower scope than one
> might like, which makes returning them less useful than one might hope;
> but that applies to *all* modes, and happens in C and Pascal as well.

I think we are talking about the same limitation here.  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.  In short, the 
failure to implement lexical binding according to (say) the lambda calculus.

Of course, C and Pascal are poor choices.  Why not choose an earlier language
such as Simula67, where no such restriction exists?  Other obvious choices
might be Pop11, Common Lisp, or Standard ML.  All of these languages, and
many other, implement lexical binding in its full glory without any
restriction.  Standard ML is an especially good comparison because it is
strongly typed.  Modula-3 is going o be another candidate.

Andy then attacks my remarks about apparent complexity as:
> *False* perception, gratuitously spread by ill-informed comments.

I don't think so -- although I admit my remarks were less than 100% serious.
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.

> Prediction:  in 5 years time, Pascal will be deader than Algol,
> and much less lamented.

We can dream :-)

Steve