[plt-scheme] Contract Error Message

From: Carl Eastlund (carl.eastlund at gmail.com)
Date: Mon Jul 20 15:25:10 EDT 2009

On Mon, Jul 20, 2009 at 3:22 PM, David Van Horn<dvanhorn at ccs.neu.edu> wrote:
> YC wrote:
>>
>> On Mon, Jul 20, 2009 at 11:59 AM, David Van Horn <dvanhorn at ccs.neu.edu
>> <mailto:dvanhorn at ccs.neu.edu>> wrote:
>>
>>    Carl Eastlund wrote:
>>
>>
>>        Not according to the documentation I find here:
>>
>>        http://docs.plt-scheme.org/reference/contracts.html
>>
>>        Constants are perfectly acceptable contracts.  If the contract?
>>        function doesn't accept them, then either contract? needs to start
>>        accepting them or or/c needs to be documented with a more general
>>        contract.  But values like #f, 'foo, or 5 are usable with most
>>        contract primitives.
>>
>>
>>    Ah, yes, (contract? #f) => #t, which I forgot.
>>
>>    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?
>>
>>
>> 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.
>
> I don't want to change the contract language, so I must be confused about
> what a "higher-order" contract is -- which I guessed was anything
> satisfying:
>
> (lambda (x)
>  (and (contract? x)
>       (not (flat-contract? x)))
>
> But it seems the bug here is actually in the docs.
>
> "Takes any number of predicates and higher-order contracts"
>
> The higher-order part should be dropped, right?
>
> David

I think higher-order here means *potentially* higher-order; i.e. not
restricted to flat contracts.

--Carl


Posted on the users mailing list.