by Darius Kazemi, March 24 2019
RFC-83 is titled “Language-Machine for Data Reconfiguration” by R. H. Anderson, Eric Harslem, and John Heafner of RAND.
The technical content
This RFC is a followup to RFC-80. The Form Machine is discussed at length here, though it's been changed conceptually since RFC-80 into a syntax-driven interpreter, rather than a compiler/executor. (I am not sure what the fine difference is here but they call it out right at the start!)
The Form Machine is given an input address range, and an output address range, and a pointer to the “forms” which are a set of grammars for data transformation. Then, as it processes data from the input memory, it spews transformed data into the output range. It is, in modern terms, an I/O stream.
There is a LOT in this paper, but the examples are somewhat illustrative. Check out the following definition of a replacement rule:
What this does is: when given a bunch of ASCII, it spews out the first 10 characters of ASCII unaltered, then the EBDIC-formatted characters for
LIT, then 70 more characters of ASCII unaltered. (Recall that EBDIC is a kind of ASCII competitor at this point, used by many computer systems.)
You can make rules like: if given a bunch of ASCII, calculate the length of the ASCII and then output the length as an 8-bit field then followed by the unaltered ASCII. This would allow you to easily convert the data from your program into something that, for example, the NCP could send to the IMP.
This seems really useful.
This is all formally written up in The Data Reconfiguration Service—an Experiment in Adaptable, Process/Process Communication, a July 1971 paper by the authors of this RFC plus a number of other RFC series contributors.