Wierd Elispsisms (was: trunk r113793: lisp/*.el: More lexical-binding warnings' cleanups.)

Wierd Elispsisms (was: trunk r113793: lisp/*.el: More lexical-binding warnings' cleanups.)

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

[elisp/woman.el]

@@ -1614,7 +1614,7 @@
 	(let* ((bufname (file-name-nondirectory file-name))
 	       (case-fold-search t)
 	       (compressed
-		(not (not (string-match woman-file-compression-regexp bufname)))))
+		(and (string-match-p woman-file-compression-regexp bufname) t)))
 	  (if compressed
 	      (setq bufname (file-name-sans-extension bufname)))



The expressions

(not (not (something)))

and

(and (something-p) t)

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'.

Why is so important to use a nil/t value for `compressed'?

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?

Using (and ... t) or (not (not ...)) is probably not harder to type than
a function, but the function has the advantage of clearly conveying the
intention and is safer to edit.

Re: Wierd Elispsisms (was: trunk r113793: lisp/*.el: More lexical-binding warnings' cleanups.)

[Juanma Barranquero]

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.

> 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. 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.

    J

Re: trunk r113793: lisp/*.el: More lexical-binding warnings' cleanups.

[Glenn Morris]

This broke the test-suite.

http://hydra.nixos.org/build/5672580

Re: Wierd Elispsisms

[Óscar Fuentes]

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.

Re: trunk r113793: lisp/*.el: More lexical-binding warnings' cleanups.

[Juanma Barranquero]

On Sun, Aug 11, 2013 at 8:28 PM, Glenn Morris <rgm@gnu.org> wrote:

> This broke the test-suite.

I think I found the culprit.

   J