PLT mzc: MzScheme Compiler Manual
The mzc compiler takes MzScheme (or MrEd) source code and produces either platform-independent byte-code compiled files (.zo files) or platform-specific native-code libraries (.so or .dll files) to be loaded into MzScheme (or MrEd). In the latter mode, mzc provides limited suport for interfacing directly to C libraries.
mzc works on either individual files or on collections. (A
collection is a group of files that conform to MzScheme's
library collection system; see section 16 in PLT MzScheme: Language Manual). In general, mzc
works best with code using the
As a convenience for programmers writing low-level MzScheme extensions, mzc can compile and link plain C files that use MzScheme's escheme.h header. This facility is described in Inside PLT MzScheme.
Finally, mzc can perform miscellaneous tasks, such as embedding Scheme code in a copy of the MzScheme (or MrEd) binary to produce a stand-alone executable, or creating .plt distribution archives.
Byte-code files are loaded into MzScheme in the same way as regular
Scheme source files (e.g., with
Byte-code programs produced by mzc run exactly the same as source code compiled by MzScheme directly (assuming the same set of bindings are in place at compile time and load time). In other words, byte-code compilation does not optimize the code any more than MzScheme's normal evaluator. However, a byte-code file can be loaded into MzScheme much faster than a source-code file.
Native-code files are loaded into MzScheme with the
The native-code compiler attempts to optimize a source program so that it runs faster than the source-code or byte-code version of the program. See section 1.4 for information on obtaining the best possible performance from mzc-compiled programs.
The cffi.ss library of the compiler collection
defines Scheme forms, such as
Native-code compilation produces C source code in an intermediate stage; your system must provide an external C compiler to produce native code. The mzc compiler cannot produce native code directly from Scheme code.
Except for MacOS, the C compiler and compiler flags used by mzc can be adjusted via command line flags.
mzc does not generally produce stand-alone executables from Scheme source code. The compiler's output is intended to be loaded into MzScheme (or MrEd or DrScheme). However, see also section 5 for information about embedding code into a copy of the MzScheme (or MrEd) executable.
mzc does not translate Scheme code into similar C code. Native-code compilation produces C code that relies on MzScheme to provide run-time support, which includes memory management, closure creation, procedure application, and primitive operations.
Under MacOS, double-click on the mzc launcher application with the Command key pressed, then provide arguments in the command line dialog that appears. (Close the MzScheme application first if it is already running, since mzc is itself a MzScheme-based application.) If the Command key is not pressed while mzc is started, the command-line dialog will not appear. If a file is dragged onto the mzc icon, then the command-line will contain the file's path; this is useful for compiling a Scheme file directly to an extension. If a file is dragged onto the mzc icon, additional command-line argument can be provided by holding down the Command key, but the arguments will go after the file name, which is almost never useful (since the order of command-line arguments is important).
In this manual, each example command line is shown as follows:
mzc --extension --prefix macros.ss file.ss
To run this example under Unix or Windows, type the command line into a shell (replacing mzc with the path to mzc on your system, if necessary). Under MacOS, launch mzc with the Command key pressed, and enter everything after mzc into the dialog that appears.
Compiling a program to native code with mzc can provide significant speedups compared to interpreting byte code (or running the program directly from source code), but only for certain kinds of programs. The speedup from native-code compilation is typically due to two optimizations:
Programs that permit these optimizations also to encourage a host of
other optimizations, such as procedure inlining (for
programmer-defined procedures) and static closure detection. In
Native-code compilation rarely produces significant speedup for programs that are not loop-intensive, programs that are heavily object-oriented, programs that are allocation-intensive, or programs that exploit built-in procedures (e.g., list operations, regular expression matching, or file manipulations) to perform most of the program's work.
1 The compiler cannot always prove that