From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Zhu Zihao <all_but_last@163.com>
Cc: Ricardo Wurmus <rekado@elephly.net>,
Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>,
guix-devel@gnu.org
Subject: Re: Semantics of circular imports
Date: Wed, 30 Mar 2022 00:50:45 -0400 [thread overview]
Message-ID: <87bkxoujq2.fsf@gmail.com> (raw)
In-Reply-To: <86ilryr8wl.fsf@163.com> (Zhu Zihao's message of "Mon, 28 Mar 2022 12:24:26 +0800")
Hello,
Zhu Zihao <all_but_last@163.com> writes:
> Philip McGrath <philip@philipmcgrath.com> writes:
>
>> Oh, wow. I definitely had not realized that, *even inside a declarative
>> module*, a reference to a variable with no statically visible definition
>> would semantically be a dynamic lookup in a mutable environment at
>> runtime (rather than a compile-time error), though I do see now that
>> `info guile declarative` does indeed say that marking a module as
>> declarative "applies only to the subset of top-level definitions that
>> are themselves declarative: those that are defined within the
>> compilation unit, and not assigned (‘set!’) or redefined within the
>> compilation unit."
>
> It depends on how you reference to it. If a variable is referenced in
> the same module, it'll be inlined if it's small enough.
>
> If you reference it from another module, it'll do something like
> module-ref instead (works like non-declarative binding)
>
>> This seems like a big barrier to cross-module inlining, though IIUC Guile
>> currently doesn't do much of that by default (maybe for this reason).
>
> Guile 3.0.8 comes to rescue. It works by rewrite the `define-module`
> call and attach the tree-il of some bindings on it.
>
> For details, read the blog post authored by Andy Wingo
>
> https://wingolog.org/archives/2021/05/13/cross-module-inlining-in-guile
Thanks for the interesting read (nice writing from Wingo, as usual :-)).
Maxim
next prev parent reply other threads:[~2022-03-30 5:21 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-20 10:05 Excessively energy-consuming software considered malware? Maxime Devos
2022-02-20 10:48 ` Tobias Platen
2022-02-20 11:13 ` Martin Becze
2022-02-20 16:52 ` Maxime Devos
2022-02-20 20:39 ` Martin Becze
2022-02-24 9:23 ` Hartmut Goebel
2022-02-24 11:18 ` Martin Becze
2022-02-25 0:27 ` Christine Lemmer-Webber
2022-02-25 12:41 ` Bengt Richter
2022-02-25 13:04 ` Tobias Geerinckx-Rice
2022-02-25 16:14 ` Bengt Richter
2022-02-25 16:32 ` Ricardo Wurmus
2022-02-25 16:49 ` Paul Jewell
2022-02-25 17:05 ` Maxime Devos
2022-02-25 17:35 ` Taylan Kammer
2022-02-25 19:00 ` Leo Famulari
2022-04-04 8:00 ` Attila Lendvai
2022-04-04 9:43 ` Maxime Devos
2022-04-04 10:15 ` Maxime Devos
2022-04-04 12:49 ` Attila Lendvai
2022-04-04 10:16 ` Maxime Devos
2022-04-04 10:37 ` Maxime Devos
2022-04-04 11:22 ` indieterminacy
2022-04-04 18:39 ` Liliana Marie Prikler
2022-02-24 9:13 ` Hartmut Goebel
2022-02-24 9:36 ` Attila Lendvai
2022-02-20 11:08 ` Ekaitz Zarraga
2022-02-20 11:27 ` Compiling blender Ricardo Wurmus
2022-02-20 11:34 ` Ekaitz Zarraga
2022-02-20 12:19 ` Faster "guix pull" by incremental compilation and non-circular modules? Maxime Devos
2022-02-20 16:47 ` Philip McGrath
2022-02-20 17:47 ` Semantics of circular imports Maxime Devos
2022-03-27 14:12 ` Philip McGrath
2022-03-27 14:19 ` Maxime Devos
2022-03-27 14:24 ` Maxime Devos
2022-03-27 14:33 ` Maxime Devos
2022-03-27 14:55 ` Maxime Devos
2022-03-28 4:24 ` Zhu Zihao
2022-03-30 4:50 ` Maxim Cournoyer [this message]
2022-02-28 13:17 ` Faster "guix pull" by incremental compilation and non-circular modules? Ludovic Courtès
2022-02-28 18:50 ` Maxime Devos
2022-05-31 4:54 ` Gábor Boskovits
2022-05-31 8:49 ` Maxime Devos
2022-05-31 10:23 ` Ricardo Wurmus
2022-02-20 15:54 ` Compiling blender Ricardo Wurmus
2022-02-20 16:14 ` Ekaitz Zarraga
2022-02-20 12:20 ` Excessively energy-consuming software considered malware? Taylan Kammer
2022-02-20 12:37 ` Maxime Devos
2022-02-20 12:44 ` Taylan Kammer
2022-02-20 14:59 ` Philip McGrath
2022-02-20 18:53 ` Christine Lemmer-Webber
2022-02-20 20:34 ` Jonathan McHugh
2022-02-20 12:32 ` Paul Jewell
2022-02-20 18:26 ` Liliana Marie Prikler
2022-02-20 19:36 ` Ryan Sundberg
2022-02-21 9:29 ` Attila Lendvai
2022-02-21 13:06 ` Maxime Devos
2022-02-21 18:56 ` raingloom
2022-02-21 23:02 ` Attila Lendvai
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://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bkxoujq2.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=all_but_last@163.com \
--cc=guix-devel@gnu.org \
--cc=liliana.prikler@ist.tugraz.at \
--cc=rekado@elephly.net \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).