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 : do read line if [ ! $? = 0 ]; then break fi eval "echo $line | $1" done
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.