RE: Predicate for true lists

[Drew Adams <drew.adams@oracle.com>]

> The documentation for "*" doesn't say that "*" signals an error if an
> argument is not a number or a marker; it says only that its arguments
> are numbers or markers. This wording means that if we later extend "*"
> (say, to support multiplication on vectors of numbers), we won't be
> making an incompatible change.

I'm sorry to butt in here, but I disagree.  Such a change
_is_ an incompatible change, _regardless_ of what the doc
might say before the change.  An incompatible change is
about behavior, not just doc.

If we at some point changed `*' so that it accepted also
vectors and performed a dot- or cross-product operation
(or something else), then that would be decided taking
into account that the behavior (for vector arguments)
changes.

For vector arguments the change would, yes, be
incompatible, regardless of what the doc might have said.
Presumably, if such a decision were ever made, it would
be a change for the better - but it would nevertheless
an incompatible change.

The point of view that we won't document what the
current error-handling behavior is, in hopes that that
will somehow give us more leeway for changing the
behavior later, is misguided.  Users should be able
to count on the intended behavior - the design, not
just what on some part of it that we choose to
advertise.

We should document the intended behavior, including
the error behavior.  If we later change the behavior,
so be it.  At that point we'll change the doc to fit
the new behavior.

We are all users of Emacs.  Doc is a window into the
behavior.  There is no sense tinting it or blocking
part of its view.

I spoke of "intended behavior" and "design", as
distinct from unintended behavior (e.g. bugs) and
implementation details.  Raising an error for an
argument that is a vector is presumably part of
the intended design.