Re: Wierd Elispsisms

["Óscar Fuentes" <ofv@wanadoo.es>]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sun, Aug 11, 2013 at 1:16 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> look bizarre. As someone who is not strong on Elisp, I was puzzled at
>> first. Finally realized that the point is to force a boolean value for
>> `compressed'.
>
> Both expressions are common enough.

Grepping for "(not (not " on .el files under lisp/ shows 11 occurrences.
Detecting "(and ... t) is harder, so didn't tried. However, if casting a
value to a boolean is a common task, that's a strong reason for
delegating the job to a function.

>> And, if there exists a reason for using nil/t instead of the original
>> value here and elsewhere, why doesn't exist a function for casting an
>> arbitrary value to a boolean?
>
> Generally speaking, I'd say (not (not X)) or (and X t) can be
> optimized and a funcall not.

I guess that the byte-compiler could apply the same optimization to a
defsubst.

> But anyway, I suspect the answer is, why
> use a function when you have a simple idiom every lisp programmer will
> understand and have quite internalized?  To me, what you're asking is
> as if you objected to the common use of (or x y) instead of (if x x
> y). Idioms.

As already mentioned, they don't look simple to me, but I'm not a Lisp
programmer (neither are most Emacs users who at some point try to hack
some Elisp).

About the idioms, C allows lots of things which are quite "obvious" to
the eyes of the expert C hacker and for a long time writing C code on a
certain "clever" (read "compressed & mind twisting") way was considered
the hallmark of the expert, but nowadays those idioms are often
discouraged, as they make the code hard to read and maintain. We could
say the same about most languages, with some extreme cases (Perl)

All this is IMHO, no big issue, I just was curious. Thanks for
explaining Juanma.