[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