implied contracts in the mapping functions?

[Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>]

    Vague arguments about possible optimizations are also a bad idea.

I disagree.  It should be clear that this sort of thing rules out a very
large class of possible optimizations -- basically, all those
optimizations that would depend on some property of the input list, such
as its length or the type of elements present.  If we allow the user's
functionals to mutilate this list after it is passed in, any highly
optimizing compiler would have to check these functionals for destructive
side-effects on the list, a much more difficult task in most cases.

    Generally, I would like to see optimizations 
    shaped by linguistic considerations, not linguistic considerations shaped
    by optimizations.

OK, how about the following: When you pass an object to a Common Lisp
function or special form whose job it is to process that object in some
coherent manner, it HAS to be undefined what happens if you somehow
regain control (perhaps because the form is executing a function on your
behalf) and destructively modify that object in the middle of the
operation.  I see no way to make this coherent in general.  Therefore to
allow a few simple cases of it (chewing only on the as-yet-unprocessed
tail of a list being chewed linearly) would be an ugly hack.

Multi-processing is not addressed by the Common Lisp design and trying
to imagine what it would look and use that as a basis for argument seems
much more bizarre to me than worrying about what "vague optimizations"
some future super-compiler for the existing language would want to
employ.

-- Scott