0

Is there an idiomatic/commonly used/established convention to convert non-nil values to t that other Elisp programmers are likely to recognize?

Sometimes I have a non-nil value, say from calling member, that I want to return as either t or nil (so that I don't leak implementation details (Cf. Hyrum's Law)).

The Emacs Lisp Coding Conventions, for example, say nothing about this that I can see. The closest I've found is the Elisp manual's section on nil and t, which says "When you need to choose a value that represents true, and there is no other basis for choosing, use t."

Ways I've come up with:

(and val t)

(if val t nil)

(not (not val))

Does one of these have a benefit over the other? Is one "more idiomatic"?

chwarr
  • 105
  • 6
  • What's the question? Define "idiomatic way". Did you check [Coding Conventions](https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html)? If you don't find anything there then the answer is no. But what are you really trying to do, and why? – Drew May 22 '20 at 04:17
  • @Drew, thanks for the suggestions to on how to clarify. I've edited the question to highlight that this is about wanting to hide implementation details (particularly under maintenance). I've also added the higher level problem I was trying to solve that prompted this question and how I solved it. While I've avoided needing to convert in this case, in my newness to Elisp, it still seems like conversion needs to happen sometimes. Is this, perhaps, more of a [Code Review](https://codereview.stackexchange.com/) question? – chwarr May 22 '20 at 06:04
  • Thanks. But is the question really *whether there is a coding convention* about this (the answer is *no*, I think)? Or is it simply *how to convert non-nil to `t`* - which is the question @Stefan answered? You might consider simplifying the question to one or the other - or post two simplified questions. – Drew May 22 '20 at 15:42
  • Trimmed it down. – chwarr May 23 '20 at 07:10
  • Looks good; thanks. – Drew May 23 '20 at 15:47

2 Answers2

2

The better option is:

(not (not X))

Some of the advantages are in the ability of the byte-compiler to optimize it away. Also for me it's easy to visually see that it's a "virtual no-op" yet at the same time it makes it clear that it was introduced on purpose.

Stefan
  • 26,154
  • 3
  • 46
  • 84
1
(and val t)

is the cleanest and clearest. 

(if val t nil)

is also clear but is slightly more verbose and less clean.

There may be efficiency advantages to using

(not (not val))

as Stefan mentions. However, efficiency gains are likely minimal in most cases since negation is a cheap operation.

While double negation is clearly intentional, the reason why the programmer would include it is less clear. For example, it could have originally been a single negation and the second one could have been added during debugging and never been removed. There are other possibilities as well.

Qudit
  • 828
  • 8
  • 16