Xref: utzoo comp.lang.misc:7295 comp.arch:21890
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!uw-beaver!ubc-cs!alberta!herald.usask.ca!zaphod!bobd
From: bobd@zaphod.UUCP (Bob Dalgleish)
Newsgroups: comp.lang.misc,comp.arch
Subject: Re: Algol68
Message-ID: <4217@zaphod.UUCP>
Date: 5 Apr 91 22:14:00 GMT
References: <9168@castle.ed.ac.uk> <4202@zaphod.UUCP> <801@taniwha.UUCP>
Organization: Develcon Electronics Limited,Saskatoon, SK, Canada
Lines: 55

In article <801@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes:
>In article <4202@zaphod.UUCP> bobd@zaphod.UUCP (Bob Dalgleish) writes:
>>Pascal was designed by Wirth after he got disgusted with the rapidly
>>growing size and complexity of the Algol68 effort.  I gave up in disgust
>I did and Algol68 implementation as my MSc project, almost 10 years ago
I'm impressed.
>now (I wish I'd had C to implement it in - it might still be useable :-)
>I always had the idea that what Wirth did was implement all the 'easy'
>stuff in Pascal.
How do you mean?

I certainly know that the use of VW grammars went to
various people's heads, and that they decided it might be easier to
implement some of the runtime in VW grammars.  (I understand that VW
himself completed a specification for the run-time in his two-level
grammar; it was at least as hard to read as the syntax).

>>overloaded operators, partial parametization, and array slices explored

>Actually most of this stuff wasn't that hard to implement, what I found
>really interesting was reading the papers being written by the people
>implementing Ada - they were solving many of the same problems (and making
>many of the same mistakes) that the Algol68 implementors had solved a
>decade before - I think that a lot was learned from Algol68 in the field
>of language design and a lot was missed in actual implementation.
Agreed -- there is nothing hard about implementing an NP-hard algorithm;
it just takes a lot of nerve to explain to a programmer that his
three-hundred line program will take until next Tuesday to compile
because he used a seemingly innocuous form of overloading.  The
pathological cases cannot be readily recognized by the compiler until
you run out of CPU time.

>In my opinion the major thing 'wrong' with Algol68 is that it is not easy to
>approach with modern compiler tools - modern language designers tend to
>choose grammers that are lr0 (or slr/whatever) because they want them to
>go through yacc. Algol68 really has 2 grammers embedded inside each other
>(expressions and parentheses) you can't parse one untill you've parsed 
>the other.
Hank Boehm at the University of Alberta in Edmonton put together a neat
method of recognition.  He constructed two slr(0) grammars, one to be
applied left to right, and the other to be applied by reading the source
backwards.  When the I/O system was added afterwards, his parser failed.
I also saw some work on attribute grammars, which were well over my
head.

>The report(s) are hard to read, you keep getting that same sort of 'aha!'
>reaction you get in v6 unix when you finally figure out what's ment by
>"you're not expected to understand this".
Much like a religious book!  However, I never really got comfortable
with the semidecidability of language construction: illegal constructs
would often turn into productions which had no valid reduction (excuse
the hashed metaphor).
-- 
-- * * * Remember: I before E except after DALGL * * *--
Bob Dalgleish		bobd@zaphod.UUCP