[racket] How to tell if identifier is bound in racket/load?

On 07/16/2012 03:35 AM, Nick Sivo wrote:
> Hi,
>
> I've been using the following awesome snippet to detect when
> identifiers are already bound:
>
> ; From Danny Yoo's arctangent
> ; https://github.com/dyoo/arctangent/blob/master/language.rkt
> ; Returns true if stx is an identifier that is lexically bound.
> (define-for-syntax (lexically-bound? stx)
>    (let ([expanded (local-expand stx (syntax-local-context) #f)])
>      (cond
>        [(and (identifier? expanded)
>              (eq? #f (identifier-binding expanded)))
>         #f]
>        [else
>         #t])))
>
> Then I created a helper so I could call it at runtime:
>
> (define-syntax (arc-bound stx)
>    (syntax-parse
>     stx
>     [(_ var:id)
>      (if (lexically-bound? #'var) #'#t #'#f)]))
>
> That still worked great.  Then I tried using racket/load:
>
> Welcome to DrRacket, version 5.2.1 [3m].
> Language: racket/load; memory limit: 128 MB.
>> (arc-bound a)
> #f
>> (define a 5)
>> (arc-bound a)
> #f
>>
>
> :(  I've read through the docs on namespaces and the racket/load
> language source in an attempt to fully understand why racket/load is
> different, but I'm missing something.  I've noticed that I can see 'a
> in (namespace-mapped-symbols), and have tried using that, but ran into
> (I think) phase issues.  If there's a quick solution to this that I've
> missed, that's brilliant.

It works in DrRacket using #lang racket because the interactions occur 
in a module namespace, but with #lang racket/load all interactions 
happen in an ordinary namespace. That accounts for the differences in 
the results of identifier-binding.

> Otherwise, my motivation to start making use of racket/load (really
> arc/load in my case), is to get access to global variables.  If
> ark.rkt declares something at the module level, I need to be able to
> see it - the same copy of it - from other modules that require
> ark.rkt.  What I'm trying now is to have ark.rkt be a real module
> written in arc, and then require it and load the rest of the arc files
> using the arc/load language so they all share the same module registry
> and the same ark.rkt.  If there's some other, better way to do this,
> pointers will be quite warmly received.

I can't tell how the behavior you described differs from just providing 
the variable from ark.rkt and requiring ark.rkt normally. Can you elaborate?

Ryan