free variable references in interpreter.

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

    I don't believe there is anything in the Common Lisp book that
    explicitly states that a Common Lisp implementation may not signal
    errors in any situations not explicitly defined in the book to be
    errors.  On tbe other hand, I think there is at least an implicit
    expectation that a purely computational section of a valid Common Lisp
    program will execute without requiring the user to hit a "resume" key
    every three seconds.  I am not sure what we can say in the book about
    this without unduly contraining experimentation with programming
    environments and debugging tools.

If Common Lisp is to be of any value at all as a standard promoting
portable software, the following assumption has to be true (or as close
to true as we can possibly make it): If an implementation claims to be a
Common Lisp or a superset of Common Lisp, any legal program that
conforms to what is in the manual and uses nothing that is not in the
manual ought to run in that implementation.  "Run" means "run without
signalling any errors".  I'm not sure we need Guy's hedge about "purely
computational"; I don't know what he means by that, but if he means "not
involving user-interface or system-interface" issues, I think we have
excluded most of that from the current language spec, and have indicated
the range of permissible variation in the remaining cases.

Of course, this is more a goal than an iron-clad rule, since the manual
is ambiguous and incomplete in some areas.  Still, I think that we
should state this explicitly and strive to achieve it.  I thought that
we already had stated this or something close to it, but maybe not.  On
the question of how we say this without unduly constraining
experimentation, I don't see that as a problem.  People should feel free
to experiment all they want, but if they knowingly violate the standard
they should point that out and not claim to be a Common Lisp (in those
specific respects).  Manufactuers would be well-advised to provide a
mode that that is strictly kosher Common Lisp -- as close as they can
come, anyway -- and if they want to experiment with incompatible
improvements, these should be enabled by a switch of some sort.
Ideally, it should be straightforward to get at the strict Common Lisp;
you should not have to poke around setting 53 undocumented switches,
some of them guarded by people with guns, in order to get behavior that
conforms to the standard.

Given the above, I think I can answer all of Guy's queries with a single
statement of principle:

When operating as a strict Common Lisp, the system should run any legal
Common Lisp program without signalling any ERRORS.  If the system wants
to mumble warnings and critiques of my style, that's fine -- the more,
the better -- as long as these warnings are of a sort that I am free to
turn them off or at least ignore them.  If the warnings require some
explicit action in order for me to proceed, or if they cause my
compilation not to complete properly, then that is not OK, unless this
is an optional behavior that I can easily get rid of.  I don't mind the
intereter mumbling warnings (into some separate stream, so that they
don't mess up what my legal but unstylish program is trying to print),
though customers will have varying opinions about how much they want to
pay for such criticism at runtime.

Doesn't that cover it?  I think that Guy threw us a curve by asking
whether warnings were OK in various situations, while saying that these
"warnings" might or might not require some explicit action -- to me, that
is the critical issue.

Of course, a few of Guy's examples are so outlandish that I would find
the warnings in question irritating.  Perhaps we need several levels:
Error, Warning, Style Critique, Friendly Advice, Kibitz.

-- Scott