[Openmcl-devel] Documentation and Arglist

[Gary Byers]

On Wed, 18 Dec 2002, Sven Van Caekenberghe wrote:

>
> Thx, now it works!
>
> But it only preserves arglists, not documentation strings (I don't
> think there are many documentation strings in the open mcl source
> code). I wrote some code to scavenge most doc strings of commercial mcl
> (or any other CL ;-) ) and store them inside openmcl:

I wonder why it's not preserving doc strings.  (It might take a little
effort to actually -find- a function that contains a doc string ...)

Ah.  In ccl::level-0;l0-def.lisp, we have:

(defun bootstrapping-set-documentation (symbol doc-type doc-string)
  (declare (ignore symbol doc-type doc-string))
   string)

and cruft to make that be what happens when (SETF DOCUMENTATION)
is invoked.  That definition stays in effect until fairly late
in the loading sequence.

I'm fairly sure that that could be made to work (in much the
same way that source file information's retained during the
cold load, but I'd agree that there probably aren't that many
doc strings getting ignored.

>
> [code to collect doc info from inside a running CL.]
>
> If you execute (collect-info-to-file "mcl-doc.lisp") in MCL, and later
> (load-info-from-file "mcl-doc.lisp") and then
> (install-all-symbol-documentation) in OpenMCL, most CL level
> documentation gets installed.
>
> Technically, the above code is not perfect (not all documentation types
> are handled, and the distinction between functions and macros isn't
> done well), but it works great from ILISP.
>
> The question is: can we do this legally ?

I'm not sure; it's another question to ask Digitool.  (I'd also be
interested in some of the hardcopy (PDF) documentation they provide,
or at least the source to that.)

It'd be interesting to see if the result of extracting CL doc strings
from CMUCL (which is in the public domain) would be useful.

(Some code in MCL and OpenMCL came from CMUCL, and some came from
a predecessor (SPICE Lisp), so some of the CMU doc strings may
match the handful of doc strings that're actually in the sources.)

>
> I think a procedure (by means of a script like .lisp file) that turns
> the standard image into a new development image with arglist and
> documentation info would be a great idea.
>
> Alternatively, you could make the standard image contain all this info,
> and have a procedure to remove the info to save some space.
>

Several months ago, I had the stunning (for me) realization that users
would probably prefer that OpenMCL came up in the CL-USER package and
didn't require that sources be installed in order for LOOP and other
things to work.

It's just a hunch, but I'm starting to suspect that having access to
better (online and offline) documentation would make OpenMCL easier
for more people to use.

> Sven
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel