From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.lisp.guile.bugs Subject: bug#17296: Uh, wrong? Date: Wed, 04 Jun 2014 06:39:50 +0200 Message-ID: <87bnu98ezt.fsf@fencepost.gnu.org> References: <878ur25thj.fsf@yeeloong.lan> <87wqcx99zk.fsf@fencepost.gnu.org> <87a99tv0wh.fsf@yeeloong.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1401856882 30295 80.91.229.3 (4 Jun 2014 04:41:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Jun 2014 04:41:22 +0000 (UTC) Cc: 17296@debbugs.gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Jun 04 06:41:15 2014 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ws30h-00071E-2C for guile-bugs@m.gmane.org; Wed, 04 Jun 2014 06:41:11 +0200 Original-Received: from localhost ([::1]:57183 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws30g-0008AB-EZ for guile-bugs@m.gmane.org; Wed, 04 Jun 2014 00:41:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws30c-00086i-9I for bug-guile@gnu.org; Wed, 04 Jun 2014 00:41:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ws30Z-0000Wa-VX for bug-guile@gnu.org; Wed, 04 Jun 2014 00:41:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws30Z-0000WL-S0 for bug-guile@gnu.org; Wed, 04 Jun 2014 00:41:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Ws30Y-0001Il-Op for bug-guile@gnu.org; Wed, 04 Jun 2014 00:41:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Kastrup Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 04 Jun 2014 04:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17296 X-GNU-PR-Package: guile X-GNU-PR-Keywords: patch Original-Received: via spool by 17296-submit@debbugs.gnu.org id=B17296.14018568114880 (code B ref 17296); Wed, 04 Jun 2014 04:41:02 +0000 Original-Received: (at 17296) by debbugs.gnu.org; 4 Jun 2014 04:40:11 +0000 Original-Received: from localhost ([127.0.0.1]:42921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ws2zi-0001Gb-K8 for submit@debbugs.gnu.org; Wed, 04 Jun 2014 00:40:11 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:35450 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ws2zb-0001GG-ML for 17296@debbugs.gnu.org; Wed, 04 Jun 2014 00:40:05 -0400 Original-Received: from localhost ([127.0.0.1]:42755 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws2zb-00078J-1d; Wed, 04 Jun 2014 00:40:03 -0400 Original-Received: by lola (Postfix, from userid 1000) id 83202DF6C2; Wed, 4 Jun 2014 06:39:50 +0200 (CEST) In-Reply-To: <87a99tv0wh.fsf@yeeloong.lan> (Mark H. Weaver's message of "Tue, 03 Jun 2014 22:55:42 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7491 Archived-At: Mark H Weaver writes: > David Kastrup writes: >> So the behavior for length+ on a dotted list is strictly unspecified. >> It is not even stated "it is an error". > > Actually, it is. At the end of the section that defines the "types" > such a "clist" and "flist", it states: > > It is an error to pass a circular or dotted list to a procedure not > defined to accept such an argument. > > While it is true that we are not required to signal an error, I'm wary > extending 'length+' in this way. It also effectively extends 'map' and > 'for-each' to support things like (map + '() 'foo), and thus potentially > affects many other procedures both inside and outside of Guile that use > 'map' and 'for-each'. Once we've done this, users are likely to grow > dependent on it and we can never go back. That is true for _any_ particular choice for unspecified behavior. _Including_ throwing an error as a means of checking input validity. You are proposing providing functions _not_ defined in srfi-1 at all for functionality that is clearly desirable even for implementing behavior required by some functions in srfi-1. Such functions can either be made private, requiring the user to write his own, less efficient function whenever he faces the same problem. Or they can be provided publicly in which case it is unlikely that the user will not grow dependent on them and "we can never go back". The reference implementation chose the behavior I propose. The naming choice of "length+" in srfi-1 has been made in a manner suggesting that only one such additional length operator is needed as it is rather generic and not just restricted to circular and dotted lists. Basically, srfi-1 is sort of a have-one's-cake-and-eat-it-too specification: the ability to throw errors on dotted lists is explicitly mentioned as possibly helpful when a user mixes up arguments to functions like fold, while at the same time there is no framework for the explicit "accept dotted list also" kind of behavior put forward by functions like drop-right or take-right. It is also noteworthy that the reference implementation defines "length" on dotted lists rather than erroring out, and in general is pretty lenient regarding using dotted instead of proper lists. This _is_ an ugly mess. It is my personal opinion that at least with regard to length+ we are better off following the reference implementation. I don't see the point in having something like (map + '(1 2) '(1 2 3 . 4)) error out: it did not do so before your patch and definitely has an obvious result. I am not enthused over allowing (map + '(1 2) 5) => '() while balking at (map + 5) but with a single list, the "shortest finite list" clause does not really come into play, and indeed the "help avoid user error early" rationale seems particularly applicable. My first implementation of take-right/drop-right just used "count" as it does not seem to make sense to talk about dropping n elements from the end of a dotted list given that even functions like "count" and "length" are unspecified for dotted lists. I was, however, surprised to figure out later that this is one area of srfi-1 where lists were explicitly allowed to be dotted but not circular. >> At any rate, what I am getting at is that I was going to submit the >> following patch as a part of a series fixing other bugs, bugs that I >> need a working "get the length of a dotted list" operator for. We >> don't have any such operator in GUILE, and that's awkward. > > It might be helpful to add such a procedure, but I don't think > 'length+' should be it. I don't think the entire incoherent mess of what is and what is not described that makes up srfi-1 should be like it is. But that's what we have to deal with. Following the reference implementation in this regard seems like the smallest evil to me. If the standard had kept its fingers off specifying behavior for _all_ list-like operations (including the take-right and drop-right operators) we would not be in this situation. Whatever escape we choose, people will get to rely on it. -- David Kastrup