Help with lisp, please

[Michael Sherwin]

I was looking into the possibility of using common lisp to write a chess program, for prototyping, for fun, and maybe even for creating a standalone executable. However, there is an argument between pundits and detractors of lisp of whether or not modern native compiled lisp is close to C in speed or slower than interpreted basic. It seems that the main culpret in slowing down lisp is the garbage collector and maybe the run time system that they all seem to have. As, I have no way of knowing ahead of time, which side of the argument is correct, I decided it was not a very promising path to trod down.

Then I find thin lisp on the net that claims that (paraphraised) many large companies have used thin lisp for million line systems that run as fast as C code, because thin lisp translates lisp to C. Well, I am skeptical, because I also know about the ecl lisp to C translator that links to a run time system that has a garbage collector. However, I read in the thin lisp manual that thin lisp has no garbage collector and there is no mention of a run time system that must be linked to either. Here follows an excerpt from the manual.

"While C++ and Java can be viewed as attempts to move C more towards a denotational footing, Thinlisp is an attempt to move Common Lisp more towards an operational footing. I've attempted to lessen the impact of Lisp's "gotchas" that frustrate programmers who look at languages from an operational semantics point of view. Attempting to allow the benefits of deep denotational semantics while warning of performance and behavior surprises is the underlying goal for ThinLisp.

One of the goals of ThinLisp is to implement the deep semantics of Lisp, while offering compile time warnings whenever these semantics force behavior that deviates from expectations consistent with operational (or "thin") semantics. If the programmer really intends to use the full, deep semantics, then a lexically apparent declaration can be used to suppress the warnings and accept the more expensive behavior required by the deep semantics.

There are three main areas where ThinLisp warnings are used to help prevent performance gotchas.

consing,
run-time dispatched operations, and
non-local exits.
Within ThinLisp there is no garbage collector. While many fine garbage collection systems exist, and some are truely approaching the goal of real-time operation, they all impose significant overhead to maintain a root set of objects that form the base of the reference tree that is walked during a garbage collect. ThinLisp avoids the cost of the garbage collection and the cost of maintaining the data that makes garbage collection possible.

This means that Lisp programmers must adopt the discipline of the C programmer in knowing where memory is allocated and where it is reclaimed. Because this is such a foreign concept to Lisp programming style, automated help is required to protect Lisp programmers from careless consing. It is a well known maxim that Lisp programmers looking to improve performance should avoid consing, however very few Lisp programmers are good at it. Within ThinLisp there is a concept of both lexical and dynamic scopes that supply consing contexts. At compile time any consing operation must have a consing-area declaration lexically surrounding its scope, or else a compile time warning is given. The consing-area can either be permanent or temporary. (5) A permanent area means consing proceeds as normal, with all created objects having dynamic extent. However, whenever consing happens within a temporary scope, then the object's lifetime only has dynamic scope back to the exit point of the temporary consing-area. The consing-area declaration is similar to the dynamic-extent declaration, but it is pervasive instead of applying to a particular variable binding.

ThinLisp warns about run-time dispatched operations which could be made more efficient with type declarations. In some cases, the run-time polymorphism of an operation is exactly what is desired, and then there are declarations that can be used to suppress these warnings. It is well known that type declarations can improve the performance of some Lisp operations, however it is very difficult in practice to acquire these optimizations without some warnings and assistance from the compiler. The assumption in building the ThinLisp translator is that you are attempting to make production quality code, and therefore want advice about code that could be hiding a performance gotcha.

Lastly, ThinLisp can issue compile-time warnings about non-local exits. The unwind-protect form can guarantee that clean-up code is executed on exit from a scope, but it is a very expensive operation do to setjmp calls establish a reentry point into the function, and the need to declare variables volitile if they are modified within that scope. There are some macro forms where is it acceptible if an error exits a scope without a clean-up, but a normal execution of the body form should not leave the scope with a return-from form. In order to allow programmers to write macros that have clean-up code without resorting to an unwind-protect form, ThinLisp provides a require-local-exit declaration that will cause compile time warnings if a scope is left prematurely. The other kind of non-local exit that ThinLisp prevents is goto or return-from forms that exit a lexical closure and re-enter a surrounding function. These patterns of code are tantamount to catch and throw forms, which are very expensive. By declining to implement this form of non-local exit, we can prevent this kind of performance pratfall".

Okay I am hooked on the possibility that the author is being truthful and that lisp can be as fast as C if done correctly--and that is helped along by advice from the translator!

The problem I am having (on a windows XP system) is that it comes in lisp source and will not compile with out errors. There is only one error in the first package and only a few errors in the second. I figure that since, it was used in million line applications, that the errors are dialect related rather than errors in programming. I was hoping that someone that knows lisp could download thinlisp.zip from http://sourceforge.net/project/showfile ... e_id=56811 and give their opinion and possibly provide solutions. Is there a windows or even dos lisp interpreter that would compile thin lisp without errors?

THANKS!
Mike