Re: Thoughts on the simplification of CLISP

Hi,

> * Blake McBride <[email protected]> [2016-11-28 20:52:19 -0600]:
>
> 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.

I think this is usually called "ported" rather than "portable".
IOW, "the porting work has been done" rather than "porting is easy".

> 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.

I think is what is usually called "portable".
The point, I think, is that the ifdefs only come from autoconf, not from
hand-crafted tweaks.

I think the general direction is to shift _most_ of the portability work
over to gnulib.
I.e., all the functionality is expected to be standard, maybe provided
by a gnulib layer.

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

What matters is "fast enough" and functionality.
People use python a lot - so CLISP's problem is not speed.
The problem is that we don't have numpy, pandas, sklearn, matplotlib &c.

> 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.

I have been whining about this for years.
The problem is that CLISP internals work required a C hacker -
and why would a C hacker be hacking a Lisp?

> 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.

Agreed.

> 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.

We already have this.
See "porting hints" at the end of clisp/unix/PLATFORMS - it explains how
to disable all the "advanced features".

However, as usual, my general answer is
http://www.cygwin.com/acronyms/#PTC :-)



-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://jij.org
http://memri.org http://thereligionofpeace.com http://honestreporting.com
Politically Correct Chess: Translucent VS. Transparent.

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