[racket] procedure, contract, assoc, and REPL

You seem to be relying on identity of procedures (which is a bad
idea). Contracts on functions are implemented with wrappers which
breaks that by making fewer things equal but compiler optimizations
can take things the other direction making more things equal than you
might expect.

Overall I think you should just avoid relying on the identity of
procedures. One way to do that (without knowing more about your code)
would be to use struct procedures and put an extra field on the struct
that gives you the key for a comparison.

Hth,
Robby

On Wednesday, July 21, 2010, YC <yinso.chen at gmail.com> wrote:
> Hi all -
>
> I am running into an interesting issue where an alist of procedures in REPL, the ones without a contract works with assoc, but the ones with contract do not work with assoc.
>
> What I have is an alist where the keys are procedures.  Some of these procedures have contracts attached to them, and some do not.  Then I tried to use assoc to match the procedures.  If the code are run within the module itself - both types match, but within REPL only the ones without contract matches.
>
> Here's an simplified example, where foo.ss defines the procedures, and the test.ss uses foo.ss to construct the alist.
>
> ;; foo.ss
> #lang scheme
> (define (test? v) #t) ;; provided with contract
>
> (define (test2? v) #t) ;; provided without contract
>
> (provide/contract
>  (test? (-> any/c boolean?))
>  )
>
> (provide test2?)
>
> ;; test.ss
> #lang scheme
> (require "foo.ss")
>
> (define table `((,test2? . 1) (,test? . 2)))
>
> (assoc test? table) ;; works in module setting but not in REPL
>
> (assoc test2? table) ;; works in module setting AND in REPL
>
> Both the assoc test above returns the correct result.  But if I try to copy and run (assoc test? table) in REPL again, it will not match, whereas (assoc test2? table) continues to match.
>
> Is there any particular reason for the divergence of the behaviors?  I verified the behavior in both v4.2.5 and v5.0.  Thanks.
>
> yc
>
>
>
>
>