[plt-scheme] fluid-let-syntax may get flushed

From: Robby Findler (robby at cs.uchicago.edu)
Date: Wed Aug 11 08:43:10 EDT 2004

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?)


Posted on the users mailing list.