From: Mikael Djurfeldt <djurfeldt@nada.kth.se>
Cc: djurfeldt@nada.kth.se
Subject: Re: Strange undefined binding bug coupled to module system
Date: Sun, 24 Oct 2004 20:55:21 +0200 [thread overview]
Message-ID: <xy71xfohrom.fsf@nada.kth.se> (raw)
In-Reply-To: <E1CKGGL-0004pS-IU@witch> (Mikael Djurfeldt's message of "Wed, 20 Oct 2004 15:12:21 +0200")
Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:
> Loading of the following code:
>
> foo.scm:
> ----------------------------------------------------------------------
> (define-module (foo))
>
> (define (encapsulate proc)
> (lambda (_) (proc _)))
>
> (display round)
> (newline)
> (define round (encapsulate round))
> ----------------------------------------------------------------------
>
> Gives (since some change during last spring):
>
> guile> (load "foo.scm")
> #<primitive-procedure round>
>
> Backtrace:
> In unknown file:
> ?: 0* [primitive-load "foo.scm"]
> In foo.scm:
> 8: 1* (define round (encapsulate round))
> 8: 2* [encapsulate ...
>
> foo.scm:8:15: While evaluating arguments to encapsulate in expression (encapsulate round):
> foo.scm:8:15: Unbound variable: round
> ABORT: (unbound-variable)
OK, I've found the change which causes it:
2004-04-22 Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>
(scm_m_define): Change order to first create binding and
evaluating the expression afterwards.
While this change works in the R5RS situation without a module system,
the presence of a module system, with the difference between imported
and local bindings, introduces complications.
It seems like, in the case where no local binding exists before, that
local binding should be created *initialized* to the value of the
corresponding imported binding, if that exists. That is not done now,
which causes the above described non-intuitive behavior.
Since it's not immediately obvious to me how to fix this in a good
way, I'll leave that to you guys. But please keep in mind that
variable lookup is a substantial part of loading time in Guile. We
wouldn't want to make *two* eval closure traversals by invoking
scm_sym2var twice (with different value of definep) or something like
that.
M
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
next prev parent reply other threads:[~2004-10-24 18:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-20 13:12 Strange undefined binding bug coupled to module system Mikael Djurfeldt
2004-10-24 18:55 ` Mikael Djurfeldt [this message]
2004-11-04 14:10 ` Marius Vollmer
2004-11-10 8:51 ` Mikael Djurfeldt
2004-12-15 17:29 ` Marius Vollmer
2004-12-15 19:16 ` Mikael Djurfeldt
2004-12-22 15:35 ` Marius Vollmer
2004-12-22 20:29 ` Mikael Djurfeldt
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=xy71xfohrom.fsf@nada.kth.se \
--to=djurfeldt@nada.kth.se \
/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).