From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Skyler Ferris Newsgroups: gmane.lisp.guile.user Subject: Re: can't export conditional variable set with 'cond' Date: Fri, 02 Feb 2024 00:13:09 +0000 Message-ID: <2a2cfa98-c787-4664-916f-461c730c8604@protonmail.com> References: <9acca80f-02fe-457a-bbad-46d884d34387@protonmail.com> <2FE1A5CE-C531-4B6B-8F93-F0435B90FD58@posteo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14816"; mail-complaints-to="usenet@ciao.gmane.io" To: =?utf-8?Q?Daniel_Mei=C3=9Fner?= , guile-user@gnu.org, Mortimer Cladwell Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Fri Feb 02 01:14:02 2024 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rVhBw-0003du-Qu for guile-user@m.gmane-mx.org; Fri, 02 Feb 2024 01:14:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rVhBV-0003Hv-Rp; Thu, 01 Feb 2024 19:13:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rVhBS-0003HZ-Vl for guile-user@gnu.org; Thu, 01 Feb 2024 19:13:31 -0500 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rVhBO-0007J2-Vu for guile-user@gnu.org; Thu, 01 Feb 2024 19:13:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1706832803; x=1707092003; bh=rU98iXIZOgnWrpcUYFsLvoGEvx7AqWJtwr5Wv8LyUiE=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=C+LX9ZtXJfyXpkSPFXK9pfaReHkajjaTTHozx62HsSTcihZIK3Rg6gMSXLI73R3fT 8n2JW9G+PWnzMq9qj8yGrFcNJx7cr79zZGXPwUuPSmM6RBPymWJpavrK9YcSD/K+Cx yM945AclQ1mEF5SQe/10dVkiSjs3uVfJzui3+nXOvpZJUzaPZsx3OOKxdFnnObYol0 VOQ/34zwWcxFV6DAMt9f14x7G+Fb4WDBKvUF+cjDFzznGenmUGKZfMgFoEZSeOxPIy RNpmeXO3sCcCgvMdh+zDf0u6M4BFcfX9KzhsT9Y0XfXfOUFIC5qxm9srPRTnOFoeYK bQrbNKBFbEfBQ== In-Reply-To: <2FE1A5CE-C531-4B6B-8F93-F0435B90FD58@posteo.de> Feedback-ID: 40635331:user:proton Received-SPF: pass client-ip=185.70.40.134; envelope-from=skyvine@protonmail.com; helo=mail-40134.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.user:19427 Archived-At: Hi Daniel, > I think this has something to do with compilation indeed. More specifical= ly, it is caused by cross module inlining [1]. You probably need to declare= your env module as not declarative by setting #:declarative? to #f inside = the define-module form of env. I think the compiler inlines varB somehow. N= ot super sure, I am no Guile expert but you could inspect the assembly for = main to see what the compiler did. > > 1: https://www.wingolog.org/archives/2021/05/13/cross-module-inlining-in-= guile > 2: https://www.gnu.org/software/guile/manual/html_node/Declarative-Module= s.html Interestingly, it's actually the testexport module that needs to be=20 `#:declarative? #f`, not the env module. Which makes some sense after I=20 think about it - it is the variables in the testexport module that need=20 to get the updates not the env module. The mental model I use when=20 thinking about guile imports (which may or may not correspond to the=20 implementation) is that importing a variable is just defining a variable=20 with that name, and it happens to refer to a memory location allocated=20 by a different module. Then, assuming that the cause of the problem is=20 inlining as you describe (which seems quite plausible), the memory=20 locations are optimized away and the symbols lose their "declarativeness". Part of me wants to say it would make sense for non-declarative modules=20 to propagate their non-declarativeness to dependent modules. But this=20 seems like it could cause a significant loss of optimization if there is=20 one random module that needs to be non-declarative for some reason and=20 happens to be near the root of a large tree. It might be easier to=20 manage if declarativeness was associated with memory locations, instead=20 of modules or (as the manual implies) symbolic definitions. But I know=20 nothing about how declarativeness is implemented/tracked, so that might=20 be a big ask.