From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile 2.9.9 Released [beta] Date: Tue, 14 Jan 2020 21:54:02 +0100 Message-ID: <87blr5hi8l.fsf@pobox.com> References: <87zherlphs.fsf@pobox.com> <87eew2i8z3.fsf@pobox.com> <87pnfmglbo.fsf@pobox.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="8269"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Andy Wingo , guile-devel To: Mikael Djurfeldt Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jan 14 21:54:34 2020 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1irTCs-0001gC-4e for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 21:54:34 +0100 Original-Received: from localhost ([::1]:45830 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irTCq-000540-PR for guile-devel@m.gmane-mx.org; Tue, 14 Jan 2020 15:54:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36650) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irTCe-00053t-Q1 for guile-devel@gnu.org; Tue, 14 Jan 2020 15:54:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irTCd-0005iS-3G for guile-devel@gnu.org; Tue, 14 Jan 2020 15:54:20 -0500 Original-Received: from fanzine.igalia.com ([178.60.130.6]:38172) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irTCc-0005dt-Gx for guile-devel@gnu.org; Tue, 14 Jan 2020 15:54:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=3eWT2W3UdmBe4/YuYJD94jzop1UJ+G0V+L8+NsGBH5o=; b=pMhEwMOTDx4J9c0aaXJdU+Ge76T6uBAhJSse+AHxFN0N5y0HHR6FmGI/A9x3yfSGKK3uqCW/NDl0Je5pbMdhy57EXgNzf1XirW1WA/FqHq8LyAvuKvWV0eMlMNVQzMfo6+SZr6wDhWq8iHOD7VD3qcOunz7APXnIOf8Xh/4468QuTJTJdWebNzeEHd3LBkrUSxlNOOOmOy/hSV8QrLHEEtaV4Cy302ijCavL0cJryHfP8eIsSBlVwqyTkUjw5HVFI8UMORYvoHcbvRgs/EKSq29UMHiipJafkZHT1LqjrPKVGLAXBvcj2bpotBF8LGM+/2wbpoM0qTqn33FxwphfiQ==; Original-Received: from [88.123.12.110] (helo=sparrow) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1irTCX-0006nS-7A; Tue, 14 Jan 2020 21:54:13 +0100 In-Reply-To: (Mikael Djurfeldt's message of "Tue, 14 Jan 2020 17:03:32 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 178.60.130.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:20278 Archived-At: On Tue 14 Jan 2020 17:03, Mikael Djurfeldt writes: > Hmm... it seems like both Stefan and you have interpreted my post > exactly the opposite way compared to how it was meant. :) Hah! My apologies :) > What I wanted to say is that I probably prefer you to *reverse* the > recent patch because I prefer to have good optimization also when > procedures are referenced by value in more than one non-operator > position. I prefer this over having (eq? p p) => #t for the reasons I > stated. I understand this also! However what Stefan is saying echoes what I've heard from other people. There are some cases where eta-converting all lexical procedure references helps nobody -- it makes (eqv? p p) be false in places where many people expect it would be true, without enabling significant optimizations. In that case, the choice is pretty clear. But if there are significant optimizations left on the table, I would hesitate a lot before chasing an ideal of procedure identity in cases where the procedure's behavior cannot possibly differ. Anyway that's not where we are currently, thankfully! Cheers, Andy