quasiquote vs. cons & friends

[Jonathan Rees <jar@martigny.ai.mit.edu>]

I can't find the relevant section of the report right now, but I
believe we agreed on the idea that redefining one standard name should
have no effect on the behavior of another.  So, redefining CONS
doesn't break APPEND, and redefining MEMV doesn't break CASE.
QUASIQUOTE's relation to CONS is just like CASE's to MEMV, so e.g. if
+ has its usual definition then necessarily

    `(a . ,(+ 1 2))  =>  (a . 3)

In implementation terms, definitions of built-in procedures and macros
need to be closed over a sort of hidden copy of the standard
environment, not over the top-level environment that the user sees.

I presume that now (Revised^5) that there are no reserved words, the
same provision applies uniformly to special forms, macros, and
procedures; e.g. redefining IF mustn't cause COND to behave
differently.

Any other behavior would necessarily expose implementation details and
lead to subtle bugs and portability problems.

I thought this was the agreed-upon opinion, but I have been wrong
about these things before.  In the past, the current editor was the
usual person to keep track of what we have or haven't agreed upon, but
at the last meeting we decided to have an "email facilitator" who
would take on this task.  The minutes say: "Jim Miller was chosen as
email facilitator.  Carl Bruggeman and Bruce Duba may assist Miller."

Jonathan