From: rm@fabula.de
Cc: rm@fabula.de
Subject: State of Docs [was] Re: Around again, and docs lead role
Date: Fri, 9 May 2003 00:32:42 +0200 [thread overview]
Message-ID: <20030508223242.GB3465@www> (raw)
In-Reply-To: <m3of2eqsht.fsf@laruns.ossau.uklinux.net>
On Wed, May 07, 2003 at 11:52:46PM +0100, Neil Jerram wrote:
> >>>>> "rm" == rm <rm@fabula.de> writes:
>
> rm> I started writing up some info last night but i'm not shure
> rm> whether the lack of documentation actually manifests some
> rm> public vs. private API issue.
>
> Now, no, it just manifests lack of documentation, I'm afraid :-)
> In the future, though, I do think it would be nice to reach a
> situation where
>
> documented <=> public and supported API
Yes. Right now, whenever i stumble upon a usefull but undocumented
part of the Guile API i'm somehow reluctant to use it since i fear
that it's not as stable as the documented part.
Who to consult in such a case? Guile-devel or Guile-user?
> rm> Hmm, there a a handfull of pretty good Scheme intros
> rm> available, why bother duplicating these efforts (better: write
> rm> a Guile-specific addendum for one of these).
>
> Tricky one, but I think if we get the rest of the GUile docs right,
> and bring more users on board, the need (or not) for this will become
> clearer.
Yes, i would assume that it's up to those who write the documentation
for guile-embedding applications to provide helpfull intros/tutorials.
After all: most general Scheme tutorials will present things like
'my-fact' or 'is-prime?' while users probably want to read about
'print-in-blue' or 'image-blur' ....
> rm> Yes. And it would be _very_ helpfull if the documentation
> rm> would mention what modules need to be "used" for certain
> rm> functions [(ice-9 regexp) for regular expressions ...).
>
> Completely agree; it's just a bug if the necessary use-module isn't
> documented. Patches welcome!
Ok, next time i find one ...
BTW, in case i have a documentation patch: where to send it to?
Post it here?
> rm> Another question: there's some very good information in the
> rm> guile-workbook CVS module. But sometimes it's hard to tell
> rm> whether a piece is documenting an existing fact of Guile or
> rm> rather proposing a new impementation.
>
> IMO the starting assumption should be that workbook stuff is not
> implemented and so not valid as documentation. If you can identify
> any text that is valid, then ideally, please convert it to a patch
> against the manual.
Finally, a proposal: I think it would be rather helpfull if the
documentation for C functions as well as CPP makros would include
the type specifier. So, instead of:
scm_make_vector (k, fill)
give
scm_c_make_vector (unsigned long int k, SCM fill)
Not having the parameter types is sometimes missleading, esp. if
the same parameter name sometimes stands for a C value and sometimes
for a SCM value (see for ex.: 'scm_vector_set_x vector k obj', where 'k'
stands for SCM value).
I'm willing to take over that job and update the relevant parts over
the next few weeks if people find this helpfull.
Thanks,
Ralf
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2003-05-08 22:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-26 7:33 Around again, and docs lead role Neil Jerram
2003-04-26 10:19 ` Thamer Al-Harbash
2003-04-27 20:56 ` Neil Jerram
[not found] ` <3E92E1B40021F4D7@pop3.tiscalinet.es>
2003-04-27 21:01 ` Neil Jerram
[not found] ` <3E92E1B4002B0632@pop3.tiscalinet.es>
2003-04-30 22:47 ` Neil Jerram
[not found] ` <3EAFE4EC000D9733@pop1.tiscalinet.es>
2003-05-07 21:06 ` Doc organization (Re: Around again, and docs lead role) Neil Jerram
2003-05-08 16:21 ` Rob Browning
2003-05-08 17:50 ` rm
2003-05-08 22:47 ` Neil Jerram
2003-10-28 16:09 ` Thien-Thi Nguyen
2003-05-08 22:36 ` Neil Jerram
2003-05-09 2:23 ` Rob Browning
2003-05-09 17:46 ` David Van Horn
2003-05-10 11:32 ` Neil Jerram
2003-05-15 16:02 ` Rob Browning
2003-05-15 16:33 ` Paul Jarc
2003-05-09 11:52 ` Bill Schottstaedt
2003-05-13 23:01 ` Neil Jerram
2003-05-14 1:07 ` Viktor Pavlenko
2003-05-14 14:29 ` Bill Schottstaedt
2003-05-15 7:55 ` Mikael Djurfeldt
2003-05-17 3:02 ` Max Techter
2003-05-09 8:15 ` tomas
2003-05-10 12:01 ` Neil Jerram
2003-05-12 11:40 ` tomas
2003-05-03 4:40 ` Around again, and docs lead role Robert Uhl
2003-05-03 11:34 ` rm
2003-05-03 22:21 ` Robert Uhl
2003-05-03 23:15 ` Thamer Al-Harbash
2003-05-04 8:40 ` David Allouche
2003-05-04 21:34 ` Robert Uhl
2003-05-04 19:47 ` rm
2003-05-04 21:42 ` Robert Uhl
2003-05-04 23:38 ` Thien-Thi Nguyen
2003-05-07 22:52 ` Neil Jerram
2003-05-08 22:32 ` rm [this message]
2003-05-08 23:11 ` State of Docs [was] " Neil Jerram
2003-05-10 0:47 ` State of Docs Kevin Ryde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030508223242.GB3465@www \
--to=rm@fabula.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).