On Mon, Sep 9, 2019 at 8:17 PM Simon Haines <simon.hai...@con-amalgamate.net> wrote:
> What wasted a lot of time for me is that, despite the macroexpander's > results, the macro works as expected in the REPL. If you paste my original > macro into DrRacket, run it, then type '(hex a)' into the REPL you get the > expected result. In this case, '(expand (hex a))' doesn't help. This is > possibly due to something like a combination of phases, environments and > top-level bindings, but I couldn't figure it out. > This is a rather unpleasant pitfall of the REPL. If you try to evaluate the expression `(if #f some-unbound-identifier 1)`, you will see that it evaluates to `#f` in the REPL but raises an unbound identifier error in a module. At the REPL, `some-unbound-identifier` refers to a top-level variable, and it is allowed to support, for example, forward references to identifiers that will be defined in a subsequent interaction, or interactive re-definition of variables. However, I have to admit that I hadn't realized before that references to undefined variables are allowed even without a lambda delaying evaluation, as long as they are in an untaken branch of a conditional. I have to say I don't like it. This certainly falls under the category of "the top level is hopeless" [1], but maybe we can do better in Racket2. [1] See for example https://gist.github.com/samth/3083053, though that list isn't even up-to-date. -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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAH3z3gZGHqow2wS6QOfEa3zT%2BM-y2_HOERuDC_H5KHcYmY7RsQ%40mail.gmail.com.
