unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Noah Lavine <noah.b.lavine@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] Turn on more documentation
Date: Mon, 14 May 2012 10:05:38 -0400	[thread overview]
Message-ID: <CA+U71=P0=bVgzvN7wqcAe_hdFfsDHFmEgKCrnxHgRvtiodjf3w@mail.gmail.com> (raw)
In-Reply-To: <87k40fszd5.fsf@gnu.org>

Hello,

> From “Organisation of this Manual”:
>
>  *Chapter 6: Guile API Reference*
>       This part of the manual documents the Guile API in
>       functionality-based groups with the Scheme and C interfaces
>       presented side by side.
>
>  *Chapter 7: Guile Modules*
>       Describes some important modules, distributed as part of the Guile
>       distribution, that extend the functionality provided by the Guile
>       Scheme core.
>
> So I think the idea is for core functionality to be in Chapter 6, and
> “peripheral things” to be in Chapter 7.  The modules you mention would
> fall in the second category, I think.

That's certainly enough for this project, but I think in general this
distinction is not very clear. How would someone guess what
functionality is considered "core" and what functionality is an
extension? My first guess would be that things in the (guile) module
are core and everything else is an extension, but that is not the
case. Does this come from an earlier time when the Guile core was
distributed separately from the Guile libraries?

Unless there is going to be some other distinction between core and
extensions, it would seem more natural to me to document everything by
functionality, in the same part of the manual. Some sections would
correspond to modules, because modules are also supposed to group
things by functionality, but that would not be the rule for how the
manual worked. What do you think?

Noah



  reply	other threads:[~2012-05-14 14:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-03  3:20 [PATCH] Turn on more documentation Noah Lavine
2012-05-03 22:07 ` Noah Lavine
2012-05-06 10:14 ` Ludovic Courtès
2012-05-07 12:30   ` Noah Lavine
2012-05-07 14:31     ` Ludovic Courtès
2012-05-12 20:56       ` Noah Lavine
2012-05-14 12:47         ` Ludovic Courtès
2012-05-14 14:05           ` Noah Lavine [this message]
2012-05-14 15:00             ` Ludovic Courtès
2012-05-14 15:14               ` Noah Lavine
2012-05-15 20:24                 ` Andy Wingo
2012-05-15 21:25                   ` Ludovic Courtès
2012-05-16  0:19                     ` Noah Lavine
2012-05-14 21:26             ` dsmich
2012-05-15 20:19   ` Andy Wingo

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='CA+U71=P0=bVgzvN7wqcAe_hdFfsDHFmEgKCrnxHgRvtiodjf3w@mail.gmail.com' \
    --to=noah.b.lavine@gmail.com \
    --cc=guile-devel@gnu.org \
    --cc=ludo@gnu.org \
    /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).