unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: "François J" <francois-oss@avalenn.eu>
To: guile-devel@gnu.org
Subject: [PATCH] doc: local definitions always take precedence over use-modules
Date: Mon, 13 Dec 2021 15:34:45 +0100	[thread overview]
Message-ID: <20211213143445.z4ggaxk7rl7jphup@noop.avalenn.eu> (raw)

* doc/ref/api-modules.texi (Using Guile Modules): improve wording on
  example about conflict between local definitions and imported ones
---
 doc/ref/api-modules.texi | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/ref/api-modules.texi b/doc/ref/api-modules.texi
index 05a19cc16..8e0f41c25 100644
--- a/doc/ref/api-modules.texi
+++ b/doc/ref/api-modules.texi
@@ -113,12 +113,12 @@ Here, the interface specification is @code{(ice-9 popen)}, and the
 result is that the current module now has access to @code{open-pipe},
 @code{close-pipe}, @code{open-input-pipe}, and so on (@pxref{Pipes}).
 
-Note in the previous example that if the current module had already
-defined @code{open-pipe}, that definition would be overwritten by the
-definition in @code{(ice-9 popen)}.  For this reason (and others), there
-is a second variation of interface specification that not only names a
-module to be accessed, but also selects bindings from it and renames
-them to suit the current module's needs.  For example:
+Note in the previous example that if the current module already defines
+@code{open-pipe}, that definition has precedence over the definition in
+@code{(ice-9 popen)} we try to import.  For this reason (and others),
+there is a second variation of interface specification that not only
+names a module to be accessed, but also selects bindings from it and
+renames them to suit the current module's needs.  For example:
 
 @cindex binding renamer
 @lisp
-- 
2.32.0



                 reply	other threads:[~2021-12-13 14:34 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20211213143445.z4ggaxk7rl7jphup@noop.avalenn.eu \
    --to=francois-oss@avalenn.eu \
    --cc=guile-devel@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).