From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: master 2bb0703 1/2: lisp/*.el: Force non-nil result to t, to match docstring Date: Thu, 17 Oct 2019 15:15:39 +0000 (UTC) Message-ID: References: <<20191017004602.22269.2935@vcs0.savannah.gnu.org>> <<20191017004604.866DF20BC2@vcs0.savannah.gnu.org>> <<875zkonpqm.fsf@gnus.org>> <> <<871rvcnmg1.fsf@gnus.org>> <<8336frdcs9.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="119935"; mail-complaints-to="usenet@blaine.gmane.org" Cc: lekktu@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 17 18:10:28 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iL8M7-000V46-BV for ged-emacs-devel@m.gmane.org; Thu, 17 Oct 2019 18:10:27 +0200 Original-Received: from localhost ([::1]:52034 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iL8M5-0003m0-Mh for ged-emacs-devel@m.gmane.org; Thu, 17 Oct 2019 12:10:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55585) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iL7VI-0003C8-TB for emacs-devel@gnu.org; Thu, 17 Oct 2019 11:15:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iL7VH-0004o2-5q for emacs-devel@gnu.org; Thu, 17 Oct 2019 11:15:52 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:38118) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iL7VF-0004kd-8F; Thu, 17 Oct 2019 11:15:49 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9HF6P2I178347; Thu, 17 Oct 2019 15:15:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=Y7C62E8uBq+uv/c8WNvDM6lrfFlLle2uGvh/8FXrBbU=; b=BgucX3SyroOUsQw4JcGw8Im/dieYazvnDBf5whvjha/EbUdL+RJ+I0ysVPXjLTv+LCVo C3bon/KLB3q+lZ0hjdyT9FnA6ZlXqHEfv1sZKoHmARRmQDjYFhowLa7x189ZgLuTs6k7 aSlgKdpdP4wIzqIFgQtL2JqFEd90pKui8z9tmRJ4j2npljSWDbjIUr6VrQexCobNXl8x sBbRsPLa/Ha/a5u20yJmyJ1Bm/bulhTjIZFaFDQpsdw6XA5FeCflDOm7DQyoYZ7uBtKa KNIXyYveTCJLuPScv2F+DAlF8kV3tC6DUM+fgGQOjqILvbyhiU8CjehtZCqfX1DJcGr6 8A== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 2vk6sqy4mf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Oct 2019 15:15:45 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9HFAKxI125851; Thu, 17 Oct 2019 15:15:44 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 2vp70q3xyk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Oct 2019 15:15:44 +0000 Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x9HFFhwE005914; Thu, 17 Oct 2019 15:15:44 GMT In-Reply-To: <<8336frdcs9.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9412 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910170137 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9412 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910170137 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:241142 Archived-At: > > > Depends. When the function is a predicate, t/nil makes more sense > > > (generally speaking, there are exceptions) that non-nil/nil. > > > > I thought it was kinda opposite: When it's a predicate, we only care > > about nil/non-nil. >=20 > No, predicate returns a boolean result. Recall the recent discussion > of using -p in function and variable names. That begs the question of what "boolean result" means. Is the number 42 or the string "Bernie" or "false" a Boolean value (true), or not? In Lisp, in general (e.g., other than Scheme), Boolean values include so-called "generalized booleans", which means nil (for false) and any non-nil value (for true). That some particular function (predicate) might want to always return t as the non-nil value to indicate true is up to that function, and if the fact that it does so is important to its behavior then it should be documented that it does so. If there's no good reason for a predicate to return something other than t to represent true, then it should typically just use t. But in general there should be no requirement for a predicate to return t for true. Any non-nil value means true, a priori. I agree with this general and longstanding Lisp convention. So +1 for not, in general depending on t to be the only true value. So IIUC, I agree with Lars on this general question. There's nothing wrong with a predicate always returning only t for true, of course. That doesn't affect how other predicates handle generalized Boolean values. t is non-nil, after all, even if non-nil is not necessarily t. (Not saying anything about whether this or that particular predicate is better "fixed" by ensuring that it uses only t for true or changing its doc to say that t is the only true value. Not saying anything about the "fixes" Juanma made.) Node (elisp) `nil and t' says it very well: In contexts where a truth value is expected, any non-'nil' value is considered to be TRUE. However, 't' is the preferred way to represent the truth value TRUE. When you need to choose a value that represents TRUE, and there is no other basis for choosing, use 't'. The symbol 't' always has the value 't'. I agree with every bit of that text. If there is no good reason not to use t, use t. But something TESTING a value as a truth value should, in general, consider any non-nil value to be true. ("In general", because sometimes the value to test can be either a truth value or something else. In such a case, different non-nil values can mean different things.) And there is often a good reason for a given predicate to return some other non-nil value than t for true. Why is this true so often? Because it lets the predicate be, secondarily, more than a predicate, returning secondary information along with truth value t.=20 Common Lisp is also a good reference in this regard. "In Common Lisp, as in most Lisp dialects..." https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node9.html http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_g.htm