emacs-devel
[Top][All Lists]
Advanced

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

Re: Improving aesthetics & readability of backquote


From: Stefan Monnier
Subject: Re: Improving aesthetics & readability of backquote
Date: Wed, 22 May 2019 11:44:11 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> 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




reply via email to

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