From unknown Thu Jun 19 12:37:47 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#16362 <16362@debbugs.gnu.org> To: bug#16362 <16362@debbugs.gnu.org> Subject: Status: compiler doesn't preserve distinctness of literals Reply-To: bug#16362 <16362@debbugs.gnu.org> Date: Thu, 19 Jun 2025 19:37:47 +0000 retitle 16362 compiler doesn't preserve distinctness of literals reassign 16362 guile submitter 16362 Zefram severity 16362 normal tag 16362 notabug wontfix thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 05 18:44:25 2014 Received: (at submit) by debbugs.gnu.org; 5 Jan 2014 23:44:25 +0000 Received: from localhost ([127.0.0.1]:37209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzxMm-0004zP-DL for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:44:25 -0500 Received: from eggs.gnu.org ([208.118.235.92]:46628) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzwtU-00048f-Jr for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:14:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzwtP-0003vh-0F for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:14:08 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:45502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzwtO-0003vc-Tj for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:14:02 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzwtK-0007DY-4T for bug-guile@gnu.org; Sun, 05 Jan 2014 18:14:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzwtD-0003uO-AA for bug-guile@gnu.org; Sun, 05 Jan 2014 18:13:58 -0500 Received: from river.fysh.org ([5.135.154.127]:53164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzwtD-0003uK-4r for bug-guile@gnu.org; Sun, 05 Jan 2014 18:13:51 -0500 Received: from zefram by river.fysh.org with local (Exim 4.80 #2 (Debian)) id 1Vzwt9-0000g5-Ev; Sun, 05 Jan 2014 23:13:47 +0000 Date: Sun, 5 Jan 2014 23:13:47 +0000 From: Zefram To: bug-guile@gnu.org Subject: compiler disrespects referential integrity Message-ID: <20140105231347.GG30283@fysh.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 05 Jan 2014 18:44:19 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) The guile-2.0.9 compiler doesn't preserve the distinctness of mutable objects that are referenced in code via the read-eval (#.) facility. (I'm not mutating the code itself, only quoted objects.) The interpreter, and for comparison guile-1.8, do preserve object identity, allowing read-eval to be used to incorporate direct object references into code. Test case: $ cat t9 (cond-expand (guile-2 (defmacro compile-time f `(eval-when (compile eval) ,@f))) (else (defmacro compile-time f `(begin ,@f)))) (compile-time (fluid-set! read-eval? #t)) (compile-time (define aaa (cons 1 2))) (set-car! '#.aaa 5) (write '#.aaa) (newline) (write '(1 . 2)) (newline) $ guile-1.8 t9 (5 . 2) (1 . 2) $ guile-2.0 --no-auto-compile t9 (5 . 2) (1 . 2) $ guile-2.0 t9 ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-auto-compile argument to disable. ;;; compiling /home/zefram/usr/guile/t9 ;;; compiled /home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t9.go (5 . 2) (5 . 2) $ guile-2.0 t9 (5 . 2) (5 . 2) In the test case, the explicitly-constructed pair aaa is conflated with the pair literal (1 . 2), and so the runtime modification of aaa (which is correctly mutable) affects the literal. This issue seems closely related to the problem described at , wherein the compiler is entirely unable to handle code incorporating references to some kinds of object. In that case the failure mode is a compile-time error, so the problem can be worked around. The failure mode with pairs, silent misbehaviour, is a more serious problem. Between them, these problems break most of the interesting uses for read-eval, albeit only when using the compiler. Debian incarnation of this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734157 -zefram From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 14:59:33 2014 Received: (at 16362) by debbugs.gnu.org; 15 Jan 2014 19:59:33 +0000 Received: from localhost ([127.0.0.1]:52374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3Wcf-0004np-0L for submit@debbugs.gnu.org; Wed, 15 Jan 2014 14:59:33 -0500 Received: from world.peace.net ([96.39.62.75]:50079) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3Wcb-0004nZ-Ba; Wed, 15 Jan 2014 14:59:30 -0500 Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1W3WcU-0004G3-Nq; Wed, 15 Jan 2014 14:59:22 -0500 From: Mark H Weaver To: Zefram Subject: Re: bug#16362: compiler disrespects referential integrity References: <20140105231347.GG30283@fysh.org> Date: Wed, 15 Jan 2014 14:57:05 -0500 In-Reply-To: <20140105231347.GG30283@fysh.org> (zefram@fysh.org's message of "Sun, 5 Jan 2014 23:13:47 +0000") Message-ID: <87txd5t3vy.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16362 Cc: 16362@debbugs.gnu.org, request@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) tags 16362 notabug thanks Zefram writes: > The guile-2.0.9 compiler doesn't preserve the distinctness of mutable > objects that are referenced in code via the read-eval (#.) facility. > (I'm not mutating the code itself, only quoted objects.) I'm sorry that you've written code that assumes that this is allowed, but in Scheme all literals are immutable. > The interpreter, and for comparison guile-1.8, do preserve object > identity, allowing read-eval to be used to incorporate direct object > references into code. It worked by accident in Guile 1.8, but there's simply no way to support this robustly in an ahead-of-time compiler, which must serialize all literals to an object file. Thanks, Mark From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 16:02:59 2014 Received: (at 16362) by debbugs.gnu.org; 15 Jan 2014 21:03:00 +0000 Received: from localhost ([127.0.0.1]:52456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3Xc3-0000Z7-Ai for submit@debbugs.gnu.org; Wed, 15 Jan 2014 16:02:59 -0500 Received: from river.fysh.org ([5.135.154.127]:45100) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3Xc0-0000Yx-G1 for 16362@debbugs.gnu.org; Wed, 15 Jan 2014 16:02:57 -0500 Received: from zefram by river.fysh.org with local (Exim 4.80 #2 (Debian)) id 1W3Xbv-00047F-So; Wed, 15 Jan 2014 21:02:52 +0000 Date: Wed, 15 Jan 2014 21:02:51 +0000 From: Zefram To: Mark H Weaver Subject: Re: bug#16362: compiler disrespects referential integrity Message-ID: <20140115210251.GY21945@fysh.org> References: <20140105231347.GG30283@fysh.org> <87txd5t3vy.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87txd5t3vy.fsf@netris.org> X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 16362 Cc: 16362@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Mark H Weaver wrote: >I'm sorry that you've written code that assumes that this is allowed, >but in Scheme all literals are immutable. It's not a literal: the object was not constructed by the action of the reader. It was constructed by non-literal means, and merely *passed through* the reader. That's not to say your not-a-bug opinion is wrong, though. Scheme as defined by RnRS certainly doesn't support this kind of thing. It treats the print form of an expression as primary, and so doesn't like having anything unprintable in the object form. >It worked by accident in Guile 1.8, This is the bit that's really news to me. *Scheme* doesn't support it, but *Guile* is more than just Scheme, and I presumed that it was intentional that it took a more enlightened view of what constitutes an expression. If that was just an accident, then what you actually support ought to be documented. In principle it would also be a good idea to enforce this restriction in the interpreter, to avoid having this incompatibility between interpreter and compiler of the `same' implementation. > but there's simply no way to support >this robustly in an ahead-of-time compiler, which must serialize all >literals to an object file. Sure there is. The object in question is eminently serialisable: it contains only references to other serialisable data. All that needs to change is to distinguish between actual literal pairs (that can be merged) and non-literals whose distinct identity needs to be preserved. This might well be painful to add to your existing code, given the way you represent pairs. But that's a difficulty with the specific implementation, not an inherent limitation of compilation. -zefram From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 16:16:41 2014 Received: (at control) by debbugs.gnu.org; 15 Jan 2014 21:16:41 +0000 Received: from localhost ([127.0.0.1]:52494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3XpI-00028Y-IJ for submit@debbugs.gnu.org; Wed, 15 Jan 2014 16:16:40 -0500 Received: from world.peace.net ([96.39.62.75]:50140) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3XpE-00028C-M2 for control@debbugs.gnu.org; Wed, 15 Jan 2014 16:16:36 -0500 Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1W3Xp9-0005Pd-0i; Wed, 15 Jan 2014 16:16:31 -0500 From: Mark H Weaver To: control@debbugs.gnu.org Date: Wed, 15 Jan 2014 16:14:11 -0500 Message-ID: <87vbxlrlr0.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: retitle 16451 autogen.sh fails on FreeBSD 9.1 retitle 16359 "guild list" lists nothing (Guile 2.0.9 on Debian) retitle 16360 "guile help COMMAND" crashes (Guile 2.0.9 on Debian) retitle 16361 [wishlist] improve freshness checking in compile cache severity 16361 wishlist retitle 16362 compiler doesn't preserve distinctness of literals thanks [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: retitle 16451 autogen.sh fails on FreeBSD 9.1 retitle 16359 "guild list" lists nothing (Guile 2.0.9 on Debian) retitle 16360 "guile help COMMAND" crashes (Guile 2.0.9 on Debian) retitle 16361 [wishlist] improve freshness checking in compile cache severity 16361 wishlist retitle 16362 compiler doesn't preserve distinctness of literals thanks [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject retitle 16451 autogen.sh fails on FreeBSD 9.1 retitle 16359 "guild list" lists nothing (Guile 2.0.9 on Debian) retitle 16360 "guile help COMMAND" crashes (Guile 2.0.9 on Debian) retitle 16361 [wishlist] improve freshness checking in compile cache severity 16361 wishlist retitle 16362 compiler doesn't preserve distinctness of literals thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 17:17:45 2014 Received: (at 16362) by debbugs.gnu.org; 15 Jan 2014 22:17:45 +0000 Received: from localhost ([127.0.0.1]:52560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3YmO-00053F-LP for submit@debbugs.gnu.org; Wed, 15 Jan 2014 17:17:45 -0500 Received: from world.peace.net ([96.39.62.75]:50209) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3YmL-000535-D3 for 16362@debbugs.gnu.org; Wed, 15 Jan 2014 17:17:42 -0500 Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1W3YmC-0005eG-Fd; Wed, 15 Jan 2014 17:17:33 -0500 From: Mark H Weaver To: Zefram Subject: Re: bug#16362: compiler disrespects referential integrity References: <20140105231347.GG30283@fysh.org> <87txd5t3vy.fsf@netris.org> <20140115210251.GY21945@fysh.org> Date: Wed, 15 Jan 2014 17:15:14 -0500 In-Reply-To: <20140115210251.GY21945@fysh.org> (zefram@fysh.org's message of "Wed, 15 Jan 2014 21:02:51 +0000") Message-ID: <87eh48sxhp.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16362 Cc: 16362@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Zefram writes: > Mark H Weaver wrote: >>I'm sorry that you've written code that assumes that this is allowed, >>but in Scheme all literals are immutable. > > It's not a literal: the object was not constructed by the action of > the reader. It was constructed by non-literal means, and merely *passed > through* the reader. In Scheme terminology, an expression of the form (quote ) is a literal. Where that came from is not relevant to the definition of "literal". > That's not to say your not-a-bug opinion is wrong, though. Scheme as > defined by RnRS certainly doesn't support this kind of thing. It treats > the print form of an expression as primary, and so doesn't like having > anything unprintable in the object form. > >>It worked by accident in Guile 1.8, > > This is the bit that's really news to me. *Scheme* doesn't support > it, but *Guile* is more than just Scheme, and I presumed that it was > intentional that it took a more enlightened view of what constitutes > an expression. If that was just an accident, then what you actually > support ought to be documented. Where does it say in the documentation that this is allowed? To my mind, Guile documents itself as Scheme plus extensions, but you cannot determine what extensions you can depend on by experiment. If a given extension is not documented, then you cannot depend on it. > In principle it would also be a good idea to enforce this restriction > in the interpreter, to avoid having this incompatibility between > interpreter and compiler of the `same' implementation. Perhaps, but there are always going to be discernable differences between multiple implementations of the same language. >> but there's simply no way to support >>this robustly in an ahead-of-time compiler, which must serialize all >>literals to an object file. > > Sure there is. The object in question is eminently serialisable: it > contains only references to other serialisable data. Yes, but the identity of the objects cannot in general be preserved by serialization where multiple object files and multiple Guile sessions are involved. Consider this: you serialize an object to one file, and then the same object to a second file. Now you load them both in from a different Guile session. How can the Guile loader know whether these two objects should have the same identity or be distinct? > All that needs to change is to distinguish between actual literal > pairs (that can be merged) and non-literals whose distinct identity > needs to be preserved. That information is not preserved by the reader. > This might well be painful to add to your existing code, given the > way you represent pairs. But that's a difficulty with the specific > implementation, not an inherent limitation of compilation. There are inherent limitations to serialization. In the general case, the identity of mutable objects cannot be reliably preserved. For example, how do you correctly serialize a procedure produced by make-counter? (define (make-counter) (let ((n 0)) (lambda () (set! n (+ n 1)) n))) Mark From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 20:57:51 2014 Received: (at 16362) by debbugs.gnu.org; 16 Jan 2014 01:57:51 +0000 Received: from localhost ([127.0.0.1]:52685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3cDO-0003Wf-KN for submit@debbugs.gnu.org; Wed, 15 Jan 2014 20:57:51 -0500 Received: from river.fysh.org ([5.135.154.127]:47037) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W3cDM-0003WX-R6 for 16362@debbugs.gnu.org; Wed, 15 Jan 2014 20:57:49 -0500 Received: from zefram by river.fysh.org with local (Exim 4.80 #2 (Debian)) id 1W3cDI-0006Wf-Gw; Thu, 16 Jan 2014 01:57:44 +0000 Date: Thu, 16 Jan 2014 01:57:44 +0000 From: Zefram To: Mark H Weaver Subject: Re: bug#16362: compiler disrespects referential integrity Message-ID: <20140116015744.GA21945@fysh.org> References: <20140105231347.GG30283@fysh.org> <87txd5t3vy.fsf@netris.org> <20140115210251.GY21945@fysh.org> <87eh48sxhp.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eh48sxhp.fsf@netris.org> X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 16362 Cc: 16362@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Mark H Weaver wrote: >In Scheme terminology, an expression of the form (quote ) is a >literal. Ah, sorry, I see your usage now. R6RS speaks of that kind of expression being a "literal expression". (Elsewhere it uses "literal" in the sense I was using it, referring to the readable representation of an object.) Section 5.10 "Storage model" says "It is desirable for constants (i.e. the values of literal expressions) to reside in read-only memory.". So in the Scheme model whatever that in the expression is it's a "constant". Of course, that's in the RnRS view of expressions that ignores the homoiconic representation. It's assuming that these "constants" will always be "literal" in the sense I was using. >Where does it say in the documentation that this is allowed? It doesn't: as far as I can see it doesn't document that aspect of the language at all. It would be nice if it did. >To my mind, Guile documents itself as Scheme plus extensions, I thought the documentation was attempting to document the language that Guile implements per se. It doesn't generally just refer to RnRS for the language definition; it actually tells you most of what it could have referred to RnRS for. For example, it fully describes tail recursion, without any reference to RnRS. It's good that it does this, and it would be good for it to be more complete in the areas such as this where it's lacking. So maybe I got the wrong impression of the documentation's role. As the documentation doesn't describe expressions in the RnRS character-based way, I got the impression that Guile had not necessarily adopted that restriction. As it doesn't describe expressions in the homoiconic way either, I interpreted it as silent on the issue, making experimentation appropriate to determine the intent. Maybe the documentation should have a note about its relationship to the Scheme language definition: say which things it tries to be authoritative about. >cannot determine what extensions you can depend on by experiment. Fair point, and I'm not bitter about my experiment turning out to have this limited applicability. >Consider this: you serialize an object to one file, and then the same >object to a second file. Now you load them both in from a different >Guile session. How can the Guile loader know whether these two objects >should have the same identity or be distinct? That's an interesting case, and I suppose I wouldn't expect that to preserve identity. I also wouldn't expect you to serialise an I/O port. But the case I'm concerned about is a standalone script, being compiled as a whole, and the objects it's setting up at compile time are made of ordinary data. I think some of our difference of opinion here comes because you're mainly thinking of the compiler as something to apply to modules, so you expect to deal with many compiled files in one session, whereas I'm thinking about compilation of a program as a whole. Your viewpoint is the more general. >For example, how do you correctly serialize a procedure produced by >make-counter? Assuming we're only serialising it to one file, it shouldn't be any more difficult than my test case with a mutable pair. The procedure object needs to contain a reference to the body expression and a reference to the lexical environment that it closed over. The lexical environment contains the binding of the symbol "n" to a variable, which contains some current numeric value. That variable is the basic mutable item whose identity needs to be maintained through serialisation. If we have multiple procedures generated by make-counter, they'll have distinct variables, and therefore distinct lexical environments, and therefore be distinct procedures, though they'll share bodies. The only part of this that looks at all difficult to me is that you may have compiled the function body down to VM code, which is not exactly a normal Lisp object and needs its own serialisation arrangements. Presumably you already have that solved in order to compile code that contains function definitions. Aside from that it's all ordinary Lisp objects that look totally serialisable. What do you think is the difficult part? -zefram From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 01 15:04:23 2014 Received: (at 16362) by debbugs.gnu.org; 1 Oct 2014 19:04:23 +0000 Received: from localhost ([127.0.0.1]:57700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XZPCI-0000as-OS for submit@debbugs.gnu.org; Wed, 01 Oct 2014 15:04:22 -0400 Received: from world.peace.net ([96.39.62.75]:44196) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XZPCE-0000ad-UX; Wed, 01 Oct 2014 15:04:19 -0400 Received: from c-24-62-95-23.hsd1.ma.comcast.net ([24.62.95.23] helo=yeeloong.lan) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XZPC9-0001GJ-4C; Wed, 01 Oct 2014 15:04:13 -0400 From: Mark H Weaver To: Zefram Subject: Re: bug#16362: compiler disrespects referential integrity References: <20140105231347.GG30283@fysh.org> <87txd5t3vy.fsf@netris.org> <20140115210251.GY21945@fysh.org> <87eh48sxhp.fsf@netris.org> <20140116015744.GA21945@fysh.org> Date: Wed, 01 Oct 2014 15:04:00 -0400 In-Reply-To: <20140116015744.GA21945@fysh.org> (zefram@fysh.org's message of "Thu, 16 Jan 2014 01:57:44 +0000") Message-ID: <878ukz8vdr.fsf@yeeloong.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16362 Cc: 16362@debbugs.gnu.org, request@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) tags 16362 + notabug wontfix close 16362 thanks I'm sorry that you came to depend on the undocumented behavior of earlier versions of Guile, but the Scheme standards are quite clear that literals are immutable and that no guarantees are made about preserving object identity as seen by eq? or eqv?. To my knowledge we never made any promises that this would work, and we can't make it work properly in the general case in our new ahead-of-time compilation model. I'm closing this ticket. Mark From unknown Thu Jun 19 12:37:47 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 30 Oct 2014 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator