🚀 go-pugleaf

Here's a total flame.  No
I strongly disagree that basic sequential I/O should go into a language.
Here at Xerox, could you have anticipated these I/O methods, or would
you like to change our compiler every time we prototype a better I/O
system (which we've done several times already, with new modules)?

* Multi-national strings, with 8-bit font codes and 8-bit character
codes
* A more efficient type of string, that is used mostly for network
servers
* Routines to mimic C's printf() and putchar() functionality
* The ability to write to a random window or subwindow on the screen.
* Formatting routines that convert not just numbers, but dates,
processor IDs,
    and sockets into a myriad of forms.

If you feel we must standardize "because I/O is so basic to computing"
then we must not understand the basics, which I think is a fair
statement.  The basics are redefined every year.

It is amusing to note that only 1/3 of the systems we build here use
even the CHARACTERS and STRINGS defined by the language [MESA].  The
others use their own, and essentially waste the compiler constructs for
creating such objects (luckily MESA doesn't have i/o or string
manipulation primitives, which would have surely gone to waste).

Thus, any I/O constructs that were built into the language, would
presumably operate on types already in the language, and would have gone
to waste in 2 out of 3 of our systems.  The End-to-End argument seems to
apply here:

"Functionality, placed at a low-level in a system [the compiler] may be
redudant or of little value when compared with the cost of providing
them at that low level.  Low-level mechanisms to support these functions
are justified only as a performance enhancement"

[since many clients must reimplement this functionality anyway]

					Don