Immutable things.

[Dwight Hughes]

| From: Christopher J. Vogt <vogt@novia.net>
| > From Dwight Hughes <dhughes@intellinet.com>
| >I would not want to replace CL with something different for everybody
that
| >uses the system - having CL as a *high-level* standard for the LispOS is
| >fine.
| >Using it for programming the kernel, and making it efficient at this on
| >vanilla hardware, is not my idea of a good time. Would you like to have
a
| >10MB kernel? This could be what you would get with a LispOS programmed
in
| >CL. That could make Windows 95 seem like a speed-demon in comparison --
not
| >exactly a goal I would be proud of.
| 
| I'm not sure what all you see in the "kernel", but you can have a
complete
| CL implementation in less than 2MB (see MCL), so I'm not sure where you
are
| seeing 10MB?
  [snip] 
Perhaps I exaggerated slightly. Most implementations of CL I have worked
with (Windows based) have significant problems separating code from the
runtime image. (I haven't worked with MCL - but I do know it has a good
ability to do so. Its internal design may be more layered or more
factored (?).) "Hello World!" can run 3MB or more. This monolithic
structure
is a pain -- add to it that you don't normally know just what parts of
the runtime are being used by the system to support your code, so you
don't know what you can weed out (there is no standard definition of
required primitives to support CL that I know of). And due to the 
mutable nature of so much of CL, your compiler doesn't either, most of
the time. (By the way, even 2MB is way too big for a kernel in my opinion.)
As has been pointed out by others, the various data structures of CL
are powerful but most are quite heavy-weight, not a good match for
working near the hardware. I think Henry Baker would call it "abstraction
inversion" - the representation of lower-level, simpler structures
using higher-level abstractions - quite inefficient, both in memory
required and in performance.

-- Dwight