From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.user Subject: Re: MEMOIZE_LOCALS (fwd) Date: Thu, 27 Jun 2002 17:06:33 -0700 Sender: guile-user-admin@gnu.org Message-ID: References: Reply-To: ttn@glug.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1025223563 24589 127.0.0.1 (28 Jun 2002 00:19:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 28 Jun 2002 00:19:23 +0000 (UTC) Cc: guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17NjTv-0006OU-00 for ; Fri, 28 Jun 2002 02:19:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17NjNk-0008Hu-00; Thu, 27 Jun 2002 20:13:00 -0400 Original-Received: from ca-crlsbd-cuda3-c6a-b-211.crlsca.adelphia.net ([68.71.15.211] helo=giblet) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17NjLR-00088R-00 for ; Thu, 27 Jun 2002 20:10:37 -0400 Original-Received: from ttn by giblet with local (Exim 3.35 #1 (Debian)) id 17NjHV-0000nH-00; Thu, 27 Jun 2002 17:06:33 -0700 Original-To: dirk@sallust.ida.ing.tu-bs.de Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:659 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:659 From: Dirk Herrmann Date: Fri, 28 Jun 2002 01:39:08 +0200 (CEST) Thus, the intention of the change is to simplify the code by removing a lot of dead #ifdef code parts, making the relevant parts of the code better readable. yes, this is clear (from looking at eval.c). in this case, no performance degredation would be the expected outcome. Regarding my 'methods', I don't think there is much need to justify them. (you have to justify them to yourself at least. :-) Typically I think of ways to improve guile, suggest changes and discuss with people whether these changes will make sense or not. If there is a consensus and I find the time (time is the most critical part!), I will apply the changes. So far, there have been only few complaints :-) unfortunately, volume of complaints doesn't always correlate w/ quality. i'm glad to see you involving guile-user, in any case. thi _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user