From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile: What's wrong with this? Date: Wed, 04 Jan 2012 14:29:25 -0500 Message-ID: <87lipnfeqy.fsf@netris.org> References: <4F027F35.5020001@gmail.com> <1325603029.22166.YahooMailNeo@web37906.mail.mud.yahoo.com> <4F032C41.3070300@gmail.com> <877h17hjj2.fsf@netris.org> <1325687351.71432.YahooMailNeo@web37906.mail.mud.yahoo.com> <874nwbs9c4.fsf@pobox.com> <87ty4bfheq.fsf@netris.org> <87sjjvpav1.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1325705393 3137 80.91.229.12 (4 Jan 2012 19:29:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2012 19:29:53 +0000 (UTC) Cc: Bruce Korb , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jan 04 20:29:49 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RiWWy-0001Hc-Tm for guile-devel@m.gmane.org; Wed, 04 Jan 2012 20:29:49 +0100 Original-Received: from localhost ([::1]:38508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiWWy-0006Ap-GF for guile-devel@m.gmane.org; Wed, 04 Jan 2012 14:29:48 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:49226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiWWw-0006Ai-LQ for guile-devel@gnu.org; Wed, 04 Jan 2012 14:29:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiWWu-0003Mv-K6 for guile-devel@gnu.org; Wed, 04 Jan 2012 14:29:46 -0500 Original-Received: from world.peace.net ([96.39.62.75]:44115) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiWWu-0003Mq-EX for guile-devel@gnu.org; Wed, 04 Jan 2012 14:29:44 -0500 Original-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.69) (envelope-from ) id 1RiWWo-0001t5-Rg; Wed, 04 Jan 2012 14:29:39 -0500 In-Reply-To: <87sjjvpav1.fsf@pobox.com> (Andy Wingo's message of "Wed, 04 Jan 2012 13:43:14 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:13288 Archived-At: Andy Wingo writes: >> David Kastrup writes: >>> What for? It would mean that a literal would not be eq? to itself, a >>> nightmare for memoization purposes. >> >> I agree that it should not be the default behavior, but I don't see the >> harm in allowing users to compile their own code this way. > > Well, we can fix this too: we can make > > "foo" > > transform to > > (copy-once UNIQUE-GENSYM str) > > with > > (define (copy-once key str) > (or (hashq-ref mutable-string-literals key) > (let ((value (string-copy str))) > (hashq-set! mutable-string-literals key value) > value))) Although this is a closer emulation of the previous (broken) behavior, IMHO this would be less desirable than simply doing (string-copy "foo") on every evaluation of "foo", which seems to be what Bruce (and probably others) expected "foo" to do. For example, based on the mental model that Bruce apparently had when he wrote his code, he might have written something like this: (define (hello-world-with-one-char-changed i c) (define str "Hello world") (string-set! str i c) str) Your UNIQUE-GENSYM hack emulates the previous behavior that makes the above procedure buggy. Simply changing "hello" to (string-copy "hello") would make the procedure work, and I believe conforms better to what Bruce expects. Of course, I'm only talking about what I think should be done when the compiler option is changed to non-default behavior. I strongly believe that the _default_ behavior should stay as it is now. Mark