On the other hand, it would be nice if every internal SBCL function/variable had a docstring.  It would make SBCL hacking less of a daunting reverse-engineering task for future generations.

Docstrings won't entire solve that problem, but wouldn't be a bad start.


On Wed, Feb 23, 2011 at 1:09 AM, Stas Boukarev <stassats@gmail.com> wrote:
Marko Kocić <marko.kocic@gmail.com> writes:

> HI all,
> I was playing a bit with slime and its documentation facilities, and
> constructed quickly a small function to find all symbols that are not
> documented.
> The results are the following:
> ECL -   CL package - 707 documented, 271 undocumented
> ECL - EXT package -   45 documented, 376 undocumented
> SBCL - CL package - 685 documented, 293 undocumented
> CCL -   CL package - 608 documented, 370 undocumented
> ABCL - CL package -    8 documented, 970 undocumented
> Winner by number of documented symbols is ECL, while CCL, and
> especially SBCL subjectively seems to have more elaborate docstrings,
> with longer explanations.
> Is anyone aware is it possible to automatically parse hyperspec in
> order to create docstring that can be added to sources later?
> Or, to teach slime to use hyperspec as a fallback for CL symbols that
> are not documented in implementation?
> Code used to count:
> (defun documented-p (sym)
>     (let ((vdoc (swank::documentation sym 'variable))
>           (fdoc (swank::documentation sym 'function)))
>       (or vdoc fdoc)))
> (length (loop for s being the external-symbols of (find-package :cl)
>               when (documented-p s)
>             collect s))
There is rarely any value in looking for documentation of symbols in CL
package, I always use C-c C-d h (slime-documentation-lookup) to lookup
them in CLHS.

With Best Regards, Stas.

Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
Sbcl-devel mailing list