Improving aesthetics & readability of backquote

Improving aesthetics & readability of backquote

[Paul W. Rankin]

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

Re: Improving aesthetics & readability of backquote

[Stefan Monnier]

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

You'd feel quite at home in Scheme where the reader's

    'E  =>  (quote E)
    
is complemented by

    `E  =>  (quasiquote E)
    ,E  =>  (unquote E)
    ,@E =>  (unquote-splicing E)

Elisp doesn't have that, mostly for historical reasons, I think.
I haven't been able to confirm it, but I believe the road looked like:
the Elisp reader originally only had the `quote` special element and
since people don't like to write (backquote (foo bar (unquote baz))),
they started writing (` (foo bar (, baz))) which was at least vaguely
reminiscent of the "normal" backquote/unquote used in other Lisps.
This is the "old-style" quotes.  When the new-style quotes were added
to the reader (those that look like regular Lisp) it was natural to map

    `E  =>  (` E)

so that the existing definition of the ` macro worked both with the new
and with the old syntax.


        Stefan

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

Re: Improving aesthetics & readability of backquote

[Lars Ingebrigtsen]

"Paul W. Rankin" <hello@paulwrankin.com> writes:

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

I'm not sure this would really help much with comprehension --
especially the (splice b) thing.  That looks like a function call, but
modifies the structure of list of the parent sexp, which is quite
magical indeed.

,@b at least tells the reader "there may be something here that's odd",
which I think may help comprehension. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Improving aesthetics & readability of backquote

[Paul W. Rankin]

On Mon, May 20 2019, Alan Mackenzie wrote:
>> 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?

The \` symbol is an alias to backquote, and the word "backquote" 
only describes the symbol, i.e. circular semantics.

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

I'm using "readability" in the sense of reader comprehension, not 
eyestrain.

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

Hence the choice of clear, easily understandable aliases.

> I'm afraid I'm against such changes.

I'm proposing an addition, not changes. See the aforementioned rx 
library; its relationship to regular expression in Emacs Lisp 
should be instructive.

-- 
https://www.paulwrankin.com

Re: Improving aesthetics & readability of backquote

[Paul W. Rankin]

On Mon, May 20 2019, Lars Ingebrigtsen wrote:

> I'm not sure this would really help much with comprehension --
> especially the (splice b) thing.  That looks like a function 
> call, but
> modifies the structure of list of the parent sexp, which is 
> quite
> magical indeed.

All Emacs Lisp forms look like function calls.

> ,@b at least tells the reader "there may be something here 
> that's odd",
> which I think may help comprehension. 

Are you suggesting that ,@b is easier to comprehend than (splice 
b)? I think that is a hard case to make. Try to put yourself in 
the mindset of someone just learning Emacs Lisp.

-- 
https://www.paulwrankin.com

Re: Improving aesthetics & readability of backquote

[Basil L. Contovounesios]

"Paul W. Rankin" <hello@paulwrankin.com> writes:

> On Mon, May 20 2019, Lars Ingebrigtsen wrote:
>
>> I'm not sure this would really help much with comprehension --
>> especially the (splice b) thing.  That looks like a function call, but
>> modifies the structure of list of the parent sexp, which is quite
>> magical indeed.
>
> All Emacs Lisp forms look like function calls.
>
>> ,@b at least tells the reader "there may be something here that's odd",
>> which I think may help comprehension. 
>
> Are you suggesting that ,@b is easier to comprehend than (splice b)? I think
> that is a hard case to make. Try to put yourself in the mindset of someone just
> learning Emacs Lisp.

I think this is a subjective matter, so the question is, as you say in
your other message, whether aliases should be added for those that
prefer the latter form; not which form each person finds most readable.

Thanks,

-- 
Basil

Re: Improving aesthetics & readability of backquote

[Alan Mackenzie]

Hello, Paul.

On Mon, May 20, 2019 at 23:25:13 +1000, Paul W. Rankin wrote:

> On Mon, May 20 2019, Alan Mackenzie wrote:

> > Sorry, I can't make anything out of that paragraph.  What meaning?
> > What relation to what?  Which code alone?

> The \` symbol is an alias to backquote, and the word "backquote" 
> only describes the symbol, i.e. circular semantics.

OK, thanks.  "Backquote" partially describes what the operator does,
i.e. it quotes.  Sort of.

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

> I'm using "readability" in the sense of reader comprehension, not 
> eyestrain.

So was I.

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

The two are different.  Regexp strings, like

   "\\([{}();:,<]+\\)\\|^\\s *\\(#\\)\\s *define[ \t]+\\(\\sw\\|_\\)+\\([^(a-zA-Z0-9_]\\|$\\)"

are hard to read and decipher.  rx is an attempt to make it clearer to
read regexps.  On the contrary, ` and , and ,@ are easy to read, the
difficulty being in their semantics.

Back in the 1950s, the language Cobol was invented with just this
premise.  It was thought that

    ADD 2 TO X GIVING Y

would be easier for beginners (i.e. managers) to understand than

    Y = X + 2;

Language design has gone firmly in the opposite direction since then,
emphasising conciseness.

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

> Hence the choice of clear, easily understandable aliases.

I don't think they're easily understandable.  They lack the clarity and
distinctiveness of `, ,, and ,@.

> > I'm afraid I'm against such changes.

> I'm proposing an addition, not changes.

An addition is a change, and it would affect all project members.  As I
said, I'm against this change.

> See the aforementioned rx library; its relationship to regular
> expression in Emacs Lisp should be instructive.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Improving aesthetics & readability of backquote

[Paul W. Rankin]

On Mon, May 20 2019, Basil L. Contovounesios wrote:
>> Are you suggesting that ,@b is easier to comprehend than 
>> (splice b)? I think
>> that is a hard case to make. Try to put yourself in the mindset 
>> of someone just
>> learning Emacs Lisp.
>
> I think this is a subjective matter, so the question is, as you 
> say in
> your other message, whether aliases should be added for those 
> that
> prefer the latter form; not which form each person finds most 
> readable.

I've written a function that doubles a number x, but I'm thinking 
about what to call it...

    _||x&    or    (double x)

Jokes aside, yes I do think Emacs would benefit from an option for 
people to use a clearer syntax for lisp form interpolation.

Re: Improving aesthetics & readability of backquote

[Paul W. Rankin]

On Tue, May 21 2019, Alan Mackenzie wrote:
> An addition is a change, and it would affect all project 
> members.  As I
> said, I'm against this change.

I am pretty sure no one will force you to use it. And on the slim 
chance that something like this is implemented and there are any 
Emacs project members who read a form like this

    (quoteval (1 2 (unquote x) 4))

and do not either understand it immediately, or understand it 
seconds after doing a C-h o, can send their hatemail my way :)

Re: Improving aesthetics & readability of backquote

[Basil L. Contovounesios]

"Paul W. Rankin" <hello@paulwrankin.com> writes:

> On Mon, May 20 2019, Basil L. Contovounesios wrote:
>>> Are you suggesting that ,@b is easier to comprehend than (splice b)? I think
>>> that is a hard case to make. Try to put yourself in the mindset of someone
>>> just
>>> learning Emacs Lisp.
>>
>> I think this is a subjective matter, so the question is, as you say in
>> your other message, whether aliases should be added for those that
>> prefer the latter form; not which form each person finds most readable.
>
> I've written a function that doubles a number x, but I'm thinking about what to
> call it...
>
>    _||x&    or    (double x)
>
> Jokes aside, yes I do think Emacs would benefit from an option for people to use
> a clearer syntax for lisp form interpolation.

No objections from me.  My point was that the discussion should remain
focussed on the addition of such aliases, their implementation and
whether it's worth it, not about which form one finds more readable, as
that is a matter of personal taste.

-- 
Basil

Re: Improving aesthetics & readability of backquote

[Lars Ingebrigtsen]

"Paul W. Rankin" <hello@paulwrankin.com> writes:

> Are you suggesting that ,@b is easier to comprehend than (splice b)?

No.  But (splice b) looks like it's a normal form, but is
incomprehensible in how it works until you read the manual about it a
few times. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Improving aesthetics & readability of backquote

[Ken Olum]

There is a Lisp standard.  I think we should not get further from Common
Lisp by inventing new syntax, especially for low-level functionality
that isn't related to anything special about emacs.

I think the advantage of ` and , is that they allow the code that the
macro will produce to be clearly visible.  Thus

(defmacro 2+ (x)
  `(+ ,x 2))

looks a lot like

(defun 2+ (x)
  (+ x 2))

These two definitions do something very similar in terms of the effect
of the object being defined when it appears in code, so I think it's
good that they look similar.

(defmacro 2+ (x)
  (quoteval (+ (unquote x) 2)))

puts the focus on the operation of the macro expanding function, rather
than on the code that is generated, i.e., on how the macro works rather
than what it does.  I think it's better to see the resulting form more
clearly.

                                        Ken

Re: Improving aesthetics & readability of backquote

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Backquote is a well-known construct, a de-facto standard since over 40
years ago.  For a while, backquote in Emacs Lisp was incompatible with
the standard, because I was trying to keep the code small.  But in the
90s we changed Emacs Lisp to fit the standard.

To change it is unthinkable.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Improving aesthetics & readability of backquote

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Are you suggesting that ,@b is easier to comprehend than (splice b)?

  > No.  But (splice b) looks like it's a normal form, but is
  > incomprehensible in how it works until you read the manual about it a
  > few times. 

I feel the same.  ,@b is obviously something magic; people who don't
know what it does will look up what it means.

(splice b) looks like an expression, so people will assume it calls
the function 'splice', and get confused.  I think we should not
implement that alias.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Improving aesthetics & readability of backquote

[Paul W. Rankin]

On Tue, May 21 2019, Richard Stallman wrote:
> Backquote is a well-known construct, a de-facto standard since 
> over 40
> years ago.  For a while, backquote in Emacs Lisp was 
> incompatible with
> the standard, because I was trying to keep the code small.  But 
> in the
> 90s we changed Emacs Lisp to fit the standard.
>
> To change it is unthinkable.

I'm not suggesting to change it, in the sense I take that you mean 
as unthinkable, i.e. that change means doing away with the 
existing implementation. I'm only suggesting to give people 
(particularly those new to Emacs) the freedom to choose a more 
literal syntax that fits with the aesthetics of the surrounding 
code.

This is not dissimilar to the aforementioned rx library. Like the 
backquote construct, regular expression is an efficient but 
cryptic syntax, and rx gives people the freedom to choose a more 
literal syntax (which also fits with the aesthetics of the 
surrounding code) if they find the real syntax too cryptic and 
scary. They can use it like training wheels before switching to 
the real syntax (which was my introduction to regular 
expressions). This is all I'm suggesting -- free software giving 
people freedom, rather than adhering to the preferences of someone 
40 years ago.

Given that at least annually there's a huge thread on the mailing 
list or elsewhere about how Emacs is fading into irrelevance (!) 
and the dire need to attract more users (!), I think it's 
worthwhile really trying to look at things from the perspective of 
new users -- backquote may well be a 40-year-old standard, but 
before learning Emacs Lisp, I'd never heard of it, and I assume 
most people are the same.

-- 
https://www.paulwrankin.com

Re: Improving aesthetics & readability of backquote

[Noam Postavsky]

On Mon, 20 May 2019 at 22:06, Paul W. Rankin <hello@paulwrankin.com> wrote:

> On Tue, May 21 2019, Richard Stallman wrote:
>> Backquote is a well-known construct, a de-facto standard since over
>> 40 years ago.

> backquote may well be a 40-year-old standard,

The standard is about the read syntax; at least, Common Lisp
explicitly says it is implementation dependent what the result of
(read "`(foo ,bar)") is.
For Emacs, that currently gives (\` (foo (\, bar))), I think it would
be nicer if it gave (quasiquote (foo (unqote bar)). From what I can
tell this has been standard in Scheme since r3rs (1986).

Re: Improving aesthetics & readability of backquote

[Paul W. Rankin]

On Tue, May 21 2019, Richard Stallman wrote:

> ,@b is obviously something magic; people who don't know what it 
> does will look up what it means.
>
> (splice b) looks like an expression, so people will assume it 
> calls the function 'splice', and get confused. I think we should 
> not implement that alias.

I think it would be a worthwhile experiment to run this theory by 
a non-programmer, or a non-Lisp programmer, because this is just 
not how people think. This distinction between "expression" and 
"function" and "construct"... people who haven't spent most of 
their lives programming Lisp just don't think in those terms. 
Instead we think of the first element inside parentheses as "this 
does a thing". We look at something like the above and think 
"splice does a thing". The notion that confusion will arise 
because (splice b) can only be called within a (quoteval ...), and 
that this confusion will supersede the confusion of "what the heck 
is ,@b??" is just not realistic.

And there are many times when the first element inside parentheses 
actually does *not* do a thing, e.g.

    (let ((a 1) (b 2)) ...)    ;; a and b don't do things

    (dolist (var list) ...)    ;; var doesn't do a thing

But "quoteval", "unquote" and "splice" are just suggestions based 
on the backquote documentation. If these suggestions are too 
troubling, maybe divide this into two parts: 1. the backquote 
syntax is ugly and hard to understand, and 2. here's a way it 
could be better. Feel free to discard 2.

-- 
https://www.paulwrankin.com

Re: Improving aesthetics & readability of backquote

[Paul W. Rankin]

On Tue, May 21 2019, Noam Postavsky wrote:
> The standard is about the read syntax; at least, Common Lisp
> explicitly says it is implementation dependent what the result 
> of
> (read "`(foo ,bar)") is.
> For Emacs, that currently gives (\` (foo (\, bar))), I think it 
> would
> be nicer if it gave (quasiquote (foo (unqote bar)). From what I 
> can
> tell this has been standard in Scheme since r3rs (1986).

Hehe I like "quasiquote".

Re: Improving aesthetics & readability of backquote

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm only suggesting to give people 
  > (particularly those new to Emacs) the freedom to choose a more 
  > literal syntax that fits with the aesthetics of the surrounding 
  > code.

We must not do that.  That would lead to such usage creeping into Lisp
code.

I don't believe this syntax would help people learn Lisp.  If you have
some hard evidence, that might convince me, but I think you are
simply speculating.

It seems impossible that changes in Emacs Lisp would convince people
to start editing with Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Improving aesthetics & readability of backquote

[Paul W. Rankin]

On Wed, May 22 2019, Richard Stallman wrote:

>   > I'm only suggesting to give people
>   > (particularly those new to Emacs) the freedom to choose a 
>   > more
>   > literal syntax that fits with the aesthetics of the 
>   > surrounding
>   > code.
>
> We must not do that.  That would lead to such usage creeping 
> into Lisp
> code.
>
> I don't believe this syntax would help people learn Lisp.  If 
> you have
> some hard evidence, that might convince me, but I think you are
> simply speculating.
>
> It seems impossible that changes in Emacs Lisp would convince 
> people
> to start editing with Emacs.

Well call Ripley's because here I am presenting my hard evidence 
by way of recounting that this was exactly my experience in 
learning Emacs Lisp.

I worked my way through the Emacs Lisp Intro manual, then started 
thumbing through the Elisp manual piecemeal. When I reached the 
backquote section, my reaction was "why doesn't this syntax match 
the Elisp syntax I've already learnt?" followed by "this must be 
for programmers to add bits of more complex languages like C, and 
D and E" (because I had no idea what C looked like). So I put it 
in the too-hard basket and just did my best without it.

So yes, making the backquote line noise make more sense would have 
its benefits.

This may make me sound like an outlier, but in releasing Elisp 
packages aimed at non-programmers, I've come into contact with 
many Emacs users with little or no familiarity with code.

In the recent mailing list thread (cited in my first email), both 
Eli and Stefan urged people to request features in Emacs when they 
found the existing Emacs capabilities insufficient:

Eli:

> But requesting a feature in addition to that does two things: 
> (a) it alerts others, including Emacs developers, to the need; 
> and (b) it announces load and clear that the package maintainer 
> is not really happy with the current solution. Without such a 
> request, no one will even know that there's a problem here 
> waiting for a volunteer.

Stefan:

> All Eli is saying is: when the Emacs infrastructure isn't as 
> good as
> you'd like for your package, please report it as a bug (no need 
> to do
> anything more than that).  That doesn't mean we'll necessarily 
> fix those
> bugs (sometimes they're hard to fix, or simply nobody is 
> interested in
> fixing them), but it helps to know about them, and can guide
> future redesigns.

This is all I'm doing. And what I'm suggesting is not without 
precedent; I've already cited the rx library, but for something 
more prevalent:

    (if COND nil ELSE)
    ->
    (unless COND THEN)

Clearly the macro unless was introduced to make Elisp more 
readable and more aesthetically pleasing; Emacs seemed to have 
survived the resultant waves of confusion and bloody factioning.

A few replies have continued with an equivocation of "change" and 
"addition". I am *not* suggesting a change to the existing syntax, 
I'm suggesting an addition. If you have an apple, and I give you 
an orange, the addition of this orange does not change your apple 
-- you still have your apple! Your life with your apple may 
continue on unabated, and my preference for oranges does not in 
any way affect your ability to eat apples. I think what 
programmers tend to believe is that if they prefer apples, then 
everyone should eat apples.

Re: Improving aesthetics & readability of backquote

[Eli Zaretskii]

> From: "Paul W. Rankin" <hello@paulwrankin.com>
> Date: Wed, 22 May 2019 12:46:49 +1000
> Cc: emacs-devel@gnu.org
> 
> In the recent mailing list thread (cited in my first email), both 
> Eli and Stefan urged people to request features in Emacs when they 
> found the existing Emacs capabilities insufficient:

I think there might be some over-reaction here.  No one reprimanded
you for bringing up this suggestion.  What happened is that Richard
expressed his opinion about the suggested feature, that's all.  I'm
sure you will agree that some suggestions which Stefan and myself
solicited will cause objections and disagreements.  That's entirely
normal and should be expected.

Let's continue discussing this issue until we understand the balance
of the different opinions about your proposal.

Re: Improving aesthetics & readability of backquote

[Paul W. Rankin]

On Wed, May 22 2019, Eli Zaretskii wrote:
> I think there might be some over-reaction here.  No one reprimanded
> you for bringing up this suggestion.  What happened is that Richard
> expressed his opinion about the suggested feature, that's all.  I'm
> sure you will agree that some suggestions which Stefan and myself
> solicited will cause objections and disagreements.  That's entirely
> normal and should be expected.
>
> Let's continue discussing this issue until we understand the balance
> of the different opinions about your proposal.


            Emacs, a play by Bertolt Brecht
            -------------------------------

Emacs:  Please proffer your suggestions on how Emacs could be
        improved, for we wish to attract new users!

Me:     As a comparatively new user, I remember when learning Emacs
        I found this part ugly and confusing. Here is a suggestion
        from such a perspective on how it could be improved.

Emacs:  It seems impossible that a new user would find that part
        ugly or confusing. It is unthinkable that it would be
        improved.

                    ~ fin ~


Thanks for the response. Please don't consider this as my proposal, I
don't really want to keep debating whether I found something
ugly/confusing or not. It's just a thing left in the Emacs Suggestion
Box. Do with what you will.

Re: Improving aesthetics & readability of backquote

[Stefan Monnier]

> is complemented by
>
>     `E  =>  (quasiquote E)
>     ,E  =>  (unquote E)
>     ,@E =>  (unquote-splicing E)
>
> Elisp doesn't have that, mostly for historical reasons, I think.

To clarify, Elisp doesn't have exactly the above, but it does have:

    `E  =>  (\` E)
    ,E  =>  (\, E)
    ,@E =>  (\,@ E)

so you *can* write them in "normal Lisp parenthesized syntax".
It's just that this syntax doesn't use English words to carry an
intended semantics.

Regarding adding alternate names, there are two separate aspects:
- What should the reader return: changes there (e.g. making it return
  the same as Scheme does, for example) are hard to justify because the
  gain is not great but it introduces backward-incompatible changes, and
  will inevitably break existing packages.
- Allow Elisp code to use alternate names.  This is already allowed
  when it comes to `E which can be written (backquote E).  A simple
  (defalias 'quasiquote #'backquote) would also add the traditional
  Scheme name if we want it.  That's easy and safe.
  Extending this to (unquote E) and (unquote-splicing E) is more
  problematic because that would be a backward-incompatible change.
  Currently `(unquote (+ 1 2)) returns (unquote (+ 1 2)) this would
  change it to return 3.  I'm not 100% it would break existing packages
  (contrary to the previous point), but the risk is still pretty high
  and the payoff rather small.
  
IOW, I think the "core Elisp" support for `E and ,E is unlikely to change
because even if there might be a benefit, it's likely not high enough to
justify the pain inflicted by the change itself.

OTOH we could define a new `quasiquote` macro which does the same as
`backquote` except that it additionally accepts (unquote E) and
(unquote-splicing E) as replacements for ,E and ,@E.  That can easily be
done even in a GNU ELPA package and doesn't risk breaking existing code.
Not sure such you'd find such a "2nd rate citizen" solution very
convincing, tho.


        Stefan

Re: Improving aesthetics & readability of backquote

[Michael Heerdegen]

"Paul W. Rankin" <hello@paulwrankin.com> writes:

> Me:     As a comparatively new user, I remember when learning Emacs
>         I found this part ugly and confusing. Here is a suggestion
>         from such a perspective on how it could be improved.

Most people participating here have learned Lisp long time ago, so they
probably don't remember how it was.

I'm quite sure that ` and , are indeed ugly, make Lisp more complicated
and harder to learn.  But they have a huge advantage that more than
outweighs all of that: they make complex list constructions much better
readable.  But only after one got used to them.  Once you did get used
to this syntax, it's invaluable.

My personal opinion is that learners need to get used to it.  I'm not
convinced allowing a different simpler syntax would be beneficial: it
would complicate things and maybe keep newbies from learning a lesson
they would need to learn anyway.


Michael.

Re: Improving aesthetics & readability of backquote

[Michael Heerdegen]

"Paul W. Rankin" <hello@paulwrankin.com> writes:

>             Emacs, a play by Bertolt Brecht
>             -------------------------------
>
> Emacs:  Please proffer your suggestions on how Emacs could be
>         improved, for we wish to attract new users!
>
> Me:     As a comparatively new user, I remember when learning Emacs
>         I found this part ugly and confusing. Here is a suggestion
>         from such a perspective on how it could be improved.
>
> Emacs:  It seems impossible that a new user would find that part
>         ugly or confusing. It is unthinkable that it would be
>         improved.
>

BTW, that's just the dry and direct tone that is common here.  That
happens to all of us.  It doesn't mean that your opinion is not
respected or considered.


Michael.

Re: Improving aesthetics & readability of backquote

[조성빈]

2019. 5. 23. 오전 12:57, Michael Heerdegen <michael_heerdegen@web.de> 작성:

> "Paul W. Rankin" <hello@paulwrankin.com> writes:
> 
>> Me:     As a comparatively new user, I remember when learning Emacs
>>        I found this part ugly and confusing. Here is a suggestion
>>        from such a perspective on how it could be improved.
> 
> Most people participating here have learned Lisp long time ago, so they
> probably don't remember how it was.

I learned Common Lisp about a year ago, and is teaching my friend CL. I learned Elisp a bit later, because I tried to customize my Emacs (which I started to use because of SLIME).
I think it’s pretty fair for me to say about beginner experiences.

> I'm quite sure that ` and , are indeed ugly, make Lisp more complicated
> and harder to learn.  But they have a huge advantage that more than
> outweighs all of that: they make complex list constructions much better
> readable.  But only after one got used to them.  Once you did get used
> to this syntax, it's invaluable.

I would say, it is indeed ugly; but it wasn’t a pain point. That’s not something begginers would say it’s complicated or harder to learn.
And, it allows beginners to gripe what ‘macro’ is, because it’s similar enough with real code to show that macros generate ‘code’ and different enough with real code to show that macros ‘generate’ code.
I immediately understood what macros do by just looking at the backquote, and my friend is having a similar experience.

> My personal opinion is that learners need to get used to it.  I'm not
> convinced allowing a different simpler syntax would be beneficial: it
> would complicate things and maybe keep newbies from learning a lesson
> they would need to learn anyway.
> 
> 
> Michael.
> 

Re: Improving aesthetics & readability of backquote

[Sam Steingold]

> * Paul W. Rankin <uryyb@cnhyjenaxva.pbz> [2019-05-20 13:03:21 +1000]:
>
> 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.

Backquote is a relatively advanced lisp feature, mostly used in macros
(which comprise a whole separate advanced domain).
If you find backquote "ugly and unreadable", it is possible that you
might not be quite advanced in your lisp skills yet.
Do you really _need_ backquote? Do you write complex macros all the time?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1671
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
http://memri.org http://americancensorship.org http://think-israel.org
When the building is on fire, evacuate it before twitting about it.

Re: Improving aesthetics & readability of backquote

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Emacs:  It seems impossible that a new user would find that part
  >         ugly or confusing. It is unthinkable that it would be
  >         improved.

What I actually said was consistent and rational.  You have altered it
into something I did not say.

However, the main point is that there is a limit to how much time we
can spend explaining decisions to you.  If you don't convince us, at
some point you'll just have to accept that.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)