Subject: Re: Which ones come first? - Macro question -
From: rpw3@rpw3.org (Rob Warnock)
Date: Tue, 02 Sep 2008 07:51:31 -0500
Newsgroups: comp.lang.lisp
Message-ID: <F_ydnREZ5s5OqyDVnZ2dnUVZ_rmdnZ2d@speakeasy.net>
Dan Weinreb <dlw@alum.mit.edu> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) wrote:
| > Unlike the Scheme standard, which specifies a specific reader
| > transformation to be used for backquote & friends:
| >   `form ==> (quasiquote form)
| >   ,form ==> (unquote form)
| >   ,@form ==> (unquote-splicing form)
| > the CLHS does not:
| >   2.4.6 Backquote
| >   ...
| >   An implementation is free to interpret a backquoted form F1 as
| >   any form F2 that, when evaluated, will produce a result that is
| >   the same under equal as the result implied by the above definition...
...
| > You have been warned! ;-}
| 
| Way back when, I didn't see any problem with putting things like that
| into the spec.  Now, I wonder whether giving all the implementors such
| flexibility is worth the possible cost in incompatible or inconsistent
| behavior between implementations.
+---------------

The biggest problem I've seen with it is that it pretty much precludes
doing a "CLsh" (a "Common Lisp Shell") that would work *exactly* the
same way that "Scsh" <http://www.scsh.net/> does, for two reasons:

1. Since in Scheme QUASIQUOTE is a macro [well, in R4RS it's called
   "essential syntax", but it's almost always implemented as a macro],
   it's possible to have *other* macros that perform "implicit
   quasiquotation" and thus can be defined to use comma (UNQUOTE)
   and comma-at (UNQUOTE-SPLICING) for their own purposes. Common
   Lisp, however, forbids any use of comma or comma-at not inside
   a backquoted form, and there's no (standard-defined) way for any
   "implicitly quasiquotating" macro to suppress the error check in
   the reader.

   This isn't a *total* killer, if one is willing to bend the Scsh
   syntax a bit [which one will *anyway*, since a "CLsh" would be
   using CL syntax, not Scheme]. Then one can (somewhat clumsily)
   work around the issue. That is, instead of the following, which is
   legal Scsh [RUN is a macro which performs "implicit quasiquoting"]:

       (run (ls ,@flags ,dir))

    to make it legal CL one would have to type this [mutatis mutandis
    in the definition of RUN]:

       (run `(ls ,@flags ,dir))

2. Since "an implementation is free to interpret a backquoted form" in
   many different ways, macros such as RUN above aren't guaranteed to be
   able to predict what the reader expanded a backquoted argument form
   into, and thus may have trouble performing its tree-walk. Even worse,
   in some (many?) cases the backquote/comma/comma-at (sub)forms will have
   disappeared *entirely* by the time a macro such as RUN sees the input
   [re-written into LIST/LIST*/CONS/etc. instead of LISP::BACKQ-LIST/
   LISP::BACKQ-CONS/LISP::BACKQ-APPEND/etc.], significantly raising the
   number of patterns the macro has to able to match.

   I haven't actually tried to work out a significant subset of Scsh
   in CL to see yet, but I suspect that even this isn't a total killer,
   either, as one can imagine a common library routine with some
   implementation-specific feature tests that attempts to "back-convert"
   the macro's arguments into some standard (Scheme-like?) form, said
   library routine being called by CLsh macros to "normalize" backquoted
   forms. But even if it's possible, it would certainly add a large pile
   of complexity.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607