More on making AKCL

[ajb@kerri.oz.au (Anthony Berglas)]

More on making KCL re. wfs's re.

I did not wish to imply that KCL was unreliable.  I have found no serious
bugs.  My suggestion is simply about how the system could be constructed
so that someone like myself who has limited time to study the details
and certainly not to read the V/ files could work with it more easily.

Currently the system seems to run like this:-
  1) Merge OldKCL into AKCL, including compiler .c files
  2) Make AKCL with the OLD KCL compiler
  3) Compile the new compiler with the old one
  4) Make AKCL.

This has then been heavily modified because the old compiler .c files 
are no longer compatible with the new AKCL data structures, not surpisingly.
My first suggestion is simply to remove the dependancies on the old KCL
INTERMEDIATE files as follows:-

  1) Copy the OldKCL SOURCES into AKCL, excluding the compiler .c files.
     (The oldKCL files can now be archived).
  2) Merge in the Source changes.
  3) Compile an interpretive version of AKCL, directly from sources.
     This will be slow.
  4) Make the Compiled AKCL.

When Bill S. or others wish to change AKCL they could simply repeat
step 4 using a reliable version to produce the next debug version.
This would be fast.  When a new distribution is loaded KCL could compile
itself twice, once interpreted and once compiled, the results should be
identical.  My point is please don't try to optimise step 3 with such tricks
as loading the .o files as you go.

My other, less important point is that it would be nice if the makes
were so organised as to not rely on dynamic linking or save-system, so
that it would easy to port a usefull subset of AKCL to other machines.
The main restriction of this lazy port would be that when new routines
were compiled KCL would have to be stopped and relinked with the new code
in the conventional C way, which is fine if the new machine is not one that
is being used for development.

Other General Notes:-

1) The source of my problems with SCO Unix is that it produces an
   error with file names longer than 14 chars, other version fives
   seem to simply truncate silently.  (I then got into hot water trying
   to modify the make procedures).  They also seem to have 'fixed' other
   things eg. ps only shows processes in your terminal group.

2) My problem with the four basic .lsp files was simply the loop in the
   dependancies -- neither evalmacros or defmacro can be loaded before
   the other has been because of the DefVar!
   Simply calling si::*Make-Special instead from defmacro fixes this.

3) My comments on the C Stack GBC where illconsidered and wrong.
   I had forgotten that savejump could be used to force a register save.
   I spent many enjoyable hours fixing a similar bug on a mickey mouse
   Lisp several years ago.

4) Most AKCL shell scripts already have #!/bin/sh in them, which I think
   is fine.  I cannot imagine a Unix sytem working without a bourne shell
   in /bin.  However why not put SHELL= in the make file before the 
   .defs is merged so that it can be overwritten.  The .def files should
   be kept as small as possible.

5) My comment on make/include was a complaint against AT&T not AKCL
   obvioulsy AKCL must use the lowest common denominator of tools.

6) If the makes need a list of CMP modules to link or load for interpretation
   couldn't you continue to use code like 
      echo $(CMPNEW) | sed ... > load.lsp

7) To avoid people editing sys_kcl.c to include extra modules of
   their own why not introduce a dummy rouine init_user that is
   in a stub file sys_user.c.  This routine could be called after
   other KCL initialization and be safly modified by others.
   (The init_or_load macro could be placed in a .h file).
   A nasty hack to get around the problem in the mean time is to 
   provide a dummy init_cmpspecial() rouine that calls
   init_cmpspec(). I am not recomending this. 
   People who edited sys_kcl will be in trouble anyway if extra
   modules are added.

None of the above changes would affect the product end Lisp users
would see, just what people like myself would see if the automatic
make procedures need any slight modifications.

Regards,
        Anthony.