On Mon, Sep 9, 2019 at 8:17 PM Simon Haines <simon.hai...@con-amalgamate.net>

> 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.


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 

Reply via email to