haim@taichi.uucp (24122-Haim Kilov(3786)m000) (08/10/90)
Algol-60 (and even 68) - as somebody remarked - was a great improvement over its successors. Starting with decent control structures, clean programs, _much_ better language specifications (recall BNF?), including clear separation between "syntax" and "semantics", etc. Of course, Algol(s) did not have i/o, overflows, etc., but these clearly are implementation-specific properties. (BTW, the Algol68 format definitions do exist, but are too complex... - so there is a good reason for not including such things in the language kernel). Separate your concerns - don't put kernel and implementations into one box. Haim Kilov haim@bcr.cc.bellcore.com
anw@maths.nott.ac.uk (Dr A. N. Walker) (08/15/90)
In article <91@towernet.UUCP> haim@taichi.UUCP (24122-Haim Kilov) writes: [...] >Of course, Algol(s) did not have i/o, overflows, etc., but these clearly >are implementation-specific properties. (BTW, the Algol68 format definitions >do exist, but are too complex... - so there is a good reason for not >including such things in the language kernel). Well, you're right about formats. Basically, they add very little to the C "printf" mechanism in return for a great wodge of syntax; worse, because formats can contain statements which can in turn contain formats, etc., they complicate lexical analysis no end. So, formats are usually the first thing to go in subset compilers. However, Algol 68 has excellent I/O specifications. The model, that a file is a "book" with pages, lines and characters which can be read from or written to, encompasses most if not all real file systems (cards, paper tape, disc, mag tape, etc). The "channel" capabilities include, for example, filtering possibilities to convert between ASCII and EBCDIC, error handling, and the like. Formats are not the only, nor even the most usual, way of using this model. Algol predates Unix, so it adapts (successfully, in my opinion) to the world outside, rather than using the much simpler Unix model, which then requires everything to look like a Unix file. Algol also has at least part of "overflows, etc.". Firstly, *some* errors [eg, reading a non-digit when inputting a number] can be trapped. Essentially, this applies to any "software" error. Secondly, the effects of "hardware" errors, such as overflow, are undefined -- indeed, computers are so varied that any defined action would be impossible to implement efficiently in general -- but there is no reason why a sympathetic environment might not hand control to a user-defined routine. Thirdly, you can always roll your own. For example, something like OP * = (INT a, b) INT: IF REAL rab = a * (REAL) b; ABS rab > maxint THEN error ("overflow in multiplication"); 0 ELSE ROUND rab FI gives you a "safe" integer multiplication (by doing it in reals first). Of course, you could write much cleverer things in the "THEN" part. -- Andy Walker, Maths Dept., Nott'm Univ., UK. anw@maths.nott.ac.uk
haim@taichi.uucp (24122-Haim Kilov(3786)m000) (08/27/90)
About Algol 68:
However, Algol 68 has excellent I/O specifications. The model,
that a file is a "book" with pages, lines and characters which can be
read from or written to, encompasses most if not all real file systems
(cards, paper tape, disc, mag tape, etc). The "channel" capabilities
include, for example, filtering possibilities to convert between ASCII
and EBCDIC, error handling, and the like. Formats are not the only,
nor even the most usual, way of using this model. Algol predates Unix,
so it adapts (successfully, in my opinion) to the world outside, rather
than using the much simpler Unix model, which then requires everything
to look like a Unix file.
Algol also has at least part of "overflows, etc.". Firstly,
*some* errors [eg, reading a non-digit when inputting a number] can
be trapped. Essentially, this applies to any "software" error.
Secondly, the effects of "hardware" errors, such as overflow, are
undefined -- indeed, computers are so varied that any defined action
would be impossible to implement efficiently in general -- but there
is no reason why a sympathetic environment might not hand control to
a user-defined routine. Thirdly, you can always roll your own. For
example, something like
Yes, I agree with the above (posted by Dr A. N. Walker). My more general
point was to _praise_ rather than to criticize Algol 68. More particularly,
however, I feel that Algol 68 contribution is underestimated irrepsectively
of whether it does or does not have formats or files. The reasons of
this were many, one of which (wrong) -- the difficulty of the revised
report.
And yes, formats are usually the first candidates for subsetting. Files
(books) are the next.
Who recalls Algol 68 now when "everybody" talks about abstract data types
and other good programming practices? Algol 68 does not encapsulate
"properly" because, e.g., you see the implementation and can access
your type in an unanticipated manner (so it is not too "abstract"), -
but, still, with a minimal amount of discipline programming becomes so
much easier. It's a pity the language is (sort of) dead...
-Haim Kilov
haim@bcr.cc.bellcore.comkinnersley@kuhub.cc.ukans.edu (Bill Kinnersley) (12/19/90)
In article <1990Dec13.084916.15659@ariel.unm.edu>, prentice@hydra.unm.edu (Colston Chandler PHYSICS) writes:
:
: Whatever did happen to Algol? You see alot of the old ACM algorithms
: programmed in it and it looked rather interesting. I can remember
: seeing satellite ephemeris programs written in it 20 years ago, but you never
: hear of it anymore.
:
Algol suffered some unfortunate adverse publicity when Pascal came out,
and was forced underground. However it has been kept alive all these
years by a small but dedicated network of users. Sorry I can't tell you
who they are--in the spirit of data hiding, each of us only knows the
names of two others.
Under our care Algol has continued to grow. The number of reserved
words is now 10,523, and the syntax diagrams are three-dimensional.
The latest version is Algol-88, but an object-oriented derivative
called Algol:= is under active development.
To appreciate fully the features of Algol-88 you must be aware of some
things about the old Algol-68. Algol-68 was written in two separate
styles, one for publication and one for actual programming. With the
advent of desktop publishing this is no longer necessary, and Algol-88
programs are now entered directly in Times-Roman, with reserved words
in Helvetica Bold.
Data types supported are integer, real, complex, quaternion, character,
string, sentence, paragraph, stream, list, record, tape and compact disk.
Among the features of Algol-68 criticized as too complex was the
loop construct, for-from-by-to-while-do-od. In fact it had not
reached its full potential, and in Algol-88 has the more general form
for-from-by-to-with-while-using-do-od-until. The basic conditional
construct has been expanded to if-then-elif-unless-yet-ontheotherhand-fi.
In the interest of simplicity we have abolished the goto.
Algol-88 has extensive support for multiprogramming. Processes may be
lightweight, heavyweight, bantamweight or overweight, and they communicate
via semaphores, monitors, message queues, interrupts and exceptions,
not to mention shared memory and rendezvouses. There is something for
everyone in Algol-88.