<br><div class="gmail_quote">On Mon, Jul 20, 2009 at 12:22 PM, 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;">
YC wrote:<div><div></div><div class="h5"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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>

</blockquote>
<br></div></div>
I don&#39;t want to change the contract language, so I must be confused about what a &quot;higher-order&quot; contract is -- which I guessed was anything satisfying:<br>
<br>
(lambda (x)<br>
  (and (contract? x)<br>
       (not (flat-contract? x)))<br>
<br>
But it seems the bug here is actually in the docs.<br>
<br>
&quot;Takes any number of predicates and higher-order contracts&quot;<br>
<br>
The higher-order part should be dropped, right?<br><font color="#888888">
</font></blockquote><div><br>I agree that the doc seem ambiguous on the higher contract point. IIUC, or/c is a higher order contract itself, and accepts regular contracts (including constants, predicates, flat contracts) and higher order contracts such as another or/c, listof, etc. <br>
<br>Cheers,<br>yc<br><br></div></div>