[clisp-list] What are CLISP's "selling" points?

[Pascal B. <pj...@in...>]

Hoehle, Joerg-Cyril writes:
> Hi,
>=20
> I'm wondering what attracts people to CLISP. Maybe developers could
> then concentrate efforts on these distinguishing areas.
>=20
> My likes:
> + small size (both disk & run-time)
> + works on many many platforms (many unixes)
> + portability stresser, e.g. any place which might cause an error
> actually signals an error (except declarations :-) at run-time
> + robustness -- for years, I had no single crash using Amiga-CLISP
> which I could not trace down to a bug in gcc(!) or in CLISP, which
> got fixed soon. Very few crashes in total. This generates warm
> feelings for every Amiga user. These days however, CLISP sadly has a
> few known GC-triggered bugs somewhere in its code, seemingly hard to
> nail down.

Yes all this.

> [...]
> I also received feedback by some people who considered CLISP much
> easier on the beginner than e.g. CMUCL. I fail to understand this,
> but maybe this is something to concentrate upon: first impressions
> count a lot. Many SW-packages get tossed away within half an hour of
> toying with them.  Maybe CMUCL beginners get turned away by the
> warnings about special declarations they dont' understand when they
> use (setq x 123) at top-level, which beginners tend to do a lot? --
> but this is just a supposition of mine.

CMUCL user interface is bare-bone (no readline!).

CMUCL can't be  compiled without CMUCL.  And even  with CMUCL binaries
installed, I've  got big difficuties to  compile it. The  fact that it
cannot be  compiled without itself poses  a big security  risk (it may
contain a backdoor  in the binaries which replicate  it into the newly
compiled versions).  That means that  once I'll have compiled it, I'll
need to disassemble and analyze the binary.  At least, they could have
requested just ANY Common-Lisp interpreter to run the CMUCL compiler.

=20
> Your suggestions/ideas are welcome,
> 	J=F6rg H=F6hle.

Well the only bad point I find in CLISP, is its .d sources.

I  liked Squeak  (a  Smalltalk implementation)  which  is a  byte-code
virtual  machine  like  CLISP,   but  which  is  entirely  written  in
Smalltalk. It contains a generator to  C for a small core of SmallTalk
which is used to compile the rest of the system.  So everything can be
changed from  the Smalltalk image  in Smalltalk, without  messing with
push/pop and other low-level C stuff...


Note, while for my own programs CLISP and its byte-compile is perfect,
I'll need a native compiler to  deploy a tool for a customer.  Perhaps
it's one thing  that could be ported to CLISP:  a native compiler like
the one of CMUCL. Not necessarily integrated into CLISP, personnaly, I
don't  mind  the byte-code  in  CLISP (I'd  rather  prefer  it in  the
interactive environment, and for  it's platform independance I think),
but being able to generate  a binary program could be handy sometimes,
either for performance or for psychological reasons.


Another thing  that seems inferior in  CLISP with respect  to CMUCL is
the handling of the unix signals. =20


The  FFI is  important  but we  need a  common  FFI API  over all  the
Common-Lisp implementations  to be able to  develop portable interface
packages to external libraries.


--=20
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.