emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Improving aesthetics & readability of backquote


From: Paul W. Rankin
Subject: Improving aesthetics & readability of backquote
Date: Mon, 20 May 2019 13:03:21 +1000
User-agent: mu4e 1.2.0; emacs 26.2

wrt. http://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/msg00022.html

I understand that aesthetics and readability are not going to be a concern for many, but I'd like to put forth this suggestion anyway.

For as long as I've used Emacs Lisp, I've found the backquote[1] to be ugly and unreadable, to the extent that I've gone to lengths to avoid using it. It looks like a mistaken quote added by someone using an unfamiliar keyboard. Then when you add the splice... ugh..

   (setq a '(3 4))
   (setq b '(6 7))

   `(1 2 ,a 5 ,@b 8)
   -> (1 2 (3 4) 5 6 7 8)

I know people make fun of Perl for being "line noise"[2] and IMO the backquote approaches that.

Add to this the \` is just an alias for backquote, which doesn't imply any meaning except as relation to itself. Its meaning cannot be inferred through the code alone.

I suggest that we could introduce some aliases and augment the reader constucts a little to make them more aesthetically pleasing and more readable.

The easy first step would be chosing a nice and meaningful alias for backquote. Considering the semantic role of backquote seems to be both to "quote" and selectively "eval" its body form, and together with the tradition of Emacs Lisp making contractions from e.g. "define" + "function" -> "defun", then I suggest:

   (quoteval ...)

Which sits similarly to:

   (quote ...)
   (eval ...)

Then it would be a case of augmenting the "unquote" ,VAR and "splice" ,@VAR reader constructs:

   (quoteval (1 2 (unquote a) 5 (splice b) 8 ))
   -> (1 2 (3 4) 5 6 7 8)

(Both "insert" and "unquote" are used in backquote.el; I lean towards "unquote" because there is already the function "insert".)

Although the above is more verbose, to me this is immediately clear what's happening in the code, and is much more aesthetically pleasing.

If it remains unclear, my suggestion is not to supplant the original syntax; I position this suggestion in a similar vein as the rx library.

Thoughts?

[1]: (info "(elisp) Backquote")
[2]: https://famicol.in/sigbovik/


--
https://www.paulwrankin.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]