Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!clyde!watmath!watnot!watmum!gvcormack
From: gvcormack@watmum.UUCP (Gordon V. Cormack)
Newsgroups: net.lang.c,net.lang.pascal
Subject: Re: I/O in Algol (was I/O in Pascal)
Message-ID: <564@watmum.UUCP>
Date: Sat, 2-Aug-86 07:42:21 EDT
Article-I.D.: watmum.564
Posted: Sat Aug  2 07:42:21 1986
Date-Received: Sat, 2-Aug-86 23:39:23 EDT
References: <2222@brl-smoke.ARPA> <7014@boring.mcvax.UUCP>
Organization: U of Waterloo, Ontario
Lines: 31
Xref: mnetor net.lang.c:5541 net.lang.pascal:360

> ...  Unfortunately, I/O libraries are not something that can be
> tacked on later.  I/O affects the definition of the language.  This is
> one of the most serious problems with the languges in the Algol
> tradition.  There is a tendency to think I/O is a detail unfit for
> computer scientists, which can be left to the "standard prolog".

Algol 68 treats I/O at great length.  I think it is more in the
"algol tradition" than Pascal, which is best characterised as
the anti-algol.

Algol 68, unlike Pascal, is sufficiently extensible to do a reasonable
(if not great; but then C is hardly great) job of defining routines
like printf.  For example, the following routine gives something
like what is needed:

MODE PRINTABLE = UNION(INTEGER, REAL, ... )

PROC printf = ( [] CHAR f, [] PRINTABLE ) VOID : BEGIN ... END

printf(" %d  hi there %f \n", (123, 0.123))


Over the past decade, we have seen endless discussions comparing
brain-damaged languages like Pascal and C, and the design of the
Ada, all without learning from the successes (and mistakes) of
Algol 68.
-- 
Gordon V. Cormack      CS Department, University of Waterloo
uucp:  { allegra, decvax, ... }!watmath!gvcormack
csnet: gvcormack%watmum@waterloo
cdn:   gvcormack@mum.waterloo.cdn