[plt-scheme] fluid-let-syntax may get flushed
You may want to read about module->namespace in the mzscheme manual.
Robby
At Wed, 11 Aug 2004 08:34:41 -0400, "Richard C. Cobbe" wrote:
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> Lo, on Tuesday, August 10, Matthew Flatt did write:
>
> > The problem with `fluid-let-syntax' is that it provides a way to break
> > into a module and access the module's private bindings. We have ignored
> > the problem up to now, because there were so many other ways to break
> > into a module. We're closing those other holes without changing the
> > language much, but I think the solution for `fluid-let-syntax' is
> > simply to get rid of it.
>
> Does that mean that the following will no longer work?
>
> (module foo mzscheme
> (provide a)
>
> (define a 3)
> (define b 4))
>
> (define-syntax require/expose
> (syntax-rules ()
> [(_ mod (ids ...))
> (begin
> (require mod)
> (define-values (ids ...)
> (let ([ns (module->namespace 'mod)])
> (parameterize ([current-namespace ns])
> (values
> (namespace-variable-value 'ids)...)))))]))
>
> (require-expose foo (b))
>
> ;; both a and b now available.
>
> If that's going away, then I'm disappointed. Modules are great once
> you've got code that works, but the strong abstraction barriers are a
> serious, even fatal, impediment to white-box testing. Combined with the
> less-than-completely-useful result of check-syntax on a module [1], it's
> enough to make me give up on the module system. (Which would be a pity,
> because then contracts would be useless.)
>
> As another possibility, what about a new language level? I gather that
> the (module ...) language implementation reaches into the guts of the
> module, if you will, and extracts the private bindings to make them
> available to the repl. Would it be possible to create a testing
> language that did something similar? Specifically, it would expect the
> definitions window to contain only a single module definition, which
> would contain test cases. The module would be written just as modules
> are now, except that it would have a special require form that would
> expose private identifiers within the module being tested.
>
> I'd look at the module language's current implementation to see how
> these things are done, but I can't actually find it. Where is that,
> please?
>
> Richard
>
> [1] I would really prefer it if the expander allowed check-syntax to
> highlight *all* of the module's unbound identifiers in one go, rather
> than stopping with a fatal error on the first and requiring me to hit
> check-syntax N more times to find the rest. In general, my tools should
> give me as many error messages per run as possible; it wastes less of my
> time. (This is one thing the C folks got right; why has the Scheme
> community forgotten this?)