Yes, I've read those docs many times. :) I'll also note that changing the require in 'f' to this doesn't help, which seems suspicious:
(require (submod ".." evaluator) (for-meta 0 (submod ".." evaluator)) (for-meta 1 (submod ".." evaluator)) (for-meta 2 (submod ".." evaluator)) (for-meta 3 (submod ".." evaluator)) (for-meta 4 (submod ".." evaluator)) (for-meta 5 (submod ".." evaluator)) (for-meta -1 (submod ".." evaluator)) (for-meta -2 (submod ".." evaluator)) (for-meta -3 (submod ".." evaluator)) (for-meta -4 (submod ".." evaluator)) (for-meta -5 (submod ".." evaluator))) On Wed, May 7, 2014 at 9:31 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: > Well, to quote from the docs for `dynamic-require`: > > "When provided is a symbol, the value of the module’s export with the > given name is returned, and still the module is not visited or made > available in higher phases." > > That's why I think the extra line is needed. > > You're right that the error message refers to phase 0, but I'm not > sure who's phase 0 that is. > > Sam > > On Wed, May 7, 2014 at 10:27 AM, Robby Findler > <ro...@eecs.northwestern.edu> wrote: >> When I look at this code I can't figure out why (submod "weird.rkt" >> evaluator) _isn't_ available at phase 0! Could this be a bug? >> >> Robby >> >> On Wed, May 7, 2014 at 9:11 AM, Sam Tobin-Hochstadt >> <sa...@cs.indiana.edu> wrote: >>> This program: https://gist.github.com/samth/e7b55fcef66da9b8416a works >>> when line 33 is uncommented, otherwise it gives the error: >>> >>> ?: module mismatch; >>> attempted to use a module that is not available >>> possible cause: >>> using (dynamic-require .... #f) >>> but need (dynamic-require .... 0) >>> module: (submod "weird.rkt" evaluator) >>> phase: 0 >>> in: phase1-phase0-run >>> context...: >>> weird.rkt: [running body] >>> >>> From reading the docs on `dynamic-require`, I can see that >>> `(dynamic-require m 'f)` doesn't make anything available for higher >>> phases. However, the actual `dynamic-require` in the program is just >>> for a function -- the need for higher phases is an implementation >>> detail that's leaking in because it doesn't behave like a regular >>> value wrt `dynamic-require`. >>> >>> Is there something I can change in the implementation of the internals >>> of `f` so that clients of `f` don't need to do the extra >>> `(dynamic-require m 0)` in order for `f` to work? >>> >>> Sam >>> _________________________ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >> _________________________ >> Racket Developers list: >> http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev