Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: John Ames Newsgroups: comp.os.linux.misc,alt.folklore.computers Subject: Re: naughty Pascal Date: Mon, 5 Jan 2026 13:37:55 -0800 Organization: A noiseless patient Spider Lines: 71 Message-ID: <20260105133755.00005e21@gmail.com> References: <10iu02q$1029n$12@dont-email.me> <10iu3g7$11u10$3@dont-email.me> <10iutjt$1c0aq$2@dont-email.me> <79ScnZHy-uXnP8n0nZ2dnZfqnPadnZ2d@giganews.com> <4oycne7Wk4RQ6sj0nZ2dnZfqnPidnZ2d@giganews.com> <10j48fv$2t1h9$12@dont-email.me> <10j5qgf$3etcd$6@dont-email.me> <10j60bb$3hhps$1@dont-email.me> <7cadnTBwKKzA68r0nZ2dnZfqn_idnZ2d@giganews.com> <10jak55$13ji1$2@dont-email.me> <10jh3n1$3644m$1@nntp.eternal-september.org> <20260105115058.000054fc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Mon, 05 Jan 2026 21:38:03 +0000 (UTC) Injection-Info: nntp.eternal-september.org; posting-host="b2391d08a3fc6e672fef609ec53bb1a2"; logging-data="3448884"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bO5LLlQOwHfTxH7II8Tye2NSqiY6jfHY=" Cancel-Lock: sha1:hJMP8/Hl2fXKylwhb9WmtmBnRUM= X-Newsreader: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) Xref: csiph.com comp.os.linux.misc:80536 alt.folklore.computers:233213 On Mon, 5 Jan 2026 11:50:58 -0800 John Ames wrote: > > Actually, many systems programming languages have no I/O, the idea > > being that non-OS programs call the OS to do the I/O, and the OS > > interacts directly with the hardware. > > "Systems programming" usually implies implementation of an OS, though, > and IIRC that was the sense that Kernighan was using. Had to go back and double-check myself on this - his essay can be found at https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html for those who want to read it. He doesn't use "systems programming" at all, and his cited examples have to do with general applications rather than OS implementation. (Of course, the same limitations that plagued vanilla Pascal for that do it no favors in anything lower-level.) What he actually says is: "Pascal's built-in I/O has a deservedly bad reputation. It believes strongly in record-oriented input and output." "The I/O design reflects the original operating system upon which Pascal was designed; even Wirth acknowledges that bias, though not its defects. It is assumed that text files consist of records, that is, lines of text. When the last character of a line is read, the built-in function 'eoln' becomes true; at that point, one must call 'readln' to initiate reading a new line and reset 'eoln'. Similarly, when the last character of the file is read, the built-in 'eof' becomes true. In both cases, 'eoln' and 'eof' must be tested before each 'read' rather than after." "There is no notion at all of access to a file system except for pre- defined files named by (in effect) logical unit number in the 'program' statement that begins each program. This apparently reflects the CDC batch system in which Pascal was originally developed. [...] Most imple- mentations of Pascal provide an escape hatch to allow access to files by name from the outside environment, but not conveniently and not standardly." "But 'reset' and 'rewrite' are procedures, not functions - there is no status return and no way to regain control if for some reason the att- empted access fails. [...] This straitjacket makes it essentially im- possible to write programs that recover from mis-spelled file names, etc." "There is no notion of access to command-line arguments, again probably reflecting Pascal's batch-processing origins." AFAICT some of those may have been solved by the time the ISO standard was finalized (the standard as I can find it online is much more of a "committee deciding on points of dispute" document than a language ref and I can't be bothered to dig that deep.) But none of these points are matters where the programmer is "helped" by delegating anything to the OS/runtime environment - indeed, if anything the opposite is true, and the programmer is needlessly bound to assumptions carried over from one specific environment (batch-oriented, record- or line-oriented.) And Kernighan's final summation certainly held true for the original flavor of the language, however many variants over the years have had their own (non-standard) fixes: "The language is inadequate but circumscribed, because there is no way to escape its limitations. There are no casts to disable the type- checking when necessary. There is no way to replace the defective run- time environment with a sensible one, unless one controls the compiler that defines the 'standard procedures.' The language is closed. [...] Because the language is so impotent, it must be extended. But each group extends Pascal in its own direction, to make it look like what- ever language they really want."