From: Mark H Weaver <mhw@netris.org>
To: guile-devel@gnu.org
Subject: Re: Mutable top-level bindings
Date: Wed, 17 Apr 2013 13:53:53 -0400 [thread overview]
Message-ID: <878v4hdowe.fsf@tines.lan> (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")
Hi Chris,
"Chris K. Jester-Young" <cky944@gmail.com> writes:
> 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.
Well, if top-level bindings are immutable, then you have to restart the
system, and possibly even recompile .go files that incorporated
assumptions about the immutable bindings, in order to change a binding.
This is quite contrary to the Lisp and Scheme tradition of course.
My preference would be to provide a way to mark bindings as "rarely
mutated", such that the compiler could treat them as immutable. The
binding could still be mutated, but mutation would be very expensive: it
would cause all compiled code that incorporated assumptions about that
binding to be immediately invalidated. This is hard to implement,
though, because it requires "on stack replacement".
> 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.
Currently, our compiler treats several bindings in (guile) such as '+',
'car', 'cdr', 'cons', 'eq?', etc, as if they were immutable. See
(language tree-il primitives) for the full list. However, it's not
handled very well: you are still allowed to mutate those bindings, and I
guess the evaluator will pick up the changes but the compiler won't.
> 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)))
Yes. I started work on this quite a while ago, but got distracted.
Doing the job right requires changes to the "fixing-letrec" pass of the
compiler. I started by reimplementing the improved "fixing letrec
reloaded" algorithm (with some fixes), but for various reasons it's not
yet ready for publication. The next step is to finish that work and to
extend it to handle letrec-values and letrec*-values.
Regards,
Mark
next prev parent reply other threads:[~2013-04-17 17:53 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 ` Mark H Weaver [this message]
2013-04-17 20:25 ` Mutable top-level bindings 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=878v4hdowe.fsf@tines.lan \
--to=mhw@netris.org \
--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).