Re: Double unquote/unquote-splicing

["Stephen J. Turnbull" <stephen@xemacs.org>]

Nathan Trapuzzano writes:

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

Like Stefan, I couldn't understand what your example is supposed to do
*without reading the expansion*.  That I do understand, though it took
some head-scratching.

"It's pretty, so it must be right" is a fallacy.  The temptation to
write what really should be a cond with a large number of exceptional
cases as a backquote construct looping over applications of a general
function is probably not good for Emacs.  Emacs is about user
interface: its beauty mostly is, and generally should be, "skin deep".

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

AFAICS, (1) hasn't been properly checked, and one can also disagree
with (4), as phrased.  There will still be plenty of differences in
behavior.  Only nested backquotes (an infrequently used facility) will
be synchronized.

Note also that "powerful" (== expressive) syntax is not necessarily
*efficient* syntax.  This is especially so for Emacs Lisp.

I don't really see why people want to write wizardly code in Emacs
Lisp.  Why not use a language designed for that purpose instead?

Emacs Lisp is a slow implementation (though with lexical scope it can
get a lot faster, it is unlikely to approach the performance of
well-tuned Common Lisp implementations, let alone the faster Scheme
implementations) with idiosyncratic, unstandardized semantics that
change at the whim of the maintainers.  This doesn't matter much in
its primary role as a user interface (nothing in the computing
environment is as slow as the user ;-).  But UIs are typically a
matter of attention to detail and context, rather than complex
algorithms.

I'm not really against this, but if it makes Stefan uneasy, I'll side
with Stefan's ambiguous intuition against the rather tenuous claims in
favor.