This is an issue with the tools, not a fundamental one.

If I do a slime-macroexpand-1 on (define-source-transform sb!impl::sort-vector) the result looks nice - preserving triply-nested backquotes. The same can not be said of the previous implementation.  macroexpand-all looks ugly, I'll agree with you there.

What I find interesting is that CLISP does what you want, which suggests to me that its backend for Slime has been hacked to understand that their SYSTEM:BACKQUOTE macro should not expand when nested inside another for purposes of pretty output.  The macro has the same property as SB-INT:QUASIQUOTE- it must turn into a form involving list constructors.
I haven't looked at the swank CLISP code, but either it is expanding and then reverse-engineering - a suboptimal technique for sure, one which defeats the point of their abstract tree representation of BACKQUOTE/COMMA, or just not expanding nested backquotes in the implementation of macroexpand-all.

We should do something similar perhaps.

Also, I think it's slightly ironic to ask that macroexpand-1 at toplevel not expand, so your first few examples are not quite as compelling to me as the use-case with Slime.



On Fri, Aug 1, 2014 at 4:59 PM, James M. Lawrence <llmjjmll@gmail.com> wrote:
CL-USER> (macroexpand-1 '`(foo ,x))
(SB-IMPL::|List| 'FOO X)

CL-USER> (macroexpand-1 '``(foo ,,x))
(SB-IMPL::|List| 'SB-INT:QUASIQUOTE (SB-IMPL::|List| 'FOO (SB-IMPL::UNQUOTE X)))

Code that contains backquotes now macroexpands into a mess of
SB-IMPL::|List|s and SB-IMPL::|List*|s, reminiscent of CCL's
treatment of backquotes. If the new behavior is expected (which it
appears to be), it seems rather unfortunate to work so hard at pretty
printing only to throw it away upon macroexpansion.

Having readable macroexpanded code is a big advantage when writing
complex macros. Each of us could presumably cite examples of macros
that would be difficult to write without comprehensible macroexpansion
output available. I have cases which would have been practically
infeasible.

Unless there is some way to fix this (seems not, short of going back
to the old backquote technique), a workaround might be to write
pretty-macroexpand-1, pretty-macroexpand, and pretty-macroexpand-all,
and then have SLIME and other environments use that instead.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel