guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (ice-9 documentation) `find-documentation' to be exported


From: thi
Subject: Re: (ice-9 documentation) `find-documentation' to be exported
Date: Tue, 24 Apr 2001 13:05:25 -0700

   From: Neil Jerram <address@hidden>
   Date: 24 Apr 2001 19:36:53 +0100

   I think I'd rather export just `find-documentation-in-file', since it
   has a more specific interface and therefore seems to offer fewer
   guarantees about tight integration with the documentation system in
   the future.

sounds reasonable, although i predict in practice people will then
privately re-implement `find-documentation' anyway.  actually, it seems
to me that the more general an interface, the more room there is to
change the implementation.

if you are dead-set against exporting `find-documentation', that's ok,
too -- i'll simply include its definition in the writeup and a blurb
urging readers to remind guile developers to export such a useful
procedure.  ;->

   Well the format will either change or become obsolete, so as to
   accommodate doc stuff other than just the docstring, although probably
   not for some time.  I think that (i) a writeup would be well
   worthwhile in the interim, and (ii) it makes sense to associate the
   documentation of the file format specifically with
   `find-documentation-in-file', then people who choose to may continue
   to use that format and `find-documentation-in-file' even if/when
   Guile's help system is no longer based on it.

cool, i'll take (i) as a thumbs-up on the writeup.

(ii) is the general versioning issue.  probably better to name the
current format as "version 1" (or whatever) and then figure out a
(hopefully simple) transition protocol.  i see that the current version
skips to the first form feed.  we can specify forms read before that as
meta info, with `(version N)' required as the first.  so the format
would be:

   (version 1)
   (author "guile-doc-snarf")
   ;; etc
   ^Lacons
   ...

i think this kind of approach has less potential for latent confusion
than associating specific procs to functionality.

thi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]