Or why I don't like documenting my code. From a letter to John Cowan:

I was documenting a program of mine today, and in the process of explaining its utility, I came to realise not only that it's solving a different problem to what I'd originally intended, but that it touches on some subjects that may warrant your attention.

The program in question is called "ppr" (source: ppr.py), an improved stream editor, and I started its documentation as follows:

Given a command list, for each line of the input ppr will send the line through the command list, as if it were a piped list. Each command must be separated by a semi-colon, and may optionally take a single argument. For example, the ppr command "from> ; reduce; @; quot" can be thought of as though it were a mini-shell script along the lines of "from '> ' | reduce | at | quot".

I'd already implemented it in 180 lines of Python, so when I thought about my analogy, I was perplexed and amused that I was able to recreate the program in eleven lines of bash, and that even that is redundant in most cases:

#!/usr/bin/env bash
# ppr - An extensible stream editor

while :
   read line
   if [ ! $? = 0 ]; then
   eval "echo $line | $1"

How this relates to sre is that I feel it can be done in the same way. Let's take one of the examples from the sam manual:

, x/[A-Za-z_][A-Za-z_0-9]*/ g/n/ v/../ c/num/

- http://www.eecs.harvard.edu/~rsc/plan9-unix.html

Surely that's very similar to:

cat input | \
   findall '[A-Za-z_][A-Za-z_0-9]*' | \
   grep n | \
   grep -v .. | \
   sed 's/.*/num/'

The difference being that the pipeline above doesn't replace the text, it only greps it out and acts on it. Well fine, but a modified version of my eleven line shell script could probably be made to do that.

But I don't think that ppr and sre etc. are obsolete: as I said, I think they're just solving a different problem to the one we're thinking about. The reason why I prefer ./ppr 'from> ; reduce; @; quot" file over cat file | from '> ' | reduce | at | quot is that a) I'm able to use my own namespace, and b) the syntax of ppr's command line is much more comfortable with respect to quoting levels and so forth. Therefore I posit that what we're solving is a problem of namespaces and syntax, not of better stream editors, and that perhaps given that clarification there may be better routes forward.

Sean B. Palmer