unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.uklinux.net>
To: Mark Harig <idirectscm@aim.com>
Cc: wingo@pobox.com, guile-devel@gnu.org
Subject: Re: Patch: New section "Invoking Guile" for chapter "Programming in Scheme"
Date: Wed, 27 Apr 2011 20:40:17 +0100	[thread overview]
Message-ID: <87vcxz5vq6.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <8CDD312F8902D56-2538-152DE@webmail-m127.sysops.aol.com> (Mark Harig's message of "Wed, 27 Apr 2011 12:54:56 -0400")

Mark Harig <idirectscm@aim.com> writes:

>> > +The @var{function} is most often a simple symbol that names a function
>> > +that is defined in the script.  It can also be of the form @code{(@@
>> > +@var{module-name} @var{symbol})}, and in that case, the symbol is
>> > +looked up in the module named @var{module-name}.
>>
>> You inserted a comma here before "@var{symbol})}, and in that case".  I
>> agree that a comma was needed, but would have put it as "@var{symbol})}
>> and, in that case, the ...".  What do you think?
>>
>
> Is the sentence of the form 1) "A and B" or of the form 2) "A, and some
> supplemental information about A"?  I think it is 2).  Then, you are
> left with the choice of how many commas:
>
> 1) "A, and, in that case, B"
> 2) "A, and in that case, B"
> 3) "A and, in that case, B"
>
> Either choice 1) or 2) gets my vote.  Choice 3) is, I think, an error.

I'm not sure it's completely clearcut but yes, I see your point.  In
that case I might technically favour 1), but then that's a lot of
commas.  But, in any case, ...

> Another perspective: Re-write the sentence, replacing "and in that
> case" with "in which case."  This should make it clearer that the
> sentence consists of a main clause and a sub-clause (preceded by a
> comma), not two main clauses.

... this is a much nicer idea than any of the above!

>> > +@table @env
>> > +@item GUILE_AUTO_COMPILE
>> > +@vindex GUILE_AUTO_COMPILE
>> > +This is a flag that can be used to tell Guile whether or not to compile
>> > +Scheme source files automatically.  Starting with Guile 2.0, Scheme
>> > +source files will be compiled automatically, by default.
>>
>> Is it useful to say "Starting with Guile 2.0" in a post-2.0.0 version of
>> the manual?  I think that expression could be deleted now.
>>
>
> That's a consequence of the fact that I looked up what information I
> could find from the NEWS file, and then used that text as an initial
> version.
>
> I agree that it's not the best solution to the problem, but the
> problem is "how does the manual convey to long-time Guile users this
> change in behavior?"  I do not have a good solution to that in this
> brief patch.  For now, experienced users will and should rely on the
> NEWS file to inform them about changes in behavior.

Agreed.  I think it makes sense overall for the manual to describe the
status quo (plus the history section, for fun) and for NEWS to cover
changes.

(Notwithstanding that there are some occurrences in the manual source of
`@vnew{...}', which I guess was/is an attempt to codify such things
(when features changed, or were introduced) in the manual source.  As
far as I know this usage has never been sufficiently widespread to be
reliable.)

Regards,
        Neil



  reply	other threads:[~2011-04-27 19:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-23 19:46 Patch: New section "Invoking Guile" for chapter "Programming in Scheme" Mark Harig
2011-04-24 14:33 ` Andy Wingo
2011-04-24 20:36   ` Mark Harig
2011-04-24 21:00     ` Andy Wingo
2011-04-24 21:58       ` Mark Harig
2011-04-25  8:01         ` Andy Wingo
2011-04-24 22:09       ` David Pirotte
2011-04-24 22:43         ` Indexing Scheme and C identifiers separately Mark Harig
2011-04-25  1:18           ` Noah Lavine
2011-04-25 16:16           ` David Pirotte
2011-05-20 22:53             ` Neil Jerram
2011-04-25 19:49       ` Patch: New section "Invoking Guile" for chapter "Programming in Scheme" Mark Harig
2011-04-26 18:07         ` Neil Jerram
2011-04-26 21:01           ` Ludovic Courtès
2011-04-27  9:40             ` Andy Wingo
2011-04-27 10:23               ` Ludovic Courtès
2011-04-27 19:29                 ` Neil Jerram
2011-04-27 16:54           ` Mark Harig
2011-04-27 19:40             ` Neil Jerram [this message]
2011-06-30 11:23         ` 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=87vcxz5vq6.fsf@ossau.uklinux.net \
    --to=neil@ossau.uklinux.net \
    --cc=guile-devel@gnu.org \
    --cc=idirectscm@aim.com \
    --cc=wingo@pobox.com \
    /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).