Should this make a compiler complain about the comma not being
backquoted (as ACL does)?
#+(or) (print ,hi-mom)
Jes wondrin.
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 8, 9:09 pm, Ken Tilton <···········@optonline.net> wrote:
> Should this make a compiler complain about the comma not being
> backquoted (as ACL does)?
>
> #+(or) (print ,hi-mom)
No, this is broken. Or, at best, a poor quality interpretation of a
gray area.
During the reading of a form that was suppressed by a feature test,
the *read-suppress* special is bound, and given the value T.
If *read-suppress* is T, the reader is not supposed to bitch about
syntax or type errors.
The reason is that code which is excluded by #+ might use the
extensions of another Lisp implementation; a possible such extension
might be a dangling comma.
Since you haven't written an unbalanced paranthesis, or used something
like #< which calls for an error, there is no reason to complain. The
read macro for , can trivially check *read-suppress* and behave
gracefully.
See the description of *read-suppress* for the details.
Why I said "gray area" at the outset is due to the exception for
backquote notations: ``No matter what the value of *read-suppress*,
parentheses still continue to delimit and construct lists; the
#( notation continues to delimit vectors; and comments, strings, and
the single-quote and backquote notations continue to be interpreted
properly. Such situations as '), #<, #), and #<Space> continue to
signal errors.''
You could argue in defence of ACL that throwing an error on a dangling
comma is an example of continuing to interpret backquote notations
properly, in spite of *read-suppress* being true.
> Jes wondrin.
You know, I should't even be speaking to you.
Bitch!
From: Kent M Pitman
Subject: Re: Paging all CL language lawyers
Date:
Message-ID: <uprv6wkp1.fsf@nhplace.com>
Ken Tilton <···········@optonline.net> writes:
> Should this make a compiler complain about the comma not being
> backquoted (as ACL does)?
LispWorks does, too.
> #+(or) (print ,hi-mom)
>
> Jes wondrin.
IMO, the issue is not really dictated by the spec, but by common
sense. #+/#- is intended to span not just CL but other dialects of
Lisp. To include Franz Lisp, Maclisp, and other older [and perhaps
one day newer] dialects of Lisp. Consequently, if one signals an
error in this context, the problem is that you're making it hard to do
things like
#+MACLISP (print ,hi-mom)
I mention this because in early Maclisp, comma meant the same as
whitespace. Historically, that probably predates the sharpsign
readmacro. And then MACLISP went through a phase where , as possible
to read out of context and didn't give a read-time error.
But even within CL, the entire design of #+ and #- is organized around
the notion that readmacros are supposed to try to avoid making
bracketing problems so that you can incorporate even strange things
inside #+something (progn ...) and even if you can't read the thing
inside the progn, you can tokenize it, and then ignore the tokens.
DISCLAIMER: I didn't go back and do a search of the manual to see if
that's what's required. The above is just my emotional impression.
From: Edi Weitz
Subject: Re: Paging all CL language lawyers
Date:
Message-ID: <uhcgiel2y.fsf@agharta.de>
On Sat, 09 Feb 2008 00:09:41 -0500, Ken Tilton <···········@optonline.net> wrote:
> Should this make a compiler complain about the comma not being
> backquoted (as ACL does)?
>
> #+(or) (print ,hi-mom)
>
> Jes wondrin.
I'm not sure if it /should/, but I know that I've seen that on
LispWorks as well. I think what happens is that the reader knows,
when seeing the #+(or), that it has to skip the next form, but it
still has to /read/ the next form somehow to figure out where it ends.
(It doesn't use READ of course, but probably some stripped-down
variant.) And so it sees the comma and is confused.
It seems SBCL can cope with that, though.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")