RE: MzScheme for Embedding

[Brent Fulgham <brent.fulgham@xpsystems.com>]

> > 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.
>
What I mean here is that I could capture the "internal representation"
in the caching -- rather than go through the relatively slower parsing
routines prior to running.  This is useful if a web site has lots of
hits on the same routines (e.g., some kind of content display utility).
I believe this is easy to accomplish in MzScheme because I can see
that it produces a "compiled" version of the code (perhaps along the
same lines as an Emacs lisp compile?)  I don't think Guile's analog
is available to me, but I haven't fully read the documentation.

> > 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.
>
Oh!  Well that's great then.  I was afraid of using a non-standard
format that would result in lots of angry e-mails some time down the
road as expert schemers tried to use my plug-in.
 
> > 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.
> 
I've seen some postings on the Guile list that show a very wide range
of performance.  Of course, as we know there are "lies, damn lies,
and statistics".  I don't trust benchmarking results too blindly, and
I saw that Guile performs quite well in "real-world" situations.
However, I have to think that a memoizing type of system (which is what
Guile uses AFAIK) will theoretically be unable to provide the same
kinds of performance optimizations as a dedicated compiler might.  But
I certainly don't know what I'm talking about.  Probably test cases
can be constructed to highlight weaknesses in both designs.

If Guile did provide me access to its internal representation so I could 
bypass that step when multiple invocations are made it would be a great
benefit.

> You should also list Guile's lack of documentation.
> 
It seems to be about as good as most Free software projects -- it's
always far more fun to code than to document. ;-)

-Brent