[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

I claim subsetting doesn't kill portability

I agree with Krall that if the LISP or whatever standardly-named package
doesn't contain all of the CL language (or the subset) and exactly that
with nothing else, you have trouble with portability. Krall seems to be
saying there's no way to have the LISP package contain exactly the subset
and have the LISP package contain exactly fullblown CL. Well, with loading
of compiled files into an existing LISP package and with multiple startup
shell scripts (CMS EXEC files etc.), I claim it is possible. You simply
put that part of the LISP system which absolutely must be handcoded or
cross-compiled in the kernel, and put all the rest in runtime-loadable
(binary program space) modules. You can then have well-defined supersets
of the kernel which are subsets of the fullblown system (or if you want,
kernel-supersets which are NOT subsets of CL). You have a different shell
script for each well-defined (documented) superset of the kernel. The method
can be (1) actually load in all the extra modules each time the user boots
a new user environment ("core image"), (2) simply install autoload properties
for all the functions in all the additional modules that are to be made
available, or (3) pre-load all the actual modules or autoload properties
and save the core image or savefile on the disk to be quickly restored
by any user. Installation of CL on a given system can then consist of
(a) building the kernel, (b) compiling all the loadable modules, (c)
creating all the core-images of savefiles if option (3) was used, (d)
setting up all the shell scripts for the various supersets of the kernel,
(e) making documentation for the CL available in hardcopy or online,
including definition of the various subsets available, and (f) announcing
the various shell scripts available, including telling which CL subsets
(kernel supersets) correspond to which shell scripts.

Porting a program written in an official CL-subset (kernel-superset)
from one machine to another then becomes simple: (aa) FTP the source,
(bb) read the comment at the top of the source that tells which subset
it needs, (cc) check the annoncements of shell scripts to see which one
corresponds to that subset, (dd) run it.

That algorithm doesn't work if the target machine didn't have the particular
subset on which the original program was developed and which it needed
to run, but the same would be true if the target machine didn't have CL
at all, as would likely be the case if it was a small machine and CL
didn't have subsets defined, so that argument isn't a refutation to my
claim. Anybody able to find a sound refutation/rebuttal to my claim that
Krall's view is wrong?