[pro] Style issue about predicates

[Bob Kerns]

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 at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20110115/9b218d79/attachment.html>