[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
that.)

Matthew



Posted on the users mailing list.