This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: guile's OCCC contributions :>


Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> The following code snippets come from the guile evaluator and from
> the SCM evaluator and do both the same.
> [...]

Yes, the Guile evaluator looks more complex than SCM's, but it's
interesting to see some of the reasons:

In the Guile code I see fragments for

* better error checking
* thread support
* debugging support

Since these are features which SCM lacks, it's not quite fair to put
the code fragments next to each other.

Some pieces of the Guile code segments can be found in other parts of
the SCM evaluator.

Also, I'd like to point out that there is a lot of thought behind most
changes made to the original SCM evaluator.  In fact, the original
evaluator was speeded up by some changes, and other changes have been
carefully planned so that they don't slow it down.

The parts of the evaluator which I dislike the most are the support
for single-stepping and tracing without mutating the debugged code.
There is also a strength to this---it's possible to trace calls to
primitive and internally defined procedures.


I think I'm quite a heavy user of Guile in the sense that I use it a
lot and use features from the darkest corners of Guile, and I know how
many times I have needed to look through the code in eval.c---in
principle never.

The only times I have needed to work in eval.c is when doing
modifications in the evaluator itself.

So, in the role as a user, I don't care the least bit if the code in
eval.c is hard to understand, but I *do* care a lot about the speed of
the evaluator and I do care a lot about features like good error
reporting, backtraces and thread support.

While the goals of having easily maintainable, well modularized code
are central, I think it's OK to make an exception in the evaluator
*if* this is necessary to achieve high performance.

It's important to note that the current SCM evaluator is faster due to
new features, like the environment cache, not because of added
complexity or bad code in Guile.


But I don't want to argue that the state of the Guile code is perfect.
Certainly, there is much improvent that can be done.  It would be good
to import the changes that has been made to the SCM evaluator one by
one.

Every contribution to this process is appreciated.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]