[plt-scheme] difference between imported definition versus locally defined definitions?

Yes, I don't really want #%top per se.  My scenario is to "alias" an
imported id (i.e. not something privately defined by the module) and it
looks more like below:

> (module foo mzscheme
    (define bar (lambda (x) x))
    (provide bar))
> (begin
    (require (prefix baz: foo))
    (define bar baz:bar))
> baz:bar
#<procedure:bar>
> bar
#<procedure:bar>

Aliasing allow me to "trace" and set over the alias (
http://list.cs.brown.edu/pipermail/plt-scheme/2007-March/016927.html).  So I
extracted the exported variables for a module (
http://list.cs.brown.edu/pipermail/plt-scheme/2003-November/003698.html) and
attempt to do write a macro that would automatically alias them, but all of
the variables gets expanded to (#%top . variable) form, while if I manually
write it out like above, it is "ok".

Reading the manual it says that unbound variables would automatically gets
expanded to (#%top . var) form.  Anyway to prevent it from expanding to the
form?

Thanks,
yinso


On 4/23/07, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>
> At Mon, 23 Apr 2007 16:45:25 -0700, "Yin-So Chen" wrote:
> > What is the difference with respect to imported bindings and local
> > bindings?  I notice that imported binding cannot be expanded via #%top?
>
> `#%top' always refers to a definition outside of a module.
>
> > In syntax a define often gets expanded to (#%top . id) form, so how can
> I
> > write
> >
> > #'(define local-id imported-id)
> >
> > Given that the above gets expanded to
> >
> > #'(define-values (local-id) (#%top . imported-id))
>
> If I understand, you don't really want `#%top'. Instead, you want the
> binding that `imported-id' would have if it appeared at the top level
> of its enclosing module (or at the plain top level, if the definition
> appears outside of a module).
>
> There's no way to do that right now (I think).
>
> In fact, if there was a way to do that, then depending on how it
> worked, I think it might open a kind of security hole: a macro might
> expand to `(let ([x ....]) .... (<untrusted-thing> x))' where the
> enclosing module also defines a top-level `x' that is supposed to
> remain private. If `<untrusted-thing>' turned out to be a macro that
> find the module-top-level binding of `x', maybe it could get at the
> private `x'. Or maybe the relevant operations could be defined to
> prevent that sort of thing; I'm not sure.
>
> Matthew
>
>


-- 
http://www.yinsochen.com
...continuous learning...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070423/525e41db/attachment.html>