From: Douglas McIlroy <douglas.mcilroy@dartmouth.edu>
To: TUHS main list <tuhs@tuhs.org>
Subject: [TUHS] Re: Perkin-Elmer Sort/Merge II vs Unix sort(1)
Date: Tue, 21 Jan 2025 16:53:51 -0500 [thread overview]
Message-ID: <CAKH6PiWYYkJL-fc9jJnys91eCS2P+BcqASwmmbK3kHwQycpcDw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
All-in-one vs pipelined sorts brought to mind NSA's undeservedly obscure
dataflow language, POGOL, https://doi.org/10.1145/512927.512948 (POPL
1973). In POGOL one wrote programs as collections of routines that
communicated via named files, which the compiler did its best to optimize
away. Often this amounted to loop jamming or to the distributive law for
map over function composition. POGOL could, however, handle general
dataflow programming including feedback loops.
One can imagine a program for pulling the POGOL trick on a shell pipeline.
That could accomplish--at negligible cost--the conversion of a cheap demo
into a genuine candidate for intensive production use.
This consideration spurs another thought. Despite Unix's claim to build
tools to make tools, only a relativelly narrow scope of higher-order tools
that take programs as dara ever arose. After the bootstrapping B, there
were a number of compilers, most notably C, plus f77, bc, ratfor, and
struct. A slight variant on the idea of compiling was the suite of troff
preprocessors.
The shell also manipulates programs by composing them into larger programs.
Aside from such examples, only one other category of higher-order Unix
program comes to mind: Peter Weinberger's lcomp for instrumenting C
programs with instruction counts.
An offshoot of Unix were Gerard Holzmann's tools for extracting
model-checker models from C programs. These saw use at Indian Hill and most
notably at JPL, but never appeared among mainstream Unix offerings. Similar
tools exist in-house at Microsoft and elsewhere. But generally speaking we
have vey few kinds of programs that manipulate programs.
What are the prospects for computer science advancing to a stage where
higher-level programs become commonplace? What might be in one's standard
vocabulary of functions that operate on programs?
Doug
[-- Attachment #2: Type: text/html, Size: 2351 bytes --]
next reply other threads:[~2025-01-21 21:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-21 21:53 Douglas McIlroy [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-01-17 18:12 Douglas McIlroy
2025-01-18 4:29 ` G. Branden Robinson
2025-01-17 17:23 [TUHS] " Diomidis Spinellis
2025-01-17 19:10 ` [TUHS] " Bakul Shah via TUHS
2025-01-17 19:35 ` Marc Rochkind
2025-01-18 14:51 ` Diomidis Spinellis
2025-01-18 15:16 ` Larry McVoy
2025-01-18 15:40 ` Paul Winalski
2025-01-18 16:54 ` Marc Rochkind
2025-01-19 3:45 ` sjenkin
2025-01-18 16:00 ` Bakul Shah via TUHS
2025-01-18 16:25 ` Tom Lyon
2025-01-18 17:07 ` ron minnich
2025-01-18 19:39 ` Marc Rochkind
2025-01-17 20:07 ` John Levine
2025-01-18 4:46 ` Dave Horsfall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKH6PiWYYkJL-fc9jJnys91eCS2P+BcqASwmmbK3kHwQycpcDw@mail.gmail.com \
--to=douglas.mcilroy@dartmouth.edu \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).