From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: Improving aesthetics & readability of backquote
Date: Wed, 22 May 2019 11:44:11 -0400 [thread overview]
Message-ID: <jwvv9y28q67.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: jwv36l9ztzd.fsf-monnier+emacs@gnu.org
> 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
next prev parent reply other threads:[~2019-05-22 15:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 3:03 Improving aesthetics & readability of backquote Paul W. Rankin
2019-05-20 3:38 ` Stefan Monnier
2019-05-22 15:44 ` Stefan Monnier [this message]
2019-05-20 8:52 ` Alan Mackenzie
2019-05-20 13:25 ` Paul W. Rankin
2019-05-20 14:02 ` Alan Mackenzie
2019-05-20 14:26 ` Paul W. Rankin
2019-05-20 16:08 ` Ken Olum
2019-05-20 23:19 ` Richard Stallman
2019-05-21 2:06 ` Paul W. Rankin
2019-05-21 2:22 ` Noam Postavsky
2019-05-21 2:39 ` Paul W. Rankin
2019-05-21 20:19 ` Richard Stallman
2019-05-22 2:46 ` Paul W. Rankin
2019-05-22 7:56 ` Eli Zaretskii
2019-05-22 8:55 ` Paul W. Rankin
2019-05-22 15:57 ` Michael Heerdegen
2019-05-22 16:13 ` 조성빈
2019-05-22 16:13 ` Michael Heerdegen
2019-05-22 22:40 ` Richard Stallman
2019-05-20 8:59 ` Lars Ingebrigtsen
2019-05-20 13:35 ` Paul W. Rankin
2019-05-20 13:47 ` Basil L. Contovounesios
2019-05-20 14:18 ` Paul W. Rankin
2019-05-20 14:48 ` Basil L. Contovounesios
2019-05-20 15:25 ` Lars Ingebrigtsen
2019-05-20 23:21 ` Richard Stallman
2019-05-21 2:34 ` Paul W. Rankin
2019-05-22 16:14 ` Sam Steingold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvv9y28q67.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).