From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Leo Prikler Newsgroups: gmane.lisp.guile.bugs Subject: bug#48425: Should #nil be equal? to '()? Date: Thu, 24 Jun 2021 20:31:12 +0200 Message-ID: <75c724023a126850b3b21a296fb658330038e670.camel@student.tugraz.at> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12280"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.34.2 To: Taylan Kammer , 48425@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Thu Jun 24 20:32:28 2021 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lwU9M-00031K-Bg for guile-bugs@m.gmane-mx.org; Thu, 24 Jun 2021 20:32:28 +0200 Original-Received: from localhost ([::1]:58640 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lwU9L-0005fW-CF for guile-bugs@m.gmane-mx.org; Thu, 24 Jun 2021 14:32:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57842) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lwU8w-0005bZ-RU for bug-guile@gnu.org; Thu, 24 Jun 2021 14:32:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60806) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lwU8w-0000nQ-GR for bug-guile@gnu.org; Thu, 24 Jun 2021 14:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lwU8w-0008PT-EA for bug-guile@gnu.org; Thu, 24 Jun 2021 14:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 24 Jun 2021 18:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48425 X-GNU-PR-Package: guile X-GNU-PR-Keywords: patch Original-Received: via spool by 48425-submit@debbugs.gnu.org id=B48425.162455947930224 (code B ref 48425); Thu, 24 Jun 2021 18:32:02 +0000 Original-Received: (at 48425) by debbugs.gnu.org; 24 Jun 2021 18:31:19 +0000 Original-Received: from localhost ([127.0.0.1]:44119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lwU8F-0007qu-7S for submit@debbugs.gnu.org; Thu, 24 Jun 2021 14:31:19 -0400 Original-Received: from mailrelay.tugraz.at ([129.27.2.202]:21805) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lwU8C-0007nH-NQ for 48425@debbugs.gnu.org; Thu, 24 Jun 2021 14:31:18 -0400 Original-Received: from nijino.local (62-116-34-49.adsl.highway.telekom.at [62.116.34.49]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4G9pcK0QK0z3wmc; Thu, 24 Jun 2021 20:31:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1624559473; bh=q+aLm3K8Lbiar8lKZtEUVMVaErIBBFpDcWxUhA1v45E=; h=Subject:From:To:Date:In-Reply-To:References; b=esf1p/1+am8tt0SNXjaGjKbK7x/K2Q8CHHt3q3jb9iSuU+0+709iT+UuDl8QRgiT6 /nNv5W0nEsb+K395aJo5qVhDTOTAuDQTSqThRtP5v+CLptKdVBpRGlev6Ot4nAutLp gnVtunsXCJaO0ZcbaPfMCjLPHTb0nnpshs4aiiFU= In-Reply-To: X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.io gmane.lisp.guile.bugs:10128 Archived-At: Hi Taylan, after a lengthy discussion in IRC, you invited me to reply to this bug report, so that's what I'm doing. I will make short references to that discussion, but I won't rehash all of it. Anyone who is interested in reading it in all detail, should inspect the public logs: http://logs.guix.gnu.org/guile/2021-06-24.log#170309 Am Freitag, den 14.05.2021, 21:36 +0200 schrieb Taylan Kammer: > I believe it would be better if #nil were equal? to (). > > It would keep *not* being equal? to #f and as such not disturb the > property of transitiveness. I don't think there's a good reason to prefer one of this equal?ity over the other – it all comes down to personal preference if at all. > Making #nil and () be equal? would be a lot more intuitive since > they both represent the empty list, and since equal? is commonly > used to test the equality of lists. Meeting this expectation would > probably prevent a common type of unexpected behavior where a list > coming from Elisp code is not equal? to a list coming from Scheme > code, even though they have the same contents. I don't think, that this is a good reason to make them equal? We've had our lengthy discussion on the philosophy of equality, which I'm going to cut short here, as that's not the point you're making, but for the protocol's sake, #nil and '() are not philosophically equal? Regarding intuitiveness, I think this actually does more harm than good. I could argue that #nil be equal? to #f on the grounds of intuitiveness, but more importantly (if (equal? a b) (equal? (if a #t #f) (if b #t #f))) should only ever return #t or *unspecified*, never #f (insert '() and #nil as a and b). Finally on the point of making equal?ity work that way for the sake of interoperability with other Lisp dialects such as Emacs Lisp or Clojure, this assumes that this style of comparison through equal? is "good Scheme", when I'd argue, that it is in fact not. Pattern matching and dedicated comparison operators are much saner alternatives most of the time. There are multiple ways of getting around the issue of #nil, '() and #f not being equal? to each other. The first would be to define an equal- modulo-nil? procedure, which returns #t if both arguments are nil? Another, that would implement your style, would be the following: --8<---------------cut here---------------start------------->8--- ;; Don't forget to test this when actually using it (define my-equal? (match-lambda* ((() ()) #t) ;; match '() against #nil (((a . as) (b . bs)) (and (my-equal? a b) ;; recurse into the first sub-element (list= my-equal? as bs))) ;; recurse into the others ((a b) (equal? a b)))) ;; fall back to base equal? --8<---------------cut here---------------end--------------->8--- Of course, you can also take the equal? you wrote for this patch and include it in your own library, but be sure to document it so as to not confuse the readers of your code :) Note, that any such implementations will come with certain limitations, but I suppose that's what you'd want out of them. > Attached is a patch to realize the change. Note that it increases > the size of compiled code that uses equal?. I don't know if this > represents a problem or not. I personally don't think bytecode optimizations are something to consider if one can achieve correctness on the other hand, but this solution has the downside of being both wrong (philosophically, as discussed above and in IRC) and heavier to compute. That's not something a standard library should aim for :P Regards, Leo