In #lang web-server, set! seems to behave differently with local vs. top-level variables. For example:
> #lang web-server/base (define x 0) > (displayln x) ;; displays 0 > (set! x (add1 x)) > (displayln x) ;; displays 1 > (let () > (define y 0) > (displayln y) ;; displays 0 > (set! y (add1 y)) > (displayln y)) ;; still displays 0 There is an obvious solution — don't use set! — but it was still not what I was expecting. The documentation does say that "… the store is *not* serialized. If you rely on the store you will be taking huge risks. You will be assuming that the serialized continuation is invoked on the same server before the server is restarted or the memory is garbage collected." But this doesn't seem to have to do with serialization per se. The line "(set! y (add1 y))" expands to this (thanks to the macro stepper): > (let-values:130 ([(y) (#%app:178 (#%app:179 CLOSURE-ref:130 clsr:130 '0))]) > (let-values:180 (((l111640:181) > (lambda:182 (x111632) > > (with-continuation-mark lifted.0:31 '(#t (lambda (x111632))) (set! y > x111632))))) > (#%app:183 keyword-apply:130 > l111640:181 kws:130 kw-vals:130 rst:130))) which as best as I can tell will have no effect, because it's "y" is local. Does anyone have a deeper standing of what's going on? If set! is supposed to work this way, I would propose at least adding a note to the "usage considerations" for #lang web-server, and I might consider more drastic action (e.g. having set! raise an syntax error if it's used in a local context. Doing without set! is not a problem, but the fact that it *does* work as usual at the top level (and REPL) makes it difficult to realize you have a bug, e.g. when porting existing code. -- -Philip -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
