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

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