From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] add SRFI: srfi-121; generators Date: Sun, 02 Aug 2020 18:39:32 -0400 Message-ID: <87v9i0zn7k.fsf@netris.org> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10915"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel@gnu.org To: John Cowan Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Aug 03 00:40:50 2020 Return-path: Envelope-to: guile-devel@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 1k2Mew-0002kH-An for guile-devel@m.gmane-mx.org; Mon, 03 Aug 2020 00:40:50 +0200 Original-Received: from localhost ([::1]:58552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k2Meu-00080Z-Qu for guile-devel@m.gmane-mx.org; Sun, 02 Aug 2020 18:40:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35904) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k2Mek-00080P-UT for guile-devel@gnu.org; Sun, 02 Aug 2020 18:40:38 -0400 Original-Received: from world.peace.net ([64.112.178.59]:53176) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k2Mei-0007Or-Pz for guile-devel@gnu.org; Sun, 02 Aug 2020 18:40:38 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k2MeV-000206-F8; Sun, 02 Aug 2020 18:40:23 -0400 In-Reply-To: Received-SPF: pass client-ip=64.112.178.59; envelope-from=mhw@netris.org; helo=world.peace.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/02 18:40:24 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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.io gmane.lisp.guile.devel:20567 Archived-At: Hi John, John Cowan wrote: > Mark Weaver wrote in July 2019: > >> Also, the provided implementations of 'generator-find', 'generator-any' >> and 'generator-every' are incorrect: > > > I appreciate your finding these bugs. I wish, however, that you had also > sent them to . Sorry about that. As I recall, I didn't send those bug reports to the SRFI-121 mailing list because I had assumed that the bugs were not in the reference implementation. I made that assumption because the buggy procedures included comments that expressed uncertainty about what the specification intended, e.g. "the spec would have me return #f, but I think it must simply be wrong" and "a literal interpretation might say it only terminates on #eof if (pred #eof) but I think this makes more sense." It didn't occur to me that the reference implementation of a finalized SRFI would include comments like "the spec would have me return #f, but I think it must simply be wrong". However, I see now that I was mistaken. Indeed, those buggy implementations and confused comments are in both the SRFI-121 and SRFI-158 reference implementations. I *did* send bug reports to the SRFI-121 and SRFI-158 mailing lists about inconsistencies in those specifications. See: https://srfi-email.schemers.org/srfi-158/msg/11780787/ https://srfi-email.schemers.org/srfi-158/msg/11781931/ https://srfi-email.schemers.org/srfi-121/threads/2019/07/ I'm sorry to say it, but in my opinion SRFI-121 and SRFI-158 should be deprecated and avoided. The reference implementations do not match the specifications, and the specifications themselves are self-contradictory (see above). Therefore, it's entirely possible that users of these SRFIs may have contradictory expectations about how these procedures behave. Some may have read the spec one way, some may have read the spec in a contradictory way, some may have learned from how the buggy reference implementation behaves, and others may have learned from the behavior of a different SRFI-121 implementation that doesn't have those bugs. At this point, I don't see how the problems can be fixed without breaking some users' assumptions, and therefore breaking existing code. I sincerely hope that these two SRFIs are an aberration, and not representative of the quality of the R7RS-large effort. Mark