Expansion of #, and the "residential" question.

[JONL at PARC-MAXC]

As one who has "crosssed the barrier" between the MacLisp/Interlisp
style of programming, let me proffer an opinion as to what the
"residential" style means.

"Residential" means that files, in the sense of structured
words/bytes on some disk volume, don't really exist!

At first I was taken aback when I found out that Interlisp's
FILEPKG only incidentally dealt with "files" in the above sense.
A "file" is primarily viewed as an agglomeration of functions,
variables with initial values, macros, typed-definitions and so on.
The problems observed to stem from the many-to-one mapping of
READ are irrelevant, and somewhat orthogonal to this issue; in fact,
Interlisp does have a #. feature in its reader -- control-Y -- and
although it doesn't have a general input-radix feature, you can
type numbers in octal or decimal and no attempt is made to remember
how it was read in.

Of course, real disks do exist, and the FILEPKG will incidentally 
"preserve" a "residential file" by prettyprinting a full snapshot of
it onto such a volume; and also the compiler will produce
a compiled disk file upon request.  One thinks of these as information
interchange media, rather than as the real source of the programs
contained therein.

The paramount issue, as raised by ALAN, is that in the MIT world,
one just never, but never, allows the machine-generated prettyprint
of his functions to be stored on disk file, or to be used for much
of anything other than casual inspection at the terminal.  Even
the style of editing isn't the critical factor (at lest for Interlisp-D
users -- tant pis for Interlisp-10), for there is a moderately good
E-style input buffer (E is the Standford editor which inspired EMACS)
called TTYIN.

In fact, I'd like to take this opportunity to praise the Display-based
structure editor of Interlisp-D, upon which I've become increasingly
dependent recently.  The combination of bitmap-display, multiple-fonts,
interface to old-style Interlisp structure editor, mouse-oriented
new-style operations, TTYIN keyboard interface, and so on, make this
the best editor by far, for LISP programs and data, of all those I've
ever seen.

Footnote:  there were a few comments about how semi-colon comments
    are "lost" by the READer; in Interlisp, the corresponding notion
    is asterisk comments, and the are not lost, but incorporated bodily
    intot he source code.  This has two implications: the reader's
    macrocharacter scheme is modified so taht 'FOO reads in as (QUOTE FOO)
    but Don't reads in as a 5-character symbol.  The second is that you
    can't bput comments just anywhere you please; e.g.
        (CONS X (* This is a comment about X.)
              Y)
    is wrong.  I've ocasionally resorted to kludges like
        (CONS (PROG1 X (* This is a comment about X.))
               Y)
    At least the prettyprinter moves comments over to a "comment
    column", just as the MacLisp GRINDEF would put semi-colon
    comments over in a comment column.