Ah. This looks like the bug I've seen reported elsewhere that causes blame to be associated with the wrong module. The actual problem going on here appears to be that test-sim passes an "Any" to toplevel-vals, but sim-structs expects toplevel-vals to receive a toplevel. The blamed module, sim, isn't involved at all.
Carl Eastlund On Fri, Mar 4, 2011 at 6:06 PM, Matthias Felleisen <[email protected]> wrote: > > The interesting thing is that the contract blames the TYPED module, > contrary to all the blame theorems. Time to fix them. Anyone? > > On Mar 4, 2011, at 5:22 PM, Carl Eastlund wrote: > >> Danny, >> >> This is an issue with the type Any. Typed Racket has to protect all >> values passed from typed code to untyped code from all possible >> type-unsound uses. For many kinds of values, this means Typed Racket >> has to close off pretty much all kinds of uses. In your case, you >> have a transparent struct. If it were unwrapped, untyped code could >> inspect it, extract a constructor for its struct type, create an >> instance with field contents that violate your define-struct: >> declaration, and pass it back into typed code. You have to be very >> careful with Any on boundaries, because it has to make a lot of things >> completely opaque. >> >> Sadly, off the top of my head, I don't have a quick workaround for >> you. Maybe Sam will have a better suggestion. >> >> Carl Eastlund >> >> On Fri, Mar 4, 2011 at 4:20 PM, Danny Yoo <[email protected]> wrote: >>> I'm hitting an error when trying to pass values between typed and >>> untyped code. I've shrunk the error to the following test code. >>> Consider three files 'sim-structs', 'sim.rkt', and 'test-sim.rkt'. >>> sim-structs and sim are written in Typed Racket, and test-sim is >>> written in regular racket. >>> >>> ;; sim-structs.rkt >>> #lang typed/racket/base >>> (provide (all-defined-out)) >>> (define-struct: machine ([env : (Listof Any)])) #:transparent) >>> (define-struct: toplevel ([vals : (Vectorof Any)]) #:transparent) >>> >>> >>> ;; sim.rkt >>> #lang typed/racket/base >>> (require "sim-structs.rkt") >>> (provide new-machine) >>> (: new-machine ( -> machine)) >>> (define (new-machine) >>> (make-machine (list (make-toplevel (vector 'foobar))))) >>> >>> >>> ;; test-sim.rkt >>> #lang racket >>> (require "sim.rkt" "sim-structs.rkt") >>> (toplevel-vals (first (machine-env (new-machine)))) >>> >>> >>> >>> When I try to execute test-sim, it fails with the following error: >>> >>> >>> tesla ~/work/js-sicp-5-5 $ /pro/plt/software/racket/5.1/std/bin/racket >>> test-sim.rkt >>> contract violation: expected <toplevel?>, given: #<Typed Value: >>> #(struct:toplevel #(foobar))> >>> contract on toplevel-vals24 from >>> (file >>> /home/dyoo/work/js-sicp-5-5/sim-structs.rkt) >>> via >>> (file >>> /home/dyoo/work/js-sicp-5-5/test-sim.rkt) >>> blaming >>> (file /home/dyoo/work/js-sicp-5-5/sim.rkt) >>> contract: (-> toplevel? (vectorof Any)) >>> at: /home/dyoo/work/js-sicp-5-5/sim-structs.rkt:11.16 >>> >>> === context === >>> /pro/plt/software/racket/5.1/std/collects/racket/contract/private/blame.rkt:58:0: >>> raise-blame-error >>> /home/dyoo/work/js-sicp-5-5/test-sim.rkt: [running body] >>> >>> >>> >>> It looks as though there's some special "Typed Value" wrapper there >>> that shouldn't be visible from the untyped test-sim code. Is there a >>> workaround? _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
