Antonio, Yep. That was the problem. Fix pushed!
Thanks for your patience. Vincent On Mon, 07 Sep 2015 12:12:19 -0500, Vincent St-Amour wrote: > > Antonio, > > Thanks for the report! Your test case has resisted all my attempts at > simplification, which made it a bit tricky to work with. :) > > I think I've found the cause of the problem, though. It looks like the > type to static contract translation's cache causes it to generate open > static contract terms, which the optimizer chokes on, which causes the > error you're seeing. > > Specifically, the following static contract (for `bar`) is (I think) the > problem: > > #<->/sc #<or/sc #<rec/sc ((n*9 #<struct/sc #<or/sc n*9 #<rec/sc ((n*10 > #<struct/sc #<flat/sc String>>)) n*10>>>)) n*9> > #<rec/sc ((n*10 #<struct/sc #<flat/sc String>>)) n*10>> > #<rec/sc ((n*24 #<struct/sc #<or/sc n*11 #<rec/sc ((n*12 #<struct/sc > #<flat/sc String>>)) n*12>>>)) n*24>> > > Note the `n*11` on the last line, which is not bound by any `rec/sc` > (and is the particular identifier the optimizer chokes on). > > The bit with `n*11` is present in the previous (very similar) static > contract (for `foo`), where it is in fact bound. Generating the SC for > `foo` puts that term in the cache, which causes SC generation for `bar` > to reuse it. (And that explains why the error occurred only when both > bindings were provided.) > > Disabling the SC cache (in the source, there is no user-visible option) > makes the problem go away, as expected, but is not a real solution. > > IIUC, the fix would be to not put open SC terms in the SC cache. It > looks like there's already some checking for that in place, but it > doesn't seem to be working, as this example shows. I'll look into this. > > Asumu: You added this caching. Any thoughts on that? > > Vincent > > > > On Tue, 01 Sep 2015 08:28:36 -0500, > Antonio Leitao wrote: > > > > Hi, > > > > Meanwhile, I reduced the problematic code to a maneageable fragment. > > > > The following code typechecks and runs fine: > > > > #lang typed/racket > > > > (define-type (Base-Shape R) > > (U (foo-shape R) > > (bar-shape R))) > > > > (define-syntax (def-base-shape stx) > > (syntax-case stx () > > [(_ (R (func-name shape-name) [param-name : param-type] ...)) > > (syntax/loc stx > > (begin > > (struct (R) shape-name ([param-name : param-type] ...)) > > (define #:forall (R) (func-name [param-name : param-type] ...) > > (shape-name param-name ...))))])) > > > > (def-base-shape (R (foo-func foo-shape) [s : (Base-Shape R)])) > > (def-base-shape (R (bar-func bar-shape) [s : R])) > > > > (provide foo) > > (define (foo [shapes : (Base-Shape String)]) > > (foo-func shapes)) > > > > ;(provide bar) > > (define (bar [shapes : (Base-Shape String)]) > > (bar-func shapes)) > > > > However, if you uncomment the last provide, it generates an error: > > > > ..\..\..\..\..\..\..\..\Program > > Files\Racket-6.2.900.10\share\pkgs\typed-racket-lib\typed-racket\static-contracts\optimize.rkt:155:2: > > free-id-table-ref: no mapping for #<syntax n*11> > > > > Is there a workaround? > > > > Best, > > António. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Racket Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to [email protected]. > > To post to this group, send email to [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/racket-dev/3a2f30ad-218e-4684-a769-7371c069e3c0%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/m2a8syf4fd.wl-stamourv%40eecs.northwestern.edu. For more options, visit https://groups.google.com/d/optout.
