From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Neil Jerram" Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Avoid `SCM_VALIDATE_LIST ()' Date: Sun, 7 Sep 2008 00:32:59 +0200 Message-ID: <49dd78620809061532i76ccf7a4rb0c2d838d51cb504@mail.gmail.com> References: <87hc90u9lb.fsf@gnu.org> <49dd78620809011409w8902d24q5734da921d6dfbff@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220740397 19051 80.91.229.12 (6 Sep 2008 22:33:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Sep 2008 22:33:17 +0000 (UTC) Cc: guile-devel@gnu.org To: hanwen@xs4all.nl Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Sep 07 00:34:12 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kc6M4-0005qU-36 for guile-devel@m.gmane.org; Sun, 07 Sep 2008 00:34:08 +0200 Original-Received: from localhost ([127.0.0.1]:53135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kc6L4-0004Kx-Cg for guile-devel@m.gmane.org; Sat, 06 Sep 2008 18:33:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kc6L1-0004Ki-6w for guile-devel@gnu.org; Sat, 06 Sep 2008 18:33:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kc6Ky-0004KW-S4 for guile-devel@gnu.org; Sat, 06 Sep 2008 18:33:01 -0400 Original-Received: from [199.232.76.173] (port=58693 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kc6Ky-0004KT-MX for guile-devel@gnu.org; Sat, 06 Sep 2008 18:33:00 -0400 Original-Received: from rv-out-0708.google.com ([209.85.198.245]:58150) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kc6Ky-0001mc-BL for guile-devel@gnu.org; Sat, 06 Sep 2008 18:33:00 -0400 Original-Received: by rv-out-0708.google.com with SMTP id k29so969649rvb.6 for ; Sat, 06 Sep 2008 15:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lsw5pdQVVW6nOmY87jU23eOq7dKh/G1sbX1FermMprA=; b=ao1AuNDFDfE9oX2zr91c/gDBa1Ho2LxPxbMTAJPJZnuu0MHJGrOC6dNXcaUzXM9s3X //cjaNeXnGxyBKtatr+9DbXdzVOP/sDx2sSM8PMHFBRDk413PJBrrhJe3woYc6tzIBVo qozDbFthji9L6pdtmjFhGwsuIEr/LScXZX5P4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=TCFa+tVIWa9P0BY2j0m19wmETL8kIEg50/lso70H6PtgJ/yWmxEdK2gqXa2M8fjjLq 20YDxBpKndGswjaUeRNyBg5Gqx8ghlLT4LY0QO6NLhW/wALwf986TfLDLey61e4nLXxY T7cukAkSF1Fjs0g5PVe0untv5gWIVBHUIf5vM= Original-Received: by 10.141.205.10 with SMTP id h10mr7742093rvq.54.1220740379339; Sat, 06 Sep 2008 15:32:59 -0700 (PDT) Original-Received: by 10.141.177.4 with HTTP; Sat, 6 Sep 2008 15:32:59 -0700 (PDT) In-Reply-To: Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7597 Archived-At: 2008/9/2 Han-Wen Nienhuys : > > If you are doing memq? for something you already know to > somewhere in front of the list [...] Why would you do that? In two senses: 1. I know memq gives you the tail of the list, but I usually use its result only as a true/false value Why would run use memq like that in a situation where you already know that it will give you true? 2. It feels unusual to me to have a long list, but in which certain kinds of values are known always to be near the front. That sounds like something that should really be represented as two (or more) separate lists. Have you observed this (the current usage of SCM_VALIDATE_LIST) as a performance problem in practice? Regards, Neil