Re: Hello

[Don Cohen <donc@ISI.EDU>]

  widely perceived by people in NASA to be too big and slow for "real" work.
Not only NASA, of course.  The too big seems particularly galling to me,
since several good lisps (inc CLISP) run in what's rapidly becoming a
negligible amount of space; the too slow has often annoyed me coming from
people who don't even have concrete speed requirements.  (Slower than the
corresponding C program doesn't seem relevant to me - it's not a race.)

Cross compiling: since the lisp code is byte compiled, I had originally
expected that clisp would be compiled code compatible across all platforms.
It turns out that this is not true.  But it's close.  I spent a little
time looking into how to make it so, but didn't actually do it.  I really
don't think it's difficult, except for macros that expand differently for
different machines.  I'm pretty sure all the system supplied macros could
be easily fixed to compile into the same byte code for all machines (put
the machine dependence into functions called by the expansion).  Of course,
the programmer would be responsible for his own macros.

Threads: That's something else I'd have liked, but haven't actually needed
yet.  There has been some mailing list discussion on this topic.
I don't know enough about the internals to know how hard it is to do.
Unfortunately, I'd guess it IS necessary to know a lot about the internals
of clisp in order to know what is needed.  Thus, even if it's not actually
hard to do, it might be hard to find out or to get someone who knows to do
it.

P.S. on GC - I believe the normal way to avoid GC is to write your code
to avoid allocating space - not natural in lisp, but it can be done.