Peter Seibel <peter@gigamonkeys.com> wrote:
+---------------
| Kent M Pitman <pitman@nhplace.com> writes:
| > "Jason" <jasonkantz@gmail.com> writes:
| >> Seems like `,foo should have a standard mapping to a list structure
| >> just as `foo does.
| >
| > Implementations are allowed to optimize this stuff differently.
| > You aren't supposed to write programs that care. What program
| > are you wishing you could write?
|
| I'm not the OP but I once went down the path, while writing a matched
| pair of interpreter/compiler for a domain specific language, of
| wishing that I could define code-templates using backquote
| syntax and then analyze the resulting s-exprs to generate slightly
| different code in the interpreter and compiler. But because you can't
| do that I found a completely different way to slice up my problem so I
| don't know if there would have been some other problem with that
| approach. But it seemed if `(foo ,bar ,@baz) was just sugar for
| something like Scheme's (quasiquote (foo (unquote bar)
| (unquote-splicing baz))) I could have done what I wanted pretty easily.
+---------------
I once ran into the same thing while trying to port a pidgin version
of Olin Shiver's "Scsh" notation into CL. The problem is that much of
Scsh internally depends on Scheme's standard reader parsing of backquote
as QUASIQUOTE, comma as UNQUOTE, and comma-at as UNQUOTE-SPLICING,
even if not properly nested. That is, statements in Scsh are (usually)
"implicitly backquoted", and thus the following might be the "natural"
way to write a common function in CLsh [if the latter existed]:
(loop for i in (directory "foo")
do (clsh (ls -l ,i)))
As it is, most CL readers complain vociferously about "excess" commas
or comma-at's, so one would have to write it this way:
(loop for i in (directory "foo")
do (clsh `(ls -l ,i)))
Not a *big* difference you might say, but in practice it's fairly
annoying if you're trying to use Scsh/CLsh as your top-level shell.
Plus, sometimes the reader so "optimizes" the backquoted expression
for you before you get your hands on it that you can't uniquely recover
what the user typed to produce the S-expr result READ gave you.
Finally, a (hypothetical) CLsh has to have to have a massive set of
feature tests to conditionalize the post-READ (un)parsing of Scsh-like
forms, variantions that might change radically between releases of
each supported CL implementation.
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607