<br><div class="gmail_quote">On Mon, Jul 20, 2009 at 11:59 AM, David Van Horn <span dir="ltr">&lt;<a href="mailto:dvanhorn@ccs.neu.edu">dvanhorn@ccs.neu.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Carl Eastlund wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Not according to the documentation I find here:<br>
<br>
<a href="http://docs.plt-scheme.org/reference/contracts.html" target="_blank">http://docs.plt-scheme.org/reference/contracts.html</a><br>
<br>
Constants are perfectly acceptable contracts.  If the contract?<br>
function doesn&#39;t accept them, then either contract? needs to start<br>
accepting them or or/c needs to be documented with a more general<br>
contract.  But values like #f, &#39;foo, or 5 are usable with most<br>
contract primitives.<br>
</blockquote>
<br></div>
Ah, yes, (contract? #f) =&gt; #t, which I forgot.<br>
<br>
However, or/c accepts any number of predicates and *higher-order* contracts, so perhaps the or/c contract can be refined to enforce this aspect of the specification?<font color="#888888"></font></blockquote><div><br>I am a happy user of the current contract system and would hate to see this change.  Constants are a perfectly valid contract and why should they not be accepted in a higher order contract?  This would seriously curtail the expressiveness of the contract system, not to mention create two separate rules to remember.  <br>
<br>Cheers,<br>yc<br><br><br></div></div>