Thoughts on the simplification of CLISP

Greetings,

I have over 30 years experience in C, and many years playing with CLISP
(probably since its initial release).  Although I have used CLISP, I have
never really gotten into its internals.  Having been exposed to the mailing
list, a bit of experience building CLISP and tracking down rare
difficulties, I have formed some opinions which are not necessarily true.
Not having sufficient time to investigate the facts, I thought I would
share my opinions publicly in the hopes of constructive commentaries.

Let me start by saying that I deeply appreciate CLISP and the contributions
made by Bruno and many others.  CLISP is perhaps my favorite lisp system,
and lisp is surely my favorite language.

The following are just impressions:

I do not believe that CLISP is very portable.  I know CLISP runs in a great
number of environments, but I do not think that makes the system portable
for the following reason.  Being able to run in a lot of environments, and
being portable, are not the same thing.  For example, I will describe two
different types of systems, both of which run in a lot of environments, but
only one is portable in the sense I am trying to convey.

Type 1:  This system takes maximum advantage of the underlying platform
facilities in order to provide the most functionality and be as fast as
possible on the system it is running on.  It achieves "portability" through
many, many ifdef's or constructs that have the same effect.  So, while the
system is "portable" in the sense that it runs on a lot of systems, it only
does so through many careful ifdef like facilities and complex build
procedures.

Type 2:  This system is portable because it only uses standard facilities
that are broadly available on most platforms.  Although there are ifdef
constructs, they are seldom used.  The system is simple to build because at
largely depends on readily available, common facilities.

The advantage of Type 1 is that it runs faster and provides more
functionality.

The disadvantages of Type 1 are that it is really not portable, and it is
very fragile.  Although it may run on many systems at one point in time, it
suffers very significantly from bit rot on nearly a monthly basis - making
it high maintenance.  It also isn't really portable because the amount of
work it would take to get it to work in a new environment is very
significant.

Type 2 systems are really portable in the sense that they can be easily
ported to a new environment, and they are much, much less subject to bit
rot.

Now, having said all that, I am of the somewhat ignorant opinion that CLISP
is of Type 1.  I say that because, over the years, I've seen how fragile
and complex the build process is.  I also say that because I've seen first
hand how the system wouldn't build because I had some arcane library one
revision too old or too new.

Speaking for myself alone, I would prefer CLISP to be Type 2 for the
following reasons:

1.  Getting every ounce of speed is not important.  No one uses CLISP if
speed is their primary concern.

2.  It seems like development and support of CLISP is beginning to
dwindle.  If CLISP doesn't become Type 2, it'll quickly die as soon as
updates to it cease - due to rapid bit rot.

3.  On the other hand, if it does become Type 2, it could live on and be
useful for a very long time with very minimal work.

Given how far CLISP has come, and the variety of machines it readily builds
on, rather than a course correction, perhaps CLISP could use a Type 2
portability fork.  In general, I don't like when forks occur, but in this
case, wanting to retain CLISP's current appeal while at the same time
building something that can be easier to support and better withstand the
changes with time.

Or, if not a fork, perhaps something like this:

    ./configure real-portable
    make real-portable

What this process leaves us with is a set of source files (not any object
or executable files) that are as portable as can be.  You can move the
files almost anywhere and just type "make".  Perhaps it incluses one header
file with a small number of define's someone can select from.

Well just some thoughts.  I do appreciate CLISP, and I hope I haven't
offended anyone.

Blake McBride

------------------------------------------------------------------------------

_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel