Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Long ago, as best I recall, the nonANSI parts of SBCL were usefully
described as small perturbations on the large extensions common to CMU
CL, the SBCL user manual (such as it was) was a lightly edited CMU CL
user manual, and a large fraction of users coming to SBCL could be
expected to be familiar with CMU CL. It seems to me that all those
things are less true now, and I propose to simply delete the
DIFFERENCES FROM CMU CL section of the man page instead of trying to
keep it up to date.
any feedback? I have this feeling that I might not be a sufficiently
typical user to guess the significance of this...
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
All growth is permanent. -- spam title from sbcl-announce
On 1/10/08, William Harold Newman <william.newman@...> wrote:
> any feedback? I have this feeling that I might not be a sufficiently
> typical user to guess the significance of this...
I think that section can die a quiet death, (Now that I've looked that
way, the man-page generally seems in sore need of some loving attention.
Perhaps we should do the "generate man-page from --help, and put everything
else in the real manual" thing?)
While I think it is more then correct to describe SBCL as a CMUCL
derivative, I agree that it is probably incorrect to overly emphasize
that (I admit to being slightly irked by the common references to SBCL
as a fork of CMUCL, with more emphasis on maintainability -- which is
both exactly true and ,,,"not quite".)
Whatever SBCL is, it derives from CMUCL, and while it originally was a
fork of CMUCL, describing it as one seems slightly misleading as best.