[racket-dev] A strange problem with namespaces

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
<samth at 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
> <robby at 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
>> <samth at 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