all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: MON KEY <monkey@sandpframing.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Juanma Barranquero <lekktu@gmail.com>, 7086@debbugs.gnu.org
Subject: bug#7086: `booleanp' return value is multi-valued list
Date: Fri, 24 Sep 2010 02:41:43 -0400	[thread overview]
Message-ID: <AANLkTimhW4CLptN0jk=ZiveSnsRd2rfWmZ-2Eiaf2DyK@mail.gmail.com> (raw)
In-Reply-To: <83pqw4vpxv.fsf@gnu.org>

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)





  reply	other threads:[~2010-09-24  6:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-22 21:58 bug#7086: `booleanp' return value is multi-valued list MON KEY
2010-09-22 22:35 ` Juanma Barranquero
2010-09-23  2:06   ` Kevin Rodgers
2010-09-23 10:29     ` Juanma Barranquero
2010-10-03  1:11     ` Chong Yidong
2010-09-23  4:22   ` MON KEY
2010-09-23 10:31     ` Juanma Barranquero
2010-09-23  8:12 ` Eli Zaretskii
2010-09-24  6:41   ` MON KEY [this message]
2010-09-24  8:48     ` Juanma Barranquero
2010-09-24  9:28     ` Lawrence Mitchell
2010-09-24 22:00 ` MON KEY
2010-09-25  9:18   ` Juanma Barranquero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTimhW4CLptN0jk=ZiveSnsRd2rfWmZ-2Eiaf2DyK@mail.gmail.com' \
    --to=monkey@sandpframing.com \
    --cc=7086@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=lekktu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.