I'm a bit disturbed by the nonportability of an unevaluated backquoted
form. CLtL/II, on page 528, says: "An implementation is quite free to
interpret backquote in any way such that a backquoted form, when
evaluated, will produce a result EQUAL to that produced by the
interpretation shown here." This implies that on seeing a backquoted
form, the Common Lisp reader might generate virtually *anything*--from
an expression that invokes an implementation-dependent function,
macro, or special form, all the way to an object of some nonstandard,
implementation-dependent type--which happens to evaluate to the
correct result. Thus, any code that sees the unevaluated backquoted
form--e.g., a macro that receives it as an argument--must be prepared
for *anything*. Moreover, there is no guaranteed way to convert the
backquoted form into a portable equivalent that uses LIST or APPEND.
So, for example, a macro that behaves differently according to whether
its (unevaluated) argument is a cons or an atom, may or may not
consider a backquoted argument to be a cons. Or, if the macro writes
its argument out to a file, that file may or may not be readable by
the same or any other Common Lisp implementation. Is my
interpretation of CLtL/II correct?
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
In article <·················@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
>I'm a bit disturbed by the nonportability of an unevaluated backquoted
>form. CLtL/II, on page 528, says: "An implementation is quite free to
>interpret backquote in any way such that a backquoted form, when
>evaluated, will produce a result EQUAL to that produced by the
>interpretation shown here." This implies that on seeing a backquoted
>form, the Common Lisp reader might generate virtually *anything*--from
>an expression that invokes an implementation-dependent function,
>macro, or special form, all the way to an object of some nonstandard,
>implementation-dependent type--which happens to evaluate to the
>correct result.
True. For example, in Lucid and Allegro:
> (setq w 23)
23
> '`(,w)
(LUCID-RUNTIME-SUPPORT:BQ-LIST W)
<cl> (setq w 23)
23
<cl> '`(,w)
`(,W)
<cl> (car *)
EXCL::BACKQUOTE
<cl> (cdr **)
((,W))
<cl> (caar *)
,W
<cl> (car *)
EXCL::BQ-COMMA
Allegro does this so that the printed representation of a backquoted form
will print readably.
> Moreover, there is no guaranteed way to convert the
>backquoted form into a portable equivalent that uses LIST or APPEND.
Not correct. Portable implementations do exist. You could always write
your own and use that if you wanted guarranteed portability.
>So, for example, a macro that behaves differently according to whether
>its (unevaluated) argument is a cons or an atom, may or may not
>consider a backquoted argument to be a cons. Or, if the macro writes
>its argument out to a file, that file may or may not be readable by
>the same or any other Common Lisp implementation. Is my
>interpretation of CLtL/II correct?
I can't see, offhand, any application for a quoted backquoted
expression which absolutely needed to quote the backquoted expression.
Do you have a real example where this is a problem?
--mark
In article <······················@cs.cmu.edu> ······@cs.cmu.edu (Mark Kantrowitz) writes:
From: ······@cs.cmu.edu (Mark Kantrowitz)
Date: Wed, 22 Apr 92 02:14:21 GMT
In article <·················@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
>I'm a bit disturbed by the nonportability of an unevaluated backquoted
>form. CLtL/II, on page 528, says: "An implementation is quite free to
>interpret backquote in any way such that a backquoted form, when
>evaluated, will produce a result EQUAL to that produced by the
>interpretation shown here." This implies that on seeing a backquoted
>form, the Common Lisp reader might generate virtually *anything*--from
>an expression that invokes an implementation-dependent function,
>macro, or special form, all the way to an object of some nonstandard,
>implementation-dependent type--which happens to evaluate to the
>correct result.
True. For example, in Lucid and Allegro:
Correct. Note, however, that in many implementations, macroexpanding
it recursively to all levels will fix it to be portable.
Not Lucid, unfortunately; I didn't check Allegro. But as
you note, with Allegro, it will print with backquote.
Lucid will also print with backquote if you set *print-pretty*.
In fact, I bet all implementations will produce something
portable if you set *print-pretty*. Either they turn directly
into list/list*/append/nconc, or they turn into BQ versions
of the those functions, and print back out using backquote
syntax, which *is* portable.
Unfortunately, this isn't guarenteed by the standard. But
it's a good bet. There's no reason for an implementation to
expand backquote into something non-portable, unless it's
to enable printing back out as backquote.
>So, for example, a macro that behaves differently according to whether
>its (unevaluated) argument is a cons or an atom, may or may not
>consider a backquoted argument to be a cons. Or, if the macro writes
>its argument out to a file, that file may or may not be readable by
>the same or any other Common Lisp implementation. Is my
>interpretation of CLtL/II correct?
I can't see, offhand, any application for a quoted backquoted
expression which absolutely needed to quote the backquoted expression.
Do you have a real example where this is a problem?
The whole problem goes away if, instead of putting backquoted
code out to a file, you produce a macro call that in turn expands
into the backquoted code. The macro would be part of the base system.
If what you're producing isn't arbitrary, this will give you better
modularity.
In article <······················@cs.cmu.edu> ······@cs.cmu.edu (Mark Kantrowitz) writes:
In article <·················@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
> Moreover, there is no guaranteed way to convert the
>backquoted form into a portable equivalent that uses LIST or APPEND.
Not correct. Portable implementations do exist. You could always write
your own and use that if you wanted guarranteed portability.
What I meant was that, given an unevaluated backquote form (using the
backquote definition supplied by the implementation), there is no
fully portable way of converting that form into an equivalent portable
form.
I realize that one solution is to define our own, portable backquote.
I can't see, offhand, any application for a quoted backquoted
expression which absolutely needed to quote the backquoted expression.
Do you have a real example where this is a problem?
We have hit two real-life examples:
- The argument to a function FUNC is usually a list generated on the
spot via a backquote. For example, a programmer might write
(FUNC `(:A ,A :B ,B))
A compiler macro would like to detect and optimize this very common
case, but it cannot because it has no portable way of detecting that
it was passed a backquoted form.
- A program Progr wants to store a form for evaluation at another time
place, or platform. On most implementations, WRITE and READ (perhaps
with *PRINT-PRETTY* set to T) will handle backquote reasonably; but
Progr employs its own specialized writer and reader, for efficiency
reasons. This writer and reader can handle almost any portable
construct--but a backquoted form doesn't meet the portability
criterion.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
In article <·················@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
> I'm a bit disturbed by the nonportability of an unevaluated backquoted
> form. CLtL/II, on page 528, says: "An implementation is quite free to
> interpret backquote in any way such that a backquoted form, when
> evaluated, will produce a result EQUAL to that produced by the
> interpretation shown here." This implies that on seeing a backquoted
> form, the Common Lisp reader might generate virtually *anything*--from
> an expression that invokes an implementation-dependent function,
> macro, or special form, all the way to an object of some nonstandard,
> implementation-dependent type--which happens to evaluate to the
> correct result.
It's worth noting that even spartan Scheme has specified the form of
unevaluated backquote structures. In particular:
`<template> <=> (quasiquote <template>)
,<expression> <=> (unquote <expression>)
,@<expression> <=> (unquote-splicing <expression>)
> Thus, any code that sees the unevaluated backquoted
> form--e.g., a macro that receives it as an argument--must be prepared
> for *anything*. Moreover, there is no guaranteed way to convert the
> backquoted form into a portable equivalent that uses LIST or APPEND.
> So, for example, a macro that behaves differently according to whether
> its (unevaluated) argument is a cons or an atom, may or may not
> consider a backquoted argument to be a cons. Or, if the macro writes
> its argument out to a file, that file may or may not be readable by
> the same or any other Common Lisp implementation.
Portable pretty-printers are also impossible to write with this
unspecified.
Doug