William: Do you have a workaround for now, such as reordering the
definitions?
I have a change that makes these examples work, but it breaks other
examples, like a single expansion of this module:
(module namespace-mismatch racket/base
(#%plain-module-begin
(#%require (for-syntax racket/base))
(begin-for-syntax
(let ([ns (variable-reference->namespace (#%variable-reference))])
;; The top level at phase 1 ...
(eval #'(define-syntax-rule (m) (begin (define x 2) x)) ns)
;; The expander will have to find the right macro-introduced `x`:
(eval #'(m) ns))
(#%plain-lambda () foo))
(begin-for-syntax
(define-values (foo) #f))
(module* f #f
(#%plain-module-begin))))
The problem is that the current expander tries to do different things
in a module and at the top level to handle macro-introduced
identifiers. That seems ok for phase 0, where a module and top-level
process don't overlap for the same namespace, but these examples
illustrate how it fails for phase 1.
The change to make other examples work is at
https://github.com/mflatt/racket/tree/phase-1-ns
Since it may break existing programs, though, I'm reluctant to push it.
The right solution is to switch to the new expander implementation ---
soon, I hope. The new expander works on all of these examples, and it
generally gets `...->namespace` operations right where the current
expander's implementation is flaky.
Thanks all for very helpfully narrowing down the problem!
--
You received this message because you are subscribed to the Google Groups
"Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/5a75d66b.494f370a.ff7f0.37d7SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
For more options, visit https://groups.google.com/d/optout.
