[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MzScheme for Embedding




> I like a few things about MzScheme:
> 1.  It compiles to an interpreted bytecode.  This means I can
> cache the bytecodes in core for heavily used scripts, and save
> some of the "compile" time for future invocations.

You should be careful about this assumption.  Guile does incrementally
convert a direct representation of the source code to an internal form
designed for fast interpretation.  However, Guile has other
performance problems.  MzScheme may indeed be faster for you, but
guessing which system is more suitable for your needs based on
implementation details is not reliable.  You should run some
experiments.

> I do have a couple of concerns about MzScheme:
> (A) The Guile-list has lots of complaints that the MzScheme
> module system is very un-schemelike (whatever that means).  Can
> anyone here shed light on what this means?

For what it's worth, I disagree.  MzScheme units are first-class
objects whose composition is entirely under the control of Scheme
code.  It seems very Schemey to me.

The biggest problem is that units can't export macros.  I understand
the rationale for this, but that choice does mean that units don't
meet a pretty widespread need.  I don't currently understand how
macros are scoped in MzScheme.  It looks like they have a totally
separate, kind of ad-hoc mechanism for dealing with that.

> 3)  No byte-code compilation, which means scheme code must be
> parsed each time it is run (less opportunity for smart compiler
> optimizations if they are "expensive").

As I say, run some tests, to be sure this works out for you.  I'm
interested in the results, either way.

You should also list Guile's lack of documentation.