bug#7086: `booleanp' return value is multi-valued list

bug#7086: `booleanp' return value is multi-valued list

[MON KEY]

"Return non-`nil' if OBJECT is one of the two canonical boolean
 values: `t' or `nil'."

It should be documented both in the manual and the docstring of `booleanp' that
its return value is a list.

Specifically that the following two forms return muti-valued lists:

 (booleanp t)
 ;=> (t)

 (booleanp nil)
 ;=> (nil t)

Additionaly, given the nature of this function and the puposes it
might serve, it
should be documented _why_ the return value is a list.

Frustratingly, while the manual waxes on about the readers interpretation of
fundamental identity equivalence w/re `nil' and `()' and their self evaluating
specialness it has frightening little to offer w/re how one should reflect on
these things values within lisp programs.

    (info "(elisp)nil and t")

In lieu of this, the terseness of the `booleanp's docstring extends a
tautological
flavor which can only be met with confusion by the uninitiated.

Indeed, while I can appreciate why (booleanp nil) returns a two element list
I'm unable to reason a rationale for why (booleanp t) doesn't?

Also, there is this goofiness:

(defun tt--bool-w/opt (&optional x)
  (booleanp x))

(tt--bool-w/opt nil) ;=> (nil t)
(tt--bool-w/opt t)   ;=> (t)
(tt--bool-w/opt)     ;=> (nil t)

(defun tt--bool (x)
  (booleanp x))

(tt--bool nil)   ;=> (nil t)
(tt--bool t)     ;=> (t)
(tt--bool 'nil)  ;=> (nil t)
(booleanp '())   ;=> (nil t)
(booleanp ())    ;=> (nil t)

(tt--bool)
;=> Debugger entered--Lisp error:
; (wrong-number-of-arguments (lambda (x) (booleanp x)) 0)

Also, I find this above error troublesome given that the following
form returns:

(tt--bool-w/opt)

Whereas this one doesn't:

(defun tt--bool-nil (nil)
  (booleanp nil))

(tt--bool-nil)
;=> Debugger entered--Lisp error:
; (wrong-number-of-arguments (lambda (nil) (booleanp nil)) 0)

(tt--bool-nil 'nil)
;=> Debugger entered--Lisp error: (setting-constant nil)

And, the nature of the above errors doesn't really stand up given that:

(defun tt--bool-qt-nil (())
  (booleanp '()))

(tt--bool-qt-nil)
;=> Debugger entered--Lisp error: (wrong-number-of-arguments (lambda
(nil) (booleanp (quote nil))) 0)

(tt--bool-qt-nil nil)
;=> Debugger entered--Lisp error: (setting-constant nil)

(tt--bool-qt-nil ())
;=> Debugger entered--Lisp error: (setting-constant nil)

These last two being the most maddening.

Emacs lets me define the function but then accuses me of somthing I didn't even
(appear) to do, i.e. set the constant nil.

--
/s_P\

bug#7086: `booleanp' return value is multi-valued list

[Juanma Barranquero]

On Wed, Sep 22, 2010 at 23:58, MON KEY <monkey@sandpframing.com> wrote:

> "Return non-`nil' if OBJECT is one of the two canonical boolean
>  values: `t' or `nil'."
>
> It should be documented both in the manual and the docstring of `booleanp' that
> its return value is a list.

Why? It is a type predicate. If anything, it should be changed to
return t or nil, as "(elisp)2.6 Type Predicates" says:

     A type predicate function takes one argument; it returns `t' if the
  argument belongs to the appropriate type, and `nil' otherwise.

The fact that it returns nil or a list is an implementation detail.

> Indeed, while I can appreciate why (booleanp nil) returns a two element list
> I'm unable to reason a rationale for why (booleanp t) doesn't?

Why do you expect any kind of rationale, other than the simple fact
that it is implemented as

  (memq object '(nil t)))

?

> Also, there is this goofiness:
[...]
> ; (wrong-number-of-arguments (lambda (x) (booleanp x)) 0)

What is exactly the goofiness?

> (tt--bool-nil)
> ;=> Debugger entered--Lisp error:
> ; (wrong-number-of-arguments (lambda (nil) (booleanp nil)) 0)

Again, what did you expect?

> These last two being the most maddening.
>
> Emacs lets me define the function but then accuses me of somthing I didn't even
> (appear) to do, i.e. set the constant nil.

Of course you did. Why do you expect to use `nil' as an argument and
not have trouble?

    Juanma

bug#7086: `booleanp' return value is multi-valued list

[Kevin Rodgers]

On 9/22/10 4:35 PM, Juanma Barranquero wrote:
> On Wed, Sep 22, 2010 at 23:58, MON KEY<monkey@sandpframing.com>  wrote:
>
>> "Return non-`nil' if OBJECT is one of the two canonical boolean
>>   values: `t' or `nil'."
>>
>> It should be documented both in the manual and the docstring of `booleanp' that
>> its return value is a list.
>
> Why? It is a type predicate. If anything, it should be changed to
> return t or nil, as "(elisp)2.6 Type Predicates" says:
>
>       A type predicate function takes one argument; it returns `t' if the
>    argument belongs to the appropriate type, and `nil' otherwise.
>
> The fact that it returns nil or a list is an implementation detail.
>
>> Indeed, while I can appreciate why (booleanp nil) returns a two element list
>> I'm unable to reason a rationale for why (booleanp t) doesn't?
>
> Why do you expect any kind of rationale, other than the simple fact
> that it is implemented as
>
>    (memq object '(nil t)))

(and (memq object '(nil t))
      t)

would be better.

-- 
Kevin Rodgers
Denver, Colorado, USA

bug#7086: `booleanp' return value is multi-valued list

[MON KEY]

On Wed, Sep 22, 2010 at 6:35 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Wed, Sep 22, 2010 at 23:58, MON KEY <monkey@sandpframing.com> wrote:
>
>> "Return non-`nil' if OBJECT is one of the two canonical boolean
>>  values: `t' or `nil'."
>>
>> It should be documented both in the manual and the docstring of `booleanp' that
>> its return value is a list.
>
> Why? It is a type predicate. If anything, it should be changed to
> return t or nil,

I'm pretty sure returning a single value is NTRT and can only generate
confusion e.g.:

(booleanp (booleanp "not-a-boolean")) ;=> t

What I would suggest is the following behavior:

(booleanp t)
;=> (t t)

(booleanp nil)
;=> (nil t)

(booleanp "not-a-boolean")
;=>  (nil nil)

Returning a two element list on success shares some similarity with
Common Lisp's multiple values which seem pertinent for special cases
like this one in that there is provision for reflection that is hard
to obtain with a uni-valued return, e.g. Right now if I ask:

(let ((query-truth (eq 8 3)))
     (car (booleanp query-truth)))
;=> nil

it is hard to know if the thing being queried of was indeed a boolean.

Whereas with a two element proper list:

(let ((query-truth (eq 8 3)))
     (and (cadr (booleanp query-truth))
          (not (car (booleanp query-truth)))))
;=> t

We can be sure we got a boolean and that it was nil.

--
/s_P\

bug#7086: `booleanp' return value is multi-valued list

[Eli Zaretskii]

> Date: Wed, 22 Sep 2010 17:58:12 -0400
> From: MON KEY <monkey@sandpframing.com>
> Cc: 
> 
> "Return non-`nil' if OBJECT is one of the two canonical boolean
>  values: `t' or `nil'."
> 
> It should be documented both in the manual and the docstring of `booleanp' that
> its return value is a list.

The precise form of the return value is an implementation detail.
Such details need not be documented.

Are there any _real-life_ use cases where this matter?

> Additionaly, given the nature of this function and the puposes it
> might serve, it
> should be documented _why_ the return value is a list.

Implementation details don't need to be documented, unless they really
matter to Lisp programs which use these APIs.

> Frustratingly, while the manual waxes on about the readers interpretation of
> fundamental identity equivalence w/re `nil' and `()' and their self evaluating
> specialness it has frightening little to offer w/re how one should reflect on
> these things values within lisp programs.

The manual is not a guide to reflections.  Please explain what is
missing, exactly.

> Indeed, while I can appreciate why (booleanp nil) returns a two element list
> I'm unable to reason a rationale for why (booleanp t) doesn't?

Again, why is it important?

> Also, there is this goofiness:
> 
> (defun tt--bool-w/opt (&optional x)
>   (booleanp x))
> 
> (tt--bool-w/opt nil) ;=> (nil t)
> (tt--bool-w/opt t)   ;=> (t)
> (tt--bool-w/opt)     ;=> (nil t)

See (info "(elisp)Argument List") for an instant enlightening: omitted
optional arguments default to nil.

> (defun tt--bool (x)
>   (booleanp x))
> 
> (tt--bool nil)   ;=> (nil t)
> (tt--bool t)     ;=> (t)
> (tt--bool 'nil)  ;=> (nil t)
> (booleanp '())   ;=> (nil t)
> (booleanp ())    ;=> (nil t)
> 
> (tt--bool)
> ;=> Debugger entered--Lisp error:
> ; (wrong-number-of-arguments (lambda (x) (booleanp x)) 0)

Exactly!  See the above node in the manual.

But this has nothing to do with booleanp.

> Emacs lets me define the function but then accuses me of somthing I didn't even
> (appear) to do, i.e. set the constant nil.

Emacs gives you enough rope to hang yourself; don't do that, unless
you mean it.

bug#7086: `booleanp' return value is multi-valued list

[Juanma Barranquero]

On Thu, Sep 23, 2010 at 04:06, Kevin Rodgers <kevin.d.rodgers@gmail.com> wrote:

> (and (memq object '(nil t))
>     t)
>
> would be better.

Yes, indeed.

    Juanma

bug#7086: `booleanp' return value is multi-valued list

[Juanma Barranquero]

On Thu, Sep 23, 2010 at 06:22, MON KEY <monkey@sandpframing.com> wrote:

> I'm pretty sure returning a single value is NTRT and can only generate
> confusion e.g.:

No. Returning a single value is what is *expected* of a type predicate
in Emacs Lisp, and so far it hasn't apparently generated any
confusion.

    Juanma

bug#7086: `booleanp' return value is multi-valued list

[MON KEY]

On Thu, Sep 23, 2010 at 4:12 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> The precise form of the return value is an implementation detail.
> Such details need not be documented.
>
> Are there any _real-life_ use cases where this matter?
>
Probably none in the life of an Emacs devel. Though down here
in the reified mud of consequence when Emacs prompts
that some file variable doesn't satisfy booleanp it would
be nice to know that the predicate was homoiconic. Whatever.

(info "(elisp)File Local Variables")

,----
|    You can specify safe values for a variable with a
| `safe-local-variable' property.  The property has to be a function of
| one argument; any value is safe if the function returns non-`nil' given
| that value.  Many commonly-encountered file variables have
| `safe-local-variable' properties; these include `fill-column',
| `fill-prefix', and `indent-tabs-mode'.  For boolean-valued variables
| that are safe, use `booleanp' as the property value.  Lambda
| expressions should be quoted so that `describe-variable' can display
| the predicate.
`----

>
> Implementation details don't need to be documented, unless they really
> matter to Lisp programs which use these APIs.
>

This one matters. It is the penultimate Emacs lisp predicate.
It tests for a boolean value yet it returns a list.

>
> Please explain what is  missing, exactly.
>

I did. The return values should be either one of:

 t | nil

 or  (my preference):

(t t) | (nil t)

Returning two different length lists for a predicate that interrogates a boolean
is ill conceived.

>
> Again, why is it important?
>

How can it not be?

>> Also, there is this goofiness:
>>
>> (defun tt--bool-w/opt (&optional x)
>>   (booleanp x))
>>
>> (tt--bool-w/opt nil) ;=> (nil t)
>> (tt--bool-w/opt t)   ;=> (t)
>> (tt--bool-w/opt)     ;=> (nil t)
>
> See (info "(elisp)Argument List") for an instant enlightening: omitted
> optional arguments default to nil.
>

Oh, now I get it.

- Omitted optional arguments default to nil;
- and nil evaluates to itself;
- the empty list is identical to nil;
- and interrogating the constant with a predicate returns a list...
- of length (length (booleanp nil)) => 2
- unless its of length (length (booleanp t)) => 1

Yep, crystal clear.

>> (defun tt--bool (x)
>>   (booleanp x))

> {...}

> Exactly!  See the above node in the manual.
>
> But this has nothing to do with booleanp.

It has everything to do with it.
These are just the types of situations where interrogating a boolean is what is
wanted.

>
> Emacs gives you enough rope to hang yourself; don't do that, unless
> you mean it.
>
Its a horrible metaphor. That's not rope its Emacs' leash which it
drags along so
someone can always drag it back out of the mire:

(defun booleanp (object)
  (or (and (eq object t) '(t t))
      (and (eq object nil) '(nil t))))

(booleanp "bubba")
;=> nil

(booleanp t)
;=> (t t)

(booleanp nil)
;=> (nil t)

(booleanp ())
;=> (nil t)

bug#7086: `booleanp' return value is multi-valued list

[Juanma Barranquero]

On Fri, Sep 24, 2010 at 08:41, MON KEY <monkey@sandpframing.com> wrote:

> I did. The return values should be either one of:
>
>  t | nil

Yes.

    Juanma

bug#7086: `booleanp' return value is multi-valued list

[Lawrence Mitchell]

MON KEY wrote:
> 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))

It's hard to see what else is required

[...]

> On Thu, Sep 23, 2010 at 4:12 AM, Eli Zaretskii <eliz@gnu.org> wrote:

[...] MON KEY claims that (funcall (lambda (x) (booleanp x)))
giving an error is somehow problematic.
>> Exactly!  See the above node in the manual.

>> But this has nothing to do with booleanp.

> It has everything to do with it.  These are just the types of
> situations where interrogating a boolean is what is wanted.

What?

(funcall (lambda (x) (1+ x)))
 => (wrong-number-of-arguments (lambda (x) (1+ x)) 0)

(funcall (lambda (x) (booleanp x)))
  => (wrong-number-of-arguments (lambda (x) (booleanp x)) 0)

Calling a function expecting an argument without one is an error,
irrespective of the function involved.

Do you in fact want:

(require 'cl)

(defun* foo (&optional (x nil got-x-p))
  (if got-x-p
      (do-something-if-x-was-an-argument x)
    (do-something-different)))

[...]


-- 
Lawrence Mitchell <wence@gmx.li>

bug#7086: `booleanp' return value is multi-valued list

[MON KEY]

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\

bug#7086: `booleanp' return value is multi-valued list

[Juanma Barranquero]

On Sat, Sep 25, 2010 at 00:00, MON KEY <monkey@sandpframing.com> wrote:

> (defun new-booleanp (putative-boolean)
>  (or (and (eq putative-boolean t) '(t t))
>      (and (eq putative-boolean nil) '(nil t))
>      '(nil nil)))

But this is not an Emacs Lisp type predicate, it's a new function with
a very specific functionality.

It is perhaps useful, but certainly as a different function. For one,
if the stock `booleanp' worked as you suggest, it could not be used in
its main uses right now (as :type in a defcustom and as
'safe-local-variable property value).

Again: the fact that the current `booleanp' returns a "multivalued
list" (not really, but still) is just an unfortunate implementation
detail.

The best way to deal with this bug is implement Kevin's suggestion
(i.e., make booleanp into "(and (memq object '(nil t)) t)") so it
follows the docs, and for you to open a new wishlist bug with your
proposed new function.

    Juanma

bug#7086: `booleanp' return value is multi-valued list

[Chong Yidong]

Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:

> (and (memq object '(nil t))
>      t)
>
> would be better.

I've checked the change you suggested into the trunk.  Thanks.