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).