Re: Thoughts on the simplification of CLISP

[Blake M. <bl...@mc...>]

I think step 1 is as follows.  Get rid of the .d files!  Start with .c
files.  Use as many macros as needed, but don't use .d files and
processors.  As a person with more than 25 years C experience, approaching
the .d files is an unnecessary barrier.  When a C programmer wants to look
at CLISP, the first thing he sees is this wacko, foreign .d stuff.  It's
like having to learn a new language.  I'd say:

1.  Run it through all of the preprocessors to convert all of the .d files
to .c files

2.  With macros, clean up the .c files so that they are more reasonable.

Then, when a new and interested C programmer first starts getting into
CLISP he isn't put off right away.

It must be doable and reasonable or most of the other lisp systems wouldn't
be written in C.

Again, I really like CLISP.  I think simplifying the code base and build
procedure would go a long way.

Other comments about depending on standard libraries are a good next step.

Just one guy's opinion.

Blake McBride


On Tue, Nov 29, 2016 at 1:55 PM, Sam Steingold <sd...@gn...> wrote:

> Hi,
>
> > * Blake McBride <oy...@zp...zr> [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.
>