[plt-scheme] Contract changes a parameter-procedure to a procedure. Why?

FWIW, I think we're getting a better understanding of what exactly
needs to be baked in to the language to do a better job of making such
contracts work, between things like struct properties and chaperones
(but the contract library has not yet caught up with the latest
goodies in mz0>

Robby

On Fri, Apr 16, 2010 at 12:53 PM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> (The real issue is that real contracts can't be implemented as a library;
> they have to be 'baked into' the core of the language. But this is not for
> here or now.)
>
>
> On Apr 16, 2010, at 1:45 PM, Carl Eastlund wrote:
>
>> On Fri, Apr 16, 2010 at 1:30 PM, Greg Hendershott
>> <greghendershott at gmail.com> wrote:
>>>
>>> I had the bright (?) idea of specifying a contract for a parameter. But:
>>>
>>> #lang scheme
>>>
>>> (define p1
>>>  (make-parameter #f))
>>>
>>> (parameter? p1) ; --> #t
>>> p1 ; --> #<procedure:parameter-procedure>
>>>
>>> (define/contract p2
>>>  (() (boolean?) . ->* . (or/c boolean? void?))
>>>  (make-parameter #f))
>>>
>>> (parameter? p2) ; --> #f   Why?
>>> p2 ; --> #<procedure>      Why?
>>>
>>> I discovered this when I made a contract for a procedure that requires
>>> its argument to be a parameter. I can't use parameter? I'd have to
>>> settle for procedure?.
>>>
>>> Is this because the contract is implemented as a wrapper procedure,
>>> and the parameter? predicate only sees the contract wrapper procedure
>>> not the parameter-procedure inside?
>>
>> That's exactly it.  Use parameter/c instead; it constructs a
>> parameter-friendly wrapper.
>>
>> --Carl
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>