From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>,
Nathan Trapuzzano <nbtrap@nbtrap.com>
Cc: emacs-devel@gnu.org
Subject: RE: Double unquote/unquote-splicing
Date: Mon, 4 Nov 2013 11:01:19 -0800 (PST) [thread overview]
Message-ID: <d87fddde-4f04-4487-9d88-eb42a16d8253@default> (raw)
In-Reply-To: <jwvfvrcja45.fsf-monnier+emacs@gnu.org>
> > "The backquote syntax was particularly powerful when nested. This
> > occurred primarily within macro-defining macros; because such were
> > coded primarily by wizards, the ability to write and interpret nested
> > backquote expressions was soon surrounded by a certain mystique.
> > Alan Bawden of MIT acquired a particular reputation as backquote-
> > meister in the early days of the Lisp Machine." - "The Evolution of
> > Lisp", Gabriel, Steele.
>
> That sounds about right: it's only for wizards.
No, that is exactly backwards. Please note: "The backquote syntax was
__particularly powerful when nested__." That's about power simplifying
understanding by humans.
Read the article for explanation and good examples. The point of that
passage is that _without_ backquote syntax the kinds of things you can
do using nested backquotes are *really* complicated without them. The
point is that backquote syntax is _especially_ good at simplifying in
the case of nested backquotes.
What is for wizards is the need to write code of this kind: the kinds
of things that nested backquotes simplify. Those use cases are not so
common, but if you have such a use case then you _really_ want to have
nested backquote syntax. That's the point of the quoted passage.
The full article is here:
http://extravagaria.com/Files/HOPL2-Uncut.pdf
> Nested backquotes were largely broken in Elisp and it took many
> years for someone to notice. I do use them occasionally, but only in
> fairly simple ways. The resulting code is largely impenetrable, so
> I don't want to encourage it.
Nested backquote syntax should be neither encouraged nor discouraged.
The point is that compared to the alternative it is a lot simpler.
next prev parent reply other threads:[~2013-11-04 19:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 14:03 Double unquote/unquote-splicing Nathan Trapuzzano
2013-11-04 17:27 ` Stefan Monnier
2013-11-04 17:59 ` Nathan Trapuzzano
2013-11-04 18:11 ` Nathan Trapuzzano
2013-11-04 18:33 ` Stefan Monnier
2013-11-04 19:01 ` Drew Adams [this message]
2013-11-04 19:09 ` Nathan Trapuzzano
2013-11-04 20:41 ` Stefan Monnier
2013-11-05 15:03 ` Nathan Trapuzzano
2013-11-05 19:14 ` Stefan Monnier
2013-11-05 4:01 ` Stephen J. Turnbull
2013-11-05 15:22 ` Nathan Trapuzzano
2013-11-05 21:48 ` Stephen J. Turnbull
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d87fddde-4f04-4487-9d88-eb42a16d8253@default \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=nbtrap@nbtrap.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.