<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">-----------</span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br>
</span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Date: Sat, 15 Jan 2011 15:23:48 +0100<br>From: "Svante Carl v. Erichsen" <<a href="mailto:Svante.v.Erichsen@web.de" style="color: rgb(20, 125, 186); ">Svante.v.Erichsen@web.de</a>><br>
Subject: Re: [pro] Style issue about predicates</span></div>Hi!<br><br>I would not like such a rule in a style guide, for fear of religious<br>followers.  My view is: yes, tighten the contract, but no, it needs<br>not (but may) specify exactly t.  If something useful can be returned,<br>
why throw it away?<br></span>