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

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Thu Apr 10 03:30:13 2003

Hi,

I'm wondering what attracts people to CLISP. Maybe developers could then concentrate efforts on these distinguishing areas.

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

~ perhaps UNICODE, but Allegro seems to have the reputation of The Lisp with excellent unicode support

~ perhaps speed?
This came out as a surprise to me yesterday, but my Logfile-analysis application works faster in CLISP than in Corman Lisp (which compiles to native code), even without my recent FAST-VECTOR-POSITION accelerator hack!
So far, it's not a fair comparison: I spent days analysing where slowness occurred in CLISP (e.g. certain calls to parse-integer), and just compiled the thing in CormanLisp, without any optimization settings. More on this another time.

I don't believe people are attracted by:
- FFI (too restrictive in the past, but with some jewels, esp. the very expressive def-call-out)
My bet is people just want the interface stuff to work, so that they can concentrate on the application instead.

- CLOS/MOP
Several people (e.g. Tim Bradshaw) were turned away by CLISP's CLOS missing MOP features or other restrictions in CLISP's implementation of CLOS.
I once suggested that CLISP might contain FAQ/documentation entries on how PCL can be used instead of its builtin-closs. Each CLISP release could ensure that it still runs with the latest PCL. Then people in havy needs of a full CLOS/MOP could use that, like I believe CMUCL does.
FWIW, CLISP's CLOS once was PCL, before it got replaced by a more efficient but more restricted builtin-version of its own.
I cannot propose to do that, since I don't have any need for CLOS+MOP.

- inspector/debugger/stepper, yet Corman's seems even less powerfull (more lacking?) than CLISP's (grain of salt here, I have only been using CormanLisp for 2 days)

- GUI - no McClim, no cello, don't know about garnet, ...
What are CLISP-users using here?

- ...?

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.

Your suggestions/ideas are welcome,
	Jörg Höhle.

---

From: Doug Philips <[email-masked]>
Date: Thu Apr 10 05:44:04 2003

On Thursday, Apr 10, 2003, at 05:15 US/Eastern, Hoehle, Joerg-Cyril 
indited:

> I'm wondering what attracts people to CLISP. Maybe developers could 
> then concentrate efforts on these distinguishing areas.

Portability is a big one, Linux (PPC, x86), MacOS/X, etc.

> Lisp with excellent unicode support

Unicode would be a big win. Its hard to imagine taking an application 
international without it.

> My bet is people just want the interface stuff to work, so that they 
> can concentrate on the application instead.

Yup. Haven't bothered yet (want too keep cross platform stuff really 
cross platform without porting FFI related Hooey.

> - CLOS/MOP
> Several people (e.g. Tim Bradshaw) were turned away by CLISP's CLOS 
> missing MOP features or other restrictions in CLISP's implementation 
> of CLOS.

So far hasn't been an issue, but at least CLISP will be good enough for 
first pass, proof of concept.

> I cannot propose to do that, since I don't have any need for CLOS+MOP.

Me neither at the moment.

> What are CLISP-users using here?

Nothing as of yet. Would like to somehow get Hemlock there, but not so 
badly (yet) to do it myself. Problem is that with extreme portability 
its hard to do much "nice" and I'm personally not willing to make it 
harder to port to get a GUI.

> Your suggestions/ideas are welcome,

Thanks. I've only been using CLISP for a few weeks, but I like that I 
can use the same thing everywhere (OK, I couldn't build 2.30 on Mac 
OS/X myself, but I haven't tried the latest tree ;-) I'm getting use 
from 2.29 ).

-D'gou

---

From: C Y <[email-masked]>
Date: Thu Apr 10 06:46:10 2003

> What are CLISP-users using here?

Garnet actually runs quite well on Clisp on Linux, but it is not yet
truly cross platform and is never likely to be cross platform on nearly
as many platforms as Clisp itself is.  It might attract more users if
it's look were a little more "modern" but it doesn't work with CLOS
without writing a glue layer between the garnet object system and CLOS
itself.

Essentially, there are very few native lisp GUI apps being written
currently.  Hopefully this situation will improve someday.

CY

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

---

From: Scott Williams <[email-masked]>
Date: Thu Apr 10 07:00:13 2003

>I'm wondering what attracts people to CLISP. Maybe developers could then concentrate efforts on these distinguishing areas.
What initially attracted me is the fact that you can build it on your 
own. When i first got involved with lisp, cmucl wouldn't build without 
already having a binary installed, SBCL was unusable, and i had a hard 
time getting gcl to compile.

-Scott

---

From: Pascal Bourguignon <[email-masked]>
Date: Thu Apr 10 09:11:07 2003

Hoehle, Joerg-Cyril writes:
> + 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.

> Your suggestions/ideas are welcome,

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.  

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.

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

---

From: "Johannes Grødem" <[email-masked]>
Date: Fri Apr 11 08:45:06 2003

* Doug Philips <[email-masked]>:

> Unicode would be a big win. Its hard to imagine taking an
> application international without it.

AFAIK, CLISP has excellent Unicode-support.  (And has had so for a
while, I think.)

-- 
Johannes Grødem <OpenPGP: 5055654C>