From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.bugs Subject: bug#7086: `booleanp' return value is multi-valued list Date: Fri, 24 Sep 2010 18:00:26 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1285366283 31534 80.91.229.12 (24 Sep 2010 22:11:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 24 Sep 2010 22:11:23 +0000 (UTC) To: 7086@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 25 00:11:22 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OzGUC-0005QZ-VB for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Sep 2010 00:11:21 +0200 Original-Received: from localhost ([127.0.0.1]:40960 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzGUC-0001G6-78 for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 Sep 2010 18:11:20 -0400 Original-Received: from [140.186.70.92] (port=60383 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzGU0-0001DC-9u for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2010 18:11:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OzGTz-0006f1-1W for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2010 18:11:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39841) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OzGTy-0006ev-RM for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2010 18:11:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OzGHK-0001WT-As; Fri, 24 Sep 2010 17:58:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: MON KEY Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Sep 2010 21:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7086 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 7086-submit@debbugs.gnu.org id=B7086.12853654695845 (code B ref 7086); Fri, 24 Sep 2010 21:58:02 +0000 Original-Received: (at 7086) by debbugs.gnu.org; 24 Sep 2010 21:57:49 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OzGH6-0001WE-Sh for submit@debbugs.gnu.org; Fri, 24 Sep 2010 17:57:49 -0400 Original-Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OzGH4-0001W7-Nc for 7086@debbugs.gnu.org; Fri, 24 Sep 2010 17:57:47 -0400 Original-Received: by wwb13 with SMTP id 13so104303wwb.15 for <7086@debbugs.gnu.org>; Fri, 24 Sep 2010 15:00:26 -0700 (PDT) Original-Received: by 10.216.193.195 with SMTP id k45mr3286964wen.32.1285365626120; Fri, 24 Sep 2010 15:00:26 -0700 (PDT) Original-Received: by 10.216.67.195 with HTTP; Fri, 24 Sep 2010 15:00:26 -0700 (PDT) X-Google-Sender-Auth: EdRPfwddvT4hrX7NDBVhyBA5x50 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 24 Sep 2010 17:58:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:40409 Archived-At: Lawrence Mitchell >> This one matters. It is the penultimate Emacs lisp predicate. >> It tests for a boolean value yet it returns a list. > Which you can happily dispatch on: > > (if (booleanp foo) > (if (null foo) > (do-something-if-foo-is-nil) > (do-something-if-foo-is-t)) > (do-something-if-foo-is-neither-nil-nor-t)) Not happliy if happiness means employing nested ifs conditioned on the variadic return value of a boolean. > It's hard to see what else is required. Not much, besides not having to reinvestigate the boolean status of foo repeatedly... The version of `booleanp' supplied at the bottom of this message does what I think is expected. My point is, your example illustrates a single branch where the return value of `booleanp' isn't cached away in some local var. There are certainly situations where holding onto that value for subsequent interrogation later is desired. With your example one is required to repeat the idiom: (if (booleanp foo) (if (null foo) {...} )) What I am suggesting is that in many situations where one wants to know if the value of foo is boolean it is often desired to reexamine that value more than once either in the same form or enclosing environment. So, it makes sense (and is cleaner than the repeated branching) to store `booleanp's return value a local var for later (re)examintation, also by storing foo in a local variable we can pass its _state_ around as data However with regards the latter, doing it cleanly requires that `booleanp' return a list with a consistent form for all possible states of foo; `t', `nil', and not-a-boolean. Which FWIW is the "reflection" i was referred to earlier though apparently Eli mistook this to be of the navel gazing type. As it is now with `booleanp's current multivariant return values: { (t) | (nil t) | nil } even when we cache the value it is still required to deconstruct the list elements imediately because it is unreasonable to delay taking the car of (nil t) in lieu of some later check for (null foo) because foo might've changed since then. Which BTW is why your solution imediately (re)investigates foo just after interrogating it. IOW, as currently configured no matter what the return value of `booleanp' subsequent "dispatching" still requires the data that `booleanp' returned your (null foo) being an illustrative case. Changing booleanp to consistently return a two elt list for each of its three possible results would address this and is a much better solution than requiring all callers to repeatedly (re)xamine foo just to parse/verify the junk booleanp currently throws out. > Calling a function expecting an argument without one is an error, Your missing my point. W/re `booleanp' how the function call occurs is irrelevant. The error isn't calling the function without an arg, the locus of the error was that the interpreter evaluated the form _without_ signalling. (defun tt--bool-nil (()) (booleanp ())) (disassemble 'tt--bool-nil) ;=> Debugger entered--Lisp error: (error "Compilation failed") (defun tt--not-gonna #(x) x) ;=> Debugger entered--Lisp error: (invalid-read-syntax "#") > irrespective of the function involved. Why do you assume the call will happen as a function and not instead inside of or as a macro, or in a closed over lexical environ on the heap, is delayed, etc.? Which is what I am suggesting with: "These are just the types of situations where interrogating a boolean is what is wanted." > Do you in fact want: > (require 'cl) Well, even when in fact i do, the byte-compiler would protest that in fact what I wanted was: (eval-when-compile (require 'cl)) Besides, the cl.el package is certainly not a panacea here given the lack of multiple value return. This said, following is what is wanted: (defun new-booleanp (putative-boolean) (or (and (eq putative-boolean t) '(t t)) (and (eq putative-boolean nil) '(nil t)) '(nil nil))) (defun multiple-booleanp (obj) (values-list (new-booleanp obj))) (multiple-booleanp t) ;=> t, t (multiple-booleanp nil) ;=> t, nil (multiple-booleanp "bubba") ;=> nil, nil And barring the cold chance in hell that Emacs will ever return multiple values I'd settle for: (multiple-booleanp t) ;=> (t t) (multiple-booleanp nil) ;=> (t nil) (multiple-booleanp "bubba") ;=> (nil nil) > Lawrence Mitchell -- /s_P\