Agreed. As I indicated later, throwing away useful information wasn't my intent -- having a tight, well-defined contract was. T serves that purpose, but other values may also serve it and add utility at the same time.

The WORST case, in my mind, is to return something useful, but leave the contract as "non-null". This encourages programmers, who may or may not have observed the contract wording, to experimentally observe the actual behavior, and depend on it.

It's probably even more likely in Lisp than in most languages, because it's so easy to type a test case into a read-eval-print loop.

I am not generally dogmatic that all aspects of all behavior need to be tightly specified. For example, there can be substantial performance benefits to leaving traversal/iteration orders unspecified, or there can be substantial benefit from implementation freedom, or it can be completely impractical to write a full specification.

But return values, especially boolean return values, are well worth consistently specifying tightly. And I think there's little danger of a religion arising based on it -- and it'd be a relatively harmless one even so.

-----------

Date: Sat, 15 Jan 2011 15:23:48 +0100 From: "Svante Carl v. Erichsen" Svante.v.Erichsen@web.de Subject: Re: [pro] Style issue about predicates Hi!

I would not like such a rule in a style guide, for fear of religious followers. My view is: yes, tighten the contract, but no, it needs not (but may) specify exactly t. If something useful can be returned, why throw it away?