[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Predicate for true lists

From: Paul Eggert
Subject: Re: Predicate for true lists
Date: Sat, 7 Jul 2018 10:14:15 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

Eli Zaretskii wrote:
LGTM, pushed.

I don't see why the change is needed; on the contrary, it is counterproductive.

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.

Similarly, the documentation for "length" need not and should not say that it signals an error if its argument is not a sequence; it should merely say that its argument is a sequence. Otherwise, we'll be precluding future changes from being compatible with the existing documentation.

If we document that "length" signals an error if its argument is the wrong type, for consistency shouldn't we have similar documentation for "*" and all other functions that signal errors for wrong-type arguments? That sounds like a lot of verbiage to add the manual, and its added length would be a cost that would exceed any benefit.

Also, I still don't understand why this documentation change would be helpful for the proposed proper-list-p implementation. As Eli has acknowledged, the proposed implementation does not depend on 'length' signaling an error when given a non-sequence. So why is this documentation change needed even for this particulare case?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]