From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#15117: 24.3.50; doc of `(forward|backward)-*': state return value Date: Mon, 10 Feb 2014 22:40:25 -0800 (PST) Message-ID: References: <1dc76f7a-5481-41df-b976-ec22229d7283@default> <874n4a42f0.fsf@building.gnus.org> <1281d0fd-77cb-45e2-b99d-f4ad24b0fc4e@default> <2fefcbaf-9417-4f57-93af-490ea73aea98@default> <87mwhy4ftl.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1392100879 13198 80.91.229.3 (11 Feb 2014 06:41:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Feb 2014 06:41:19 +0000 (UTC) Cc: 15117@debbugs.gnu.org, Lars Ingebrigtsen To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 11 07:41:26 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1WD726-000736-MP for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Feb 2014 07:41:26 +0100 Original-Received: from localhost ([::1]:59819 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WD726-0001Zo-5G for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Feb 2014 01:41:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WD71t-0001Ma-2E for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 01:41:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WD71j-0003Dn-HY for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 01:41:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34507) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WD71j-0003Dh-EH for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 01:41:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WD71i-0007EZ-HQ for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 01:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 06:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15117 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 15117-submit@debbugs.gnu.org id=B15117.139210084227774 (code B ref 15117); Tue, 11 Feb 2014 06:41:02 +0000 Original-Received: (at 15117) by debbugs.gnu.org; 11 Feb 2014 06:40:42 +0000 Original-Received: from localhost ([127.0.0.1]:42402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD71M-0007Dp-Bh for submit@debbugs.gnu.org; Tue, 11 Feb 2014 01:40:41 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:41612) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD71H-0007DV-2Y for 15117@debbugs.gnu.org; Tue, 11 Feb 2014 01:40:36 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s1B6eSXV021583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Feb 2014 06:40:28 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s1B6eQ3B013544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 06:40:28 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s1B6eQ1q002066; Tue, 11 Feb 2014 06:40:26 GMT In-Reply-To: <87mwhy4ftl.fsf@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:85360 Archived-At: > > Everything in the universe has side effects. Ohhmmmm. It's true. >=20 > You should look up "referential transparency". Perhaps you should give me the benefit of the doubt. I'm actually well aware of referential transparency. That might even have been the case before you uttered your first side-effect cry. ;-) > Please read > http://en.wikipedia.org/wiki/Side_effect_(computer_science) Please spare me the comp-sci lesson. FYI, I was at the Santa Fe graph-reduction workshop in 1986, discussing what would ultimately become Haskell with John Hughes, Phil Wadler, Paul Hudak, and Simon Peyton-Jones. That's only to assure you that I am somewhat at home in this forest. I've been a proponent of purely functional and logic programming for over 30 years. And yet I have also enjoyed programming in nasty old Lisp for the same period. ;-) Go figure. > "function with side effects" is a pretty well-defined term. A > function does not necessarily have to modify an Emacs buffer to > be termed as such. Cough, gag. Yes, indeed. I really did not mean to suggest otherwise. > > By your (newfound) logic, you will presumably remove mention of > > the return value from the doc for those functions. The same > > logic behind documenting their return value applies to these > > other motion functions. >=20 > The logic is simple:=20 So are you arguing that we should not document the return value of those functions either? Meme combat. > if the return value is documented, the caller should be able to > depend on it,=20 Yes, that's the idea. > and "undocumenting" it retroactively isn't an option. As long as > the return value is undocumented, but the function can still be > useful without it, it can stay that way indefinitely. When have you ever seen Emacs Dev worry a lot about changing something, let alone undocumenting a return value retroactively? Let's not exaggerate. Yes, the return value for these simple motion functions should be documented, and thus users should be able to depend on it. That is no more of a constraint on Emacs-Lisp implementors than is letting users depend on the value of `point' when the function is finished. We are not designing a language standard that will be implemented here and there around the world using different teams and different technologies for different purposes for the next 100 years. This is Emacs Lisp, not Common Lisp. Let's not get carried away. And even Common Lisp defines return values for the vast majority of its functions, whether or not they perform side effects.