Quote:
> For some time now, I have been following SBCL and the attempts to make
> it more "buildable" and clean.
> What I have been looking for are signs that SBCL is moving towards
> becoming a self-hosting Common Lisp.
> By self-hosting I mean a system that could, once some kernel code is
> executable on a target platform, build itself upwards to selectable or
> programmable implementation levels. There is the old saying that Lisp
> can be defined in itself, i.e. in Lisp. The question is: Can SBCL, or
> CMUCL ever be expected to become buildable without using a full Common
> Lisp?
I'm not sure I entirely understand what you mean by "self-hosting",
but I think it's not a good term for what you're trying to express.
CMUCL is *quite* self-hosting -- it needs itself to build itself.
Why would you want to write a large complex system (a CL system for
example) in something other than full Common Lisp? Do you mean C or
C++ or a subset of CL? And would you really want to build a Lisp
system in that language, when you could have all of CL?
If the point is to be able to install SBCL by unpacking some sources
and typing "./configure && make && make check && make install" like a
lot of unix software, it's nearing that ability. The above line is
how you install CLISP, and SBCL is moving in the direction of being
able to be built by CLISP. Part of the reason for the fork was to
make SBCL a system that could be built by any CL. With one of those
able to be built using just a C compiler...
Quote:
> Daniel Barlow mentioned in an earlier thread that a lot could be said
> about the VOPs. This has lead me to some questions of a general nature,
> which is why I put them in this n.g.
I asked about this on the sbcl-help list and he responded in some
detail, which you may be interested in:
<http://www.geocrawler.com/archives/3/1664/2001/8/0/6521166/>
Quote:
> - How "tangled" is the CMCUCL/SBCL internal code really?
> - Can interdependencies between different parts of the
> code be reduced with a reasonable effort, whatever
> reasonable means?
These questions are different form "can it be made to not need a full
CL system?". This more or less asks if it can be built from a
different CL system; which as I already mentioned is a goal of SBCL
(but not CMUCL).
[...]
Quote:
> - Is some kind of layering possible (of course it is). Are there
> any thoughts about doing it?
What kind of layering do you have in mind? There's already a
kernel/rest layering, but perhaps you're thinking more of something
along the lines of a kernel in C, a CL0 needing only the kernel, a CL1
needing only CL0, and CLOS needing only CL1? This might be an
interesting approach for a new implementation, but I think
retrofitting an existing implementation to this model would be a
serious pain. SBCL has done a lot of work towards identifying and
managing interdependencies in the part written in CL, though.