From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Jakub Wojciech" Newsgroups: gmane.lisp.guile.bugs Subject: bug#49707: Documentation and behavior differ for match (not ...) pattern Date: Fri, 23 Jul 2021 11:45:34 +0200 Message-ID: <87fsw5e535.fsf@riseup.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8248"; mail-complaints-to="usenet@ciao.gmane.io" To: 49707@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Fri Jul 23 11:47:31 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 1m6rmE-0001vm-Kx for guile-bugs@m.gmane-mx.org; Fri, 23 Jul 2021 11:47:30 +0200 Original-Received: from localhost ([::1]:49740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m6rmD-000390-IR for guile-bugs@m.gmane-mx.org; Fri, 23 Jul 2021 05:47:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51990) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6rlm-0002ed-PX for bug-guile@gnu.org; Fri, 23 Jul 2021 05:47:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59021) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m6rlm-00080X-HI for bug-guile@gnu.org; Fri, 23 Jul 2021 05:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m6rlm-0007VN-E1 for bug-guile@gnu.org; Fri, 23 Jul 2021 05:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Jakub Wojciech" Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Fri, 23 Jul 2021 09:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 49707 X-GNU-PR-Package: guile X-Debbugs-Original-To: bug-guile@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.162703360328818 (code B ref -1); Fri, 23 Jul 2021 09:47:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 23 Jul 2021 09:46:43 +0000 Original-Received: from localhost ([127.0.0.1]:42334 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m6rlT-0007Uk-4X for submit@debbugs.gnu.org; Fri, 23 Jul 2021 05:46:43 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:35712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m6rlN-0007UY-Qr for submit@debbugs.gnu.org; Fri, 23 Jul 2021 05:46:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51910) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6rlN-00024P-DM for bug-guile@gnu.org; Fri, 23 Jul 2021 05:46:37 -0400 Original-Received: from mx1.riseup.net ([198.252.153.129]:57528) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6rlL-0007b4-3X for bug-guile@gnu.org; Fri, 23 Jul 2021 05:46:37 -0400 Original-Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4GWPbW57g4zDyTg for ; Fri, 23 Jul 2021 02:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1627033591; bh=siNbkzL78oUh0XyQUJ+jLnL3KHCyFe32N+BdtdrlNZM=; h=From:To:Subject:Date:From; b=RTIV+ntqJvbDzq9EPKbaIvdQqQIoAglD46fDwLJPFyz/fLYLLBb0DoecQgHbgqDTE VDo6G0VLDnLoRr0kQShpbD2B6elIexE+0tylfUuvNTHsFbfYPL5gq/o24PipNtmUc3 WIAvEn49yd+KltttYfxLsN2K0ZQkjLVf74Y33kKE= X-Riseup-User-ID: 04D4D64113D15ABB28AC339E10B929A56D0742AF3F585FF0C49F3CF9B34F6BF0 Original-Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4GWPbV6tlfz1ySf for ; Fri, 23 Jul 2021 02:46:30 -0700 (PDT) Received-SPF: pass client-ip=198.252.153.129; envelope-from=jakub-w@riseup.net; helo=mx1.riseup.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:10156 Archived-At: --=-=-= Content-Type: text/plain The documentation states: > (not pat_1 ... pat_n) if all pat_1 thru pat_n don't match The code only implements (not pat), for a singular pattern, e.g: (match 2 ((not 1) 'not-one) (1 'one) (2 'two)) => not-one According to the documentation this should work, but the result is erroneous: (match 3 ((not 1 2) 'not-one-nor-two) (1 'one) (2 'two) (3 'three)) => three So it fails silently. RhodiumToad on #guile proposed the simple fix that I took a liberty of attaching to this message. It adds a clause for (not ...), delegating it to 'or': (not (or ...)). However RhodiumToad also raised another issue: is the code wrong or is the documentation wrong? The documentation in the file itself states: > The 'not' operator succeeds if the given pattern doesn't match. The test from upstream also only checks for the singular pattern inside the 'not' clause. This means that the idea behind this code is to allow one and only one pattern. Although I lean towards fixing the code to match the Guile's documentation (i.e. applying the attached patch), I also wonder about the relation with the upstream - Chibi Scheme. There are three possibilities: 1. Diverge from their implementation. 2. Try to convince them to apply that patch too. 3. Make passing more than one pattern to 'not' clause a syntax error and changing the info manual documentation. The question is: which one do we want to choose? The rationale for not selecting option 3 is the fact that the change is non-breaking, adds a functionality, and conforms to both SRFI-200 and SRFI-204 drafts and the original Wright-Duba paper. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=match-patch.diff diff --git a/module/ice-9/match.upstream.scm b/module/ice-9/match.upstream.scm index b1fc371b8..f12981cb3 100644 --- a/module/ice-9/match.upstream.scm +++ b/module/ice-9/match.upstream.scm @@ -115,7 +115,7 @@ ;;> @example{(match 1 ((or x) x))} ;;> @example{(match 1 ((or x 2) x))} -;;> The @scheme{not} operator succeeds if the given pattern doesn't +;;> The @scheme{not} operator succeeds if none of the given patterns ;;> match. None of the identifiers used are available in the body. ;;> @example{(match 1 ((not 2) #t))} @@ -355,6 +355,8 @@ (match-extract-vars (or p ...) (match-gen-or v (p ...) g+s sk fk i) i ())) ((match-two v (not p) g+s (sk ...) fk i) (match-one v p g+s (match-drop-ids fk) (sk ... i) i)) + ((match-two v (not p ...) g+s (sk ...) fk i) + (match-two v (not (or p ...)) g+s (sk ...) fk i)) ((match-two v (get! getter) (g s) (sk ...) fk i) (let ((getter (lambda () g))) (sk ... i))) ((match-two v (set! setter) (g (s ...)) (sk ...) fk i) --=-=-=--