From: Ian Price <ianprice90@googlemail.com>
To: guile-devel@gnu.org
Cc: "Chris K. Jester-Young" <cky944@gmail.com>
Subject: Re: Mutable top-level bindings
Date: Wed, 17 Apr 2013 21:25:13 +0100 [thread overview]
Message-ID: <874nf4lxau.fsf@Kagami.home> (raw)
In-Reply-To: <20130417152753.GA13533@lotus.destinee.acro.gen.nz> (Chris K. Jester-Young's message of "Wed, 17 Apr 2013 11:29:11 -0400")
"Chris K. Jester-Young" <cky944@gmail.com> writes:
> With a proper module system, I don't see why top-level bindings should
> be mutable. That would make even things like direct inlining of cons or
> + somewhat harder than it needs to be. The way I understand it, the
> definition of (@ (guile) cons) or the like should not be subject to
> change at runtime. If people want to change the behaviour of cons, write
> a module that replaces the top-level binding.
Not top-level, but _exports_ and _imports_. While their use is often
ugly, I'm not sure we should do away with all top level mutables.
Since I write a lot of R6RS code, I'm pretty used to the "no mutable
exports/imports" deal. It isn't too bothersome, except in some cases
with macros and so-called implicit exports/imports. (see bottom)
> Yes, this does disable the ability to perform monkey-patching. I don't
> see this as a big loss, but perhaps there are legitimate use cases for
> monkey-patching that I haven't thought of.
It is pretty useful to be able to do redefinition in a different module
at the repl. Perhaps I could come up with a tortured argument to explain
why this is different from mutating a top-level export, but I'll refrain :)
> Another thing we will need to provide is define-values, which allows you
> to make top-level bindings that are mutually-recursive. By which I mean:
>
> (define-values (foo bar baz)
> (letrec ((foo ...)
> (bar ...)
> (baz ...))
> (values foo bar baz)))
+1
> This would obviate the need to use the following pattern:
>
> (define foo #f)
> (define bar #f)
> (define baz #f)
> (letrec ((my-foo ...)
> (my-bar ...)
> (my-baz ...))
> (set! foo my-foo)
> (set! bar my-bar)
> (set! baz my-baz))
This example is one that does not work in R6RS if you export foo, bar,
or baz. To do this, you need an additional set of defines that indirect
to the mutated ones.
e.g. https://github.com/rotty/spells/blob/master/spells/define-values.sls
>
> Granted, there are existing modules that use that approach currently, as
> we don't currently have define-values. But I think it should be possible
> to annotate individual modules as having immutable top-level bindings,
> so that we can gradually migrate modules to the define-values style.
>
* Implicit imports/exports
(http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_sec_7.1)
"An exported macro may, however, implicitly export an otherwise
unexported identifier defined within or imported into the library. That
is, it may insert a reference to that identifier into the output code it
produces."
"All implicitly exported variables are also immutable in both the
exporting and importing libraries. It is thus a syntax violation if a
variable appears on the left-hand side of a set! expression in any code
produced by an exported macro outside of the library in which the
variable is defined...."
--
Ian Price -- shift-reset.com
"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"
next prev parent reply other threads:[~2013-04-17 20:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1288755.1365813667.854.guile-devel@gnu.org>
2013-04-15 11:29 ` vectors are something else Daniel Llorens
2013-04-15 12:28 ` Daniel Hartwig
2013-04-15 14:08 ` Daniel Llorens
2013-04-15 14:17 ` Daniel Hartwig
2013-04-15 14:10 ` vector types poll Daniel Llorens
2013-04-15 22:47 ` Daniel Hartwig
2013-04-16 0:16 ` Daniel Llorens
2013-04-16 2:00 ` vectors are something else Mark H Weaver
2013-04-16 4:10 ` Daniel Llorens
2013-04-16 6:19 ` Mark H Weaver
2013-04-16 8:31 ` Daniel Llorens
2013-04-17 15:29 ` Mutable top-level bindings (was: vectors are something else) Chris K. Jester-Young
2013-04-17 17:53 ` Mutable top-level bindings Mark H Weaver
2013-04-17 20:25 ` Ian Price [this message]
2013-04-20 14:00 ` Ludovic Courtès
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=874nf4lxau.fsf@Kagami.home \
--to=ianprice90@googlemail.com \
--cc=cky944@gmail.com \
--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).