[Axiom-developer] CCL development

[root]

Mike,

CCL is on the list of lisps to build and, indeed, was the first effort
I made. You'll notice that the CCL code is in pamphlet format. The
Makefile tree exists and will properly build a working CCL image. There
were a few problems I ran into with CCL. Overall I did like the speed
of compiles and the byte-codes are very small. It took me a while to
create an image but that eventually succeeded. There were some difficult
problems however.

First, I had no documentation of the language and it is clearly not
common lisp. System commands, such as "save-system" and memory management
commands (like setting heap and stack sizes) are the kind of things I
NEED to know. I know these commands with GCL as I helped define them.

Second, I couldn't figure out how to debug code. The "break loop"
commands were not obvious to me. There is no documentation on the
structure of the runtime image or of the byte codes. These don't
exist either for GCL but I spent years with it and know the GCL
code well.

Third, there didn't seem to be a way to generate "intermediate"
code.o files from the build process. This lack breaks the whole
makefile tree and means I need to deeply reengineer the process.

Fourth, Several of the shipped algebra files will not compile in the
NAG CCL image and I couldn't figure out how to find the failure.

Fifth, the CCL image hangs if you run it long enough and I couldn't
figure out why. It isn't swapping and it uses 99% of the cpu. (The
easiest way to see this is to fire up the NAG axiom image and compile
the algebra libraries). I tried to debug this also without success.

Sixth, Size isn't the issue (anymore). Actually, it never was. I had
Axiom running on a 16Meg laptop years ago. Portability is an issue and
I expect that CCL is going to be very useful there. Speed also is not
an issue. Schelter built a special mechanism for Axiom that deeply
optimizes function calling (the so-called .fn files). We had many
discussions about it. Camm has also extended GCL with a function that
allows me to see the assembler code generated by pieces of lisp so I
can see exactly what is expensive (a more useful disassemble output).

Seventh, Common Lisp has moved since last I played with it. For instance,
you need to do a make-package before doing an in-package. Previously
in-package would do an implied make-package. The boot and spad compilers
need to be updated to handle this, and other, changes. Axiom code will
not run on the latest version of common lisp. I have several people 
who have proposed projects that depend on common lisp and Axiom so
I can't abandon common lisp. Languages change and code needs to keep
up to live (I also have a C++ code pile I maintain that won't compile
in the latest C++ because the language changed. sigh). I'll have to
retrofit the new functions into CCL when they get generated by Axiom.

So CCL is a target lisp that I plan to support but the first two
months were spent trying to get things running without success. 
Almost every problem above falls into the category of "I don't know
how to ...." and I was losing huge amounts of time trying to reverse
engineer CCL without making progress on getting Axiom running. I
switched to GCL, originally for debugging, now for first release
because I know the code so well. Once the system development moves
into the developer's hands I'll revisit the CCL path. It clearly
is an excellent lisp and I just need to find the time to learn it
in intimate detail. Unfortunately, the learning time was on the
critical path to getting Axiom out the door, which is my first
priority, and I couldn't afford to delay the effort any longer.

Tim