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: GNU Guile branch, stable-2.0, updated. v2.0.2-101-gd851e32 Date: Sat, 24 Sep 2011 14:37:19 -0400 Message-ID: <87wrcxpz1c.fsf@yeeloong.netris.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1316889477 1283 80.91.229.12 (24 Sep 2011 18:37:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 24 Sep 2011 18:37:57 +0000 (UTC) Cc: guile-devel@gnu.org To: "Andy Wingo" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Sep 24 20:37:53 2011 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 1R7X6n-00053Y-0j for guile-devel@m.gmane.org; Sat, 24 Sep 2011 20:37:53 +0200 Original-Received: from localhost ([::1]:59551 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7X6m-0001E9-KC for guile-devel@m.gmane.org; Sat, 24 Sep 2011 14:37:52 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7X6k-0001Dx-UH for guile-devel@gnu.org; Sat, 24 Sep 2011 14:37:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7X6j-0005n9-Fj for guile-devel@gnu.org; Sat, 24 Sep 2011 14:37:50 -0400 Original-Received: from world.peace.net ([96.39.62.75]:55854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7X6j-0005me-DE for guile-devel@gnu.org; Sat, 24 Sep 2011 14:37:49 -0400 Original-Received: from 209-6-55-18.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.55.18] helo=yeeloong.netris.org) by world.peace.net with esmtpa (Exim 4.69) (envelope-from ) id 1R7X6T-0000wy-V2; Sat, 24 Sep 2011 14:37:34 -0400 Original-Received: from mhw by yeeloong.netris.org with local (Exim 4.72) (envelope-from ) id 1R7X6G-0003IX-AJ; Sat, 24 Sep 2011 14:37:20 -0400 In-Reply-To: (Andy Wingo's message of "Fri, 23 Sep 2011 16:02:50 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (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:12794 Archived-At: Hi Andy, > commit d851e32fdc3d14804108f0389faa75a57599ced4 > Author: Andy Wingo > Date: Fri Sep 23 18:02:05 2011 +0200 > > prevent propagation for memory-dependent operations like `car' > > * module/language/tree-il/primitives.scm (*primitive-constructors*): > Record car, cdr, vector-ref, and struct-ref as "constructors". > Comment to come later. If car, cdr, vector-ref and struct-ref are to be included in this set of operations, it seems to me that the set should be renamed to something other than "constructors". Note that peval should not perform (in advance) any operations that access _mutable_ memory, but accessing non-mutable memory should be fine. Instead of moving those operations into the *primitive-constructors* set, perhaps we should make a new set of primitives called something like *primitive-mutable-accessors* ? > (define *primitive-constructors* > ;; Primitives that return a fresh object. > - '(acons cons cons* list vector make-struct make-struct/no-tail)) > + '(acons cons cons* list vector make-struct make-struct/no-tail > + car cdr vector-ref struct-ref)) > > (define *effect-free-primitives* > `(values > @@ -118,13 +119,11 @@ > + * - / 1- 1+ quotient remainder modulo > not > pair? null? list? symbol? vector? > - car cdr > caar cadr cdar cddr > caaar caadr cadar caddr cdaar cdadr cddar cdddr > caaaar caaadr caadar caaddr cadaar cadadr caddar cadddr > cdaaar cdaadr cdadar cdaddr cddaar cddadr cdddar cddddr > - vector-ref > - struct? struct-vtable struct-ref > + struct? struct-vtable > bytevector-u8-ref bytevector-s8-ref > bytevector-u16-ref bytevector-u16-native-ref > bytevector-s16-ref bytevector-s16-native-ref If you're going to move car and cdr from one set to the other, shouldn't you do the same for caar, cadr, etc? Also, if I'm correct in guessing the reason for this change (accessing mutable memory), shouldn't the bytevector-*-ref operations go as well? Thanks, Mark