From: "Chris K. Jester-Young" <cky944@gmail.com>
To: guile-devel@gnu.org
Subject: Mutable top-level bindings (was: vectors are something else)
Date: Wed, 17 Apr 2013 11:29:11 -0400 [thread overview]
Message-ID: <20130417152753.GA13533@lotus.destinee.acro.gen.nz> (raw)
In-Reply-To: <87haj72q08.fsf@tines.lan>
On Mon, Apr 15, 2013 at 10:00:55PM -0400, Mark H Weaver wrote:
> Unfortunately, this is rarely possible in a language like Scheme, where
> calls to procedures bound by mutable top-level variables are frequent.
> We cannot fix this without making most commonly-used top-level bindings
> immutable. Last I checked, there was strong resistance to this idea.
Maybe it's time to reopen this (and hope it's not a can of worms). :-)
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.
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.
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)))
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))
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.
Cheers,
Chris.
next prev parent reply other threads:[~2013-04-17 15:29 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 ` Chris K. Jester-Young [this message]
2013-04-17 17:53 ` Mutable top-level bindings Mark H Weaver
2013-04-17 20:25 ` Ian Price
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=20130417152753.GA13533@lotus.destinee.acro.gen.nz \
--to=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).