Re: JACAL, scm

[Tom Lord]

       We have a Guile VM which evaluates code up to 20 times faster than the
       current Guile evaluator.  Our plan is to merge this VM into the
       standard Guile distribution.  

That's neat.  "up to 20 times faster" -- can you characterize that
with greater precision?  What's the typical speed-up?  What language
features effect the speed-up that occurs?  What does the new VM do to
latency (the SCM eval is very, very good in this regard, making it
ideal for an extension language)?  What techniques are used for the new VM?

Since good performance is apparently a goal, I'm surprised to have not
gotten any positive uptake on my suggestion of merging the I/O system
from Systas with Guile.  As you may recall, one feature of the I/O
system is that file buffers and Scheme strings can be unified -- an
I/O optimization.  The Systas I/O system also has nice performance and
semantic features, only partially developed in the current release of
Systas, that result from the unification of ports and descriptors and
the introduction of a virtualized file system interface.

Another two (related) areas that effect performance, at least for some
kinds of program, are modifiable shared substrings and regexps.  I've
had good experience with the Systas versions of both of these (which
started with their presense in Guile).  Retreating from these features
in Guile is a mistake, in my opinion.

Another area where performance is tricky is strings with Unicode
support.  The new run-time system I proposed a while back has a lot to
offer in this area.  Addressing these problems in the run-time system
in a generic way gives C and C++ programmers greater incentive to
adopt Guile as an extension language, and can give the world a
much-needed Unicode library for C and C++.



       Therefore we are currently more concerned with improving
       maintainability and facilitating the use of Guile as an
       embedded language in applications than optimizing the current
       evaluator.

Has there been any behind-the-scenes work with GCC hackers to add GCC
features for precise GC?  In the absense of such features, or at least
a plausible plan that will eventually lead to such features, the
applicability of Guile is necessarily limited.  In that case, a wise
goal for the app interface would be to change it so that precise GC
can be supported without GCC features, without having to modify
library-client applications.  Even if a GCC plan is in the works,
reliance on just a single compiler is a questionable idea, and
interfaces that support precise GC a good solution.

The traditional objection to this has been "Well, GCPRO in Emacs is
hard to use."  But that objection has a good reply: build a static
analyzer to check for its correct use.  A while back, I prototyped
such an analyzer and used it to clean up many critical section errors
in Systas -- that prototype has since rotted away, but it was a good
solution.  And it could help with Emacs maintenance, as an extra
bonus.  



        You are correct that Guile fails when loading r4rstest.scm.
        It fails when trying to evaluate the expression '(begin)'.
        Now, looking at both R4RS and R5RS, it turns out that this is
        an illegal expression.  According to the standards documents,
        at least one expression is required:

         - library syntax: begin <expression1> <expression2> ...

I believe there are several problems with that interpretation.  I am
just skimming the standards, today, which are not entirely fresh in my
memory -- but tell me if you think I've missed something:

The standards documents don't describe anything called an "illegal
expression".  That's something you are making up to describe the
formal syntax.  The formal syntax doesn't include the expression
`(begin)'.

RnRS explicitly calls out situations where implementations are
required to signal errors.  `(begin)' isn't one of them.

Has Guile *no* syntax extensions compared to RnRS?  It used to -- for
good reasons.

`(begin)' is the kind of perfectly reasonable form it is easy to
create when automatically generating code.  Allowing it in an
extension language is a nice convenience feature.

Strict RnRS compatability was originally a non-goal for Guile, both
because the standards are anemic, and because we planned features 
that were certainly not compatible.  Being able to run "most" RnRS
code was a goal -- but a secondary goal.

-t