From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: To `boundp' or not to `boundp'? Date: Tue, 1 Sep 2015 13:42:25 -0700 (PDT) Message-ID: <2e80cc7f-0118-4a58-a5a8-62ad8262d905@default> References: < <55E5C99B.3020608@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 1441140188 25903 80.91.229.3 (1 Sep 2015 20:43:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 20:43:08 +0000 (UTC) To: Barry Margolin , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Sep 01 22:42:56 2015 Return-path: Envelope-to: geh-help-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 1ZWsOF-0006eW-TD for geh-help-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 22:42:48 +0200 Original-Received: from localhost ([::1]:58427 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWsOF-0002Bq-Rb for geh-help-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 16:42:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWsO0-00025I-S5 for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 16:42:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWsNx-0006yC-Md for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 16:42:32 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:23514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWsNx-0006xz-GV for help-gnu-emacs@gnu.org; Tue, 01 Sep 2015 16:42:29 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t81KgRPI001591 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Sep 2015 20:42:27 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t81KgQG4024438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2015 20:42:27 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t81KgQZD006081; Tue, 1 Sep 2015 20:42:26 GMT In-Reply-To: <> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:106970 Archived-At: > > > > I often see code like this > > > > (when (and (boundp 'xxx-mode) xxx-mode) ...) > > > > > > The "proper" way to do that is to use bound-and-true-p. > > > > That certainly is *not* proper for the more general case > > (and (boundp 'xxx) xxx), where the value of `xxx' is > > not necessarily Boolean or is not used only as a Boolean. > > > > Well, it works the same, but the _name misleads_ terribly > > in this case, even if the doc does let you know that the > > variable value (not t or nil) is returned, when bound. >=20 > The name isn't misleading if you use it in a boolean context, > like the WHEN call in the OP. Correct. It is not misleading in that case. Which is why I qualified the statement with "where the value of `xxx' is _not_ necessarily Boolean or is _not_ used only as a Boolean." It does not mislead in all cases, no. But it does in some. It is misleading in general because what it suggests is not what is meant in some (common) cases. Not a great name. FWIW, if someone proposed `member-p' instead of `member' I would have the same remark. The former emphasizes the Boolean/predicate nature; the latter does not. A fortiori, if someone were to propose `member-and-true-p' - no thanks. It's not a big deal, certainly. But neither is it needed. (and (boundp 'VAR) VAR) is succinct enough and clear enough, IMHO, and it has the advantage of _never_ misleading.