EVAL-OTHER
Structure types defined by users using DEFSTRUCT should also self-evaluate unless an explicit implementation type for the structure is given in the DEFSTRUCT, in which case the rule for evaluation of that type should be used. (This is important in the case of type LIST.)
(LET ((TEMP (MAKE-PATHNAME))) (EQ TEMP (EVAL TEMP))) => T (LET ((TEMP (MAKE-ARRAY NIL))) (EQ TEMP (EVAL TEMP))) => T
By making implementations agree, code portability is enhanced. By biasing the decision away from the "signal an error" end of the choice spectrum, the least interruption is caused to implementations which already have working code.
There is still some chance that implementations will have some other behavior than either signalling an error or self-evaluating, but there are probably few if any.
There should be no performance impact since the evaluator's test for these new data types can simply be made to follow other tests already in place, so existing code will not be slowed.
LISP may find this invasive to their sense of distinction between objects and the notation used to describe objects. In general, however, this is a fairly picky detail that is not likely to trouble the average programmer.EVAL-OTHER:SELF-EVALUATE.
Fahlman: "... I do remember the original design discussions. It was proposed that everything but lists and symbols evaluate to themselves, but at the time (this was quite early in the process) some people felt that this might close out interesting parts of the design space that might turn out to be useful for something. This hasn't happened, and I think it would be reasonable to close this door now. Some users do find it confusing that you have to quote vectors but not strings."
There has been some additional discussion of this proposal (for example, an explaination of why a similar proposal in Scheme might be a bad design.)