[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
sharp plus question
- To: DCP@QUABBIN.SCRC.Symbolics.COM, DFM%JASPER@LIVE-OAK.LCS.MIT.EDU, common-lisp@SU-AI.ARPA
- Subject: sharp plus question
- From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 22 Dec 86 09:08 EST
- Cc: dfm@JASPER.Palladian.COM
- In-reply-to: <861219125356.4.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Fri, 19 Dec 86 12:53 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Fri, 19 Dec 86 11:59 EST
From: Don Morrison <dfm@JASPER.Palladian.COM>
What should the second form in the following read as?
(push :mumble *features*)
'(#-mumble #+mumble 1 2 3)
I would expect '(2 3). Both implementations I've tried read '(3), which
is completely unintuitive to me. Such a thing can easily come up in real
life (e.g. commenting out with #+(or) something that's already under
Palladian Software, Inc.
This is curious. In the Symbolics 7.0 implementation,
'(#+non-existent-feature #-non-existent-feature 1 2 3)
'(#-non-existent-feature #+non-existent-feature 1 2 3)
'(#+LISPM #-LISPM 1 2 3)
each read as '(2 3) but
'(#-LISPM #+LISPM 1 2 3)
does read as '(3). This does seem wrong on the following grounds:
#-LISPM goes into the mode "read me a form, and ignore it." It
recursively invokes the reader.
The reader gets #+LISPM. #+LISPM goes into the mode "read
me a form and don't ignore it."
Currently, the Symbolics' reader treats both #+ and #- as "ignore next
form" when *READ-SUPPRESS* is T. This is probably a misinterpretation
of *READ-SUPPRESS*. It was done to solve the problem of an illegally
formed expression following a #+ inside a form with *READ-SUPPRESS* 'T.
(INCF (FROB-KNOB GROZZLE)
#-(CAR FGR:*GROZZLE-MODES*) 2)
Is the correct interpretation to obey #+ and #- even inside a
*READ-SUPPRESS*? (while still suppressing errors inside the feature
Clearly #+NON-FEATURE (A B #-NON-FEATURE C), shouldn't cause read errors
while reading C.
The question is whether the internal "feature specification" should be
read with *READ-SUPPRESS* bound specially to NIL or not.
If we keep the current binding of *READ-SUPPRESS*, then feature will
always be NIL (*READ-SUPPRESS* causes all extended tokens to be NIL).
If we bind *READ-SUPPRESS* to NIL to read the feature specification,
then syntactic "errors" in the feature can cause errors.
The problem of supporting (by ignoring) non-standard syntax in feature
specifications doesn't need to be part of COMMON-LISP (I don't think
CL allows extensions there), the question of nested #-'s does need to be
Implementations (Symbolics' for example) that want to be generous in
what they accept without error, can handle that themselves.
This recursively invokes
The reader reads 1.
#+LISPM does not ignore the 1, so it returns it as the thing
#-LISPM is given 1 as the result of the read, and ignores it.
2 and 3 are still in the input stream, so I don't know how both
of them manage to get ignored.
[I'm not sure what the current state of our mailer is, but I think mail
addressed to DFM%JASPER@LIVE-OAK.LCS.MIT.EDU will eventually get to me.]
I'm not on the COMMON-LISP mailing list, but someone from Symbolics can
forward to me any replies, if there is some trouble with the return