What's wrong with '#,<frob> ?

[JONL at PARC-MAXC]

As GSB related, the Maclisp notion of #, centers around a hokey
notion of "reading for the purpose of compiling this function", as
opposed to reading for any other purpose.  The probelm as I see it
is that QUOTE is being squeezed a bit beyond its capabilities.

QUOTE should imply a constant which is constant over all incarnations
of Lisp, and throughout all time.  The #, indicates something
which varies on a per-loadup basis, but is constant after that.
Previous to "#,", users would just set aside a global variable 
which would be initialized a load up time.  But I much prefer
    (MUMBLE-UPON X '(SOME #,(machine-name) MESSAGES))
to the less apealing
    (MUMBLE-UPON X GLOBALVARIABLE.FOR.MSG.FUNCTION.A0025)

Suggestion:  a new special form, say CQUOTE, which is like QUOTE
    but actually processes over its form, looking for
    certain substitutions to make (such as evaluating some part).
    this is hardly a new idea, since Adolfo Guzeman had such a
    macro in his PhD Thesis program in 1967 (running on a PDP6
    at that -- R.I.P. PDP6!)  Thus the above example would become
        (MUMBLE-UPON X (CQUOTE (SOME (:, (machine-name)) MESSAGES))
    or, if you will permit me the a few # macrocharacter extensions,
        (MUMBLE-UPON X #!(SOME #,(machine-name) MESSAGES))

There are problems to be worked out about whether the processing is
to happen at read time, at compile time, at load time, or at first
reference (Masinter's msg noted severl Interlisp special forms to make
these distinctions).  But it does bring some of the burden for
identifying an "evaluation context" for data back to the original user.

I might add, in addendum to GSB's note, the Bob Kerns and I worked
a long time at trying to get the compiler/assembler to "percolate"
information about squids u p from the inner guts of quoted data
to some "higher" level so that FASLOAD wouldn't crap out because
the load-time evaluation wound up calling FASLOAD recursively.  [I dont
thnk we ever got it 100% right -- I believe I saw another Maclisp bug
report last summer which would have been explaind by this.  But
there is a point of diminishing returns of COMPLR development, and besides
the problem goes away if you cause the needed file to be loaded in
befor hand]

As ALAN mentioned, only the Maclisp version of backquote has the option
of guaranteeing to the user some interal structure of the output
of the backquote and comma macros -- and having some such guarantee
is crucial to having a "residential" system which doesn't keep the text
of all its sources internally.  So how about "conditionalquote", i.e.
CQUOTE, by analogy to the BQUOTE case?