Path: utzoo!attcan!uunet!mcsun!ukc!keele!nott-cs!piaggio!anw
From: anw@maths.nott.ac.uk (Dr A. N. Walker)
Newsgroups: comp.lang.misc
Subject: Re: Algol
Message-ID: <1990Aug15.154636.21982@maths.nott.ac.uk>
Date: 15 Aug 90 15:46:36 GMT
References: <1990Jul21.004616.649@Stardent.COM> <388@e2big.mko.dec.com> <25630@cs.yale.edu> <2404@l.cc.purdue.edu> <91@towernet.UUCP>
Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker)
Organization: Maths Dept., Nott'm Univ., UK.
Lines: 47

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