POS, OOFS, CL v Scheme, etc.

[Kelly Murray]

>From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)
> do this, I'd indeed suggest to extend Scheme rather than Common
> Lisp, since a sufficiently careful and exhaustive review and re-
> implementation of Common Lisp would probably be beyond our short-
> term capacity (note that this would affect the optimizer deeply).

I'll use this reply to clarify what I meant by 90% of this
LispOS system would be portable CL.  What I should have said is that
90% of the code would be portable *TO* a CL system, as in it
can run on top with little trouble or modification.
I think it is mostly removing or tweaking CL things, rather than
wholesale replacement.  

I agree with hbaker about making lists be read-only,
it is an excellent idea.

That is how they work in AllegroStore today.
Destructively modifying a list does not change the contents of the
database, simply because the lists are copied to transient memory
when read from the database.  It wasn't really a design decision,
but a result of the implementation.

I note that probably 99% of all the lists in an ACL image
are read-only.  By allowing that to be 100%, a huge amount of data
can be put into a read-only memory segment and shared efficiently.

Using destructive list operations is ancient-style lisp coding.

-kelly