emacs-devel
[Top][All Lists]
Advanced

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

Re: Double unquote/unquote-splicing


From: Nathan Trapuzzano
Subject: Re: Double unquote/unquote-splicing
Date: Mon, 04 Nov 2013 14:09:11 -0500
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> This is incorrect.  ``(a ,,@x) where x=(1 2 3) would evaluate to
>> (\` (a (\, 1) (\, 2) (\, 3))).  The first comma in ,,@ has the effect of
>> being applied member-wise to each element spliced out of ,@.  Cf. CLHS
>> `Backquote' 
>> (http://www.lispworks.com/documentation/HyperSpec/Body/02_df.htm).
>
> This is even worse since it means that the expansion of ,@foo depends on
> the context.

Not necessarily.  As I said, you could simply define \, and \,@ with
more than one argument to behave the same as a series of \, or \,@s with
one argument.

In fact, I just built from trunk with two lines of code from
backquote.el changed (using your helpful comments), and it seems to work
precisely like that.  In other words, this doesn't seem to require any
extra work.

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

On second thought, that quote doesn't really support my argument.  It's
rather neutral.

However, the fact is that nested backquotes _are_ for wizards.  The
problem is, Emacs' nested backquotes aren't fully functional, the result
being that the code is harder for us non-wizards to read.

In summary, this change would

1. break nothing,
2. require virtually no work to be done,
3. render macro-writing macros easier to read and write; and
4. bring Elisp behavior right in line with CL and Scheme.

Even if you disagree with (3), this seems like a win all around.



reply via email to

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