[plt-scheme] Compiling modules that use homemade primitive modules

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Tue Feb 18 08:51:38 EST 2003

At Mon, 17 Feb 2003 07:28:08 -0800 (PST), Ulf Leopold wrote:
> I have an application that needs to implement its own
> main() function. The main() function obtains the
> global MzScheme environment, defines a primitive
> module named "prim", and then enters the Scheme code.
> [...]
> In the Scheme code, I have implemented several modules
> that are stored in a collection. These modules use the
> module "prim" above.
> [...]
> So far, everything works without any problems. But now
> I would like to compile these modules into byte code
> [...]
> Compiling directly with mzc does not work since mzc
> has no knowledge of "prim".

This same problem shows up with MrEd, which adds a `#%mred-kernel'
module to supply primitives. The MzScheme-based setup-plt can compile
MrEd programs because no program uses `#%mred-kernel' directly.
Instead, each module uses `(lib "mred.ss" "mred")', which dynamically
accesses `#%mred-kernel' and re-exports the primitives.

This is a little clumsy, but effective. And MrEd needs a wrapper module
anyway, because most of the actual primitives are wrapped with more
functionality that is implemented in Scheme.

> I have also tried to
> execute the compiler from within my own application
> (where "prim" is available) as follows:
> (current-command-line-arguments (vector
> "testmodule.scm"))
> (require (lib "start.ss" "compiler"))

I think the problem is that the compiler creates a new namespace for
expanding a module. The new namespace contains only the initially
declared modules.

After declaring "prim", you can call scheme_save_initial_module_set()
to add your module to the set of initially declared modules. (I see
that this function is not documented in "Inside MzScheme", and I'll fix


Posted on the users mailing list.