[plt-scheme] mzc, eval and redefined structures

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Sat Jan 5 08:00:01 EST 2008

At Sat, 05 Jan 2008 19:18:08 +1300, Orlando Hill wrote:
> I have some code that I generate and eval at runtime.
> The generated code accesses a library that is also used in other parts 
> of my program.
> Currently, this works fine with mzscheme but not with a stand-alone mzc 
> version. The problem encountered is that structures of the shared 
> library seem to be redefined in the mzc version.
> I've tried doing a few things with name-spaces but I feel like I'm 
> stabbing in the dark.
> Below is a tested simplification of the current code.
> 'mzscheme -mv -t app.scm' gives #t.
> 'mzc --exe app app.scm && ./app' gives #f.

In the second test, try moving "app" to a different directory. Then
you'll get a "app-lib.scm not found" error instead of #f.

The problem is the relative path "app-lib.scm" in the generated code:

> (require "app-lib.scm")
> (define code "(module app-code mzscheme (require \"app-lib.scm\") 
> (provide app-code) (define (app-code data) (make-app-lib data)))")

Since the generated code isn't read from a file, then the "app-lib.scm"
path in the generated module is relative to the current directory. But
there's no particular reason for the current directory at run time to
have anything to do with the original source directory.

In fact, the executable created by `mzc' pretends that the original
module tree is in a kind of parallel filesystem, since all of the
modules are copied into the executable.

So, that's why there are two "app-lib.scm" instances in your second
test: one is from the parallel world in the executable, and the other
is the "app-lib.scm" sourec file accessed by the dynamic code.

One way to avoid this problem is to use a `lib' path for "app-lib.scm".
That way, you haveeed an absolute, filesystem-independent name for
"app-lib.scm", instead of a filesystem-relative name, so the
compile-time code and run-time code can reliably talk about the same
module. So, put your code into a collection, and then you can use a
`lib' path to access "app-lib.scm" in the generated code.

Another possibility is to not use `mzc --exe', and instead use the
`create-embedding-executable' Scheme function to build the executable.
That function gives you more options, including the ability to give a
specific module name to "app-lib.scm" (instead of a synthesized
parallel-filesystem name) so you can access it at run time.


Posted on the users mailing list.