Re: Improving aesthetics & readability of backquote

[Alan Mackenzie]

Hello, Paul.

On Mon, May 20, 2019 at 13:03:21 +1000, Paul W. Rankin wrote:
> 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.

I personally have no such problems with backquote.  If anything, the
comma operator appearing _before_ something rather than after it jars a
little.  But only a little.

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

Sorry, I can't make anything out of that paragraph.  What meaning?  What
relation to what?  Which 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.

I don't agree with you that (quote foo) is more readable than 'foo.  I
would find (quote foo) tiring to write, and (more importantly) tiring to
read.  I believe very early lisps were lacking the ' operator.
(quoteval foo) would be even worse for me.

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

To me, it would be the opposite.  It would be less aesthetically
pleasing.  And tiring to read.

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

But code has to be maintained, and everybody would have to know the
meaning of these new aliases, and be practiced with them, to be able to
maintain code using them.

> Thoughts?

I'm afraid I'm against such changes.

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


> -- 
> https://www.paulwrankin.com

-- 
Alan Mackenzie (Nuremberg, Germany).