[plt-scheme] The usefullness of module systems

For interactive development, the module language is probably what you 
want.

For automated unit tests, it is sometimes convenient to gain access to 
a non-provided
identifier from a module. It is possible to do this by going through 
the namespace.
The following macro makes this convenient:

;; Requires a module and exposes some of its unprovided (non-syntax!)
;; identifiers.
;; USAGE: (require/expose MODULE-NAME (IDS ...))
;;   where MODULE-NAME is as in the MzScheme manual (i.e., a standard
;;   module spec) and IDS are the un-provided identifiers that you wish 
to
;;   expose in the current module.
;; Based on a macro by Raymond Racine (rracine at adelphia.net) posted to
;; plt-scheme in Dec 2003.
(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)...)))))]))

;; e.g. :
(require/expose "my-module.ss" (first-identifier-to-expose second-one 
and-so-on))


On Oct 8, 2004, at 3:52 PM, Corey Sweeney wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> Hi.  I currenly use closures instead of modules, and am looking at
> switching to modules.  So far I see the advantages as the "stackable
> macros" thing (of which i currenly have no macros to stack).  The big
> downside that i see, is that it will make development much harder,
> because when i go to probe a variable inside the module i'm
> developing, it'll just say "undefined identifier".  I've tried doing
>
> (define x 7)
> (provide mod-env)
> (define mod-env (interaction-environment))
>
> inside the module, then doing
>
>
> (require...)
> (eval `x mod-env)
>
> at top level, and i still get "undefined identifier".  Is there any
> good way to get a prompt with access to the internal vars?
>
> My other options that I see are:
> Write it outside the module, and then wrap it in the module after your
> your sure you'll never make any more changes. (i.e. never :)
> Attempt using my "define-global" (call/cc trick) to mask define inside
> the module, dumping all internal vars into the global environment.
>
> ,  without useing my "define-global" which