At Thu, 4 Apr 2013 15:34:18 -0600, Danny Yoo wrote:
> I'm running into dynamic evaluation behavior that I don't quite
> understand yet. My example is:
>
> https://gist.github.com/dyoo/5314045
>
> It's meant as an experiment to see whether it's possible to avoid 3d
> syntax in certain places like the gui-debugger. I try to throw in a
> wrench on lines 52-54:
>
> https://gist.github.com/dyoo/5314045#file-annotation-example-rkt-L52-L54
>
> but thankfully, when I evaluate this in DrRacket, I get the results I expect.
>
>
> However, that's when I'm evaluated the annotated+compiled code. If I
> modify the example so I'm evaluating just the annotated code, by
> modifying lines 117-119
> https://gist.github.com/dyoo/5314045#file-annotation-example-rkt-L117-L119
>
> from:
>
> ;; But we can evaluate it in ns:
> (printf "evaluating the annotated code\n")
> (eval compiled-code ns)
>
> to:
>
> ;; But we can evaluate it in ns:
> (printf "evaluating the annotated code\n")
> (eval annotated-code ns)
>
>
> I get the unexpected shadowing I'm trying to avoid. Why am I getting
> the clash here, and not in the compiled code?
When you use
(eval annotated-code ns)
it's the same in this example as
(map (lambda (c)
(define compiled-c
(parameterize ([current-namespace ns])
(compile c)))
(eval compiled-c ns))
(cdr ; drop `begin'
(syntax->list annotated-code)))
That is, `eval' splices a top-level `begin' and evaluates earlier
spliced forms before it compiles later spliced forms.
The `eval' function must interleave evaluation and compilation to make
various things work --- even though interleaving breaks various other
things, including your example. The top level is hopeless.
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
