[racket] local-expand 'module-begin

From: Tero Hasu (tero.hasu at ii.uib.no)
Date: Thu Sep 12 18:21:07 EDT 2013

Ah, okay. Thanks Ryan.

So it looks like the exact same phase-2 x binding is being introduced
twice, first during local-expand, and then during processing of the
expanded code, which causes a conflict. (And that something is being
done to prevent that for phase 0 and 1 bindings.) Fortunately this is
the sort of problem that I'm unlikely to soon run into in practical
code, I should think. Was just doing some testing.

I conclude that long as I avoid top-level phase 2+ bindings, and I
guess beware of duplication of top-level phase 1+ side-effecting
operations, I should be okay with this approach.


On 12/09/13 22:16, Ryan Culpepper wrote:

> Note that the problem is not restricted to submodules, and it has
> nothing to do with the fact that x is defined in two phases. The same
> error is raised by this program:
>
> #lang racket/load
>
> (module le-lang racket
>    (provide
>     (except-out (all-from-out racket) #%module-begin)
>     (rename-out [module-begin #%module-begin]))
>
>    (define-syntax (module-begin stx)
>      (syntax-case stx ()
>        ((_ . bs)
>         (local-expand
>          #'(#%module-begin . bs)
>          'module-begin null)))))
>
> (module le-module 'le-lang
>    (require (for-meta 2 racket/base))
>    (define x 0)
>    (begin-for-syntax
>      (begin-for-syntax
>        (define y 2))))
>
> I conjecture that maybe the problem is that the module's environment (or
> renames?) is not being cleared/reset at all phases when 'local-expand'
> returns, only phases 0 and 1. But in a brief search of the expander code
> I wasn't able to confirm my guess.
>
> Ryan
>


Posted on the users mailing list.