sharp plus question

[Michael Greenwald <Greenwald@STONY-BROOK.SCRC.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
	#+mumble).

						  Don Morrison
						  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.

For example, 
  (PROGN
    #+IMPLEMENTATION-X
    (INCF (FROB-KNOB GROZZLE)
	  #+SYS:GREEPS-ALLOWED 3
	  #-(CAR FGR:*GROZZLE-MODES*) 2)
    ....)

Is the correct interpretation to obey #+ and #- even inside a
*READ-SUPPRESS*?  (while still suppressing errors inside the feature
specification?)

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
made unambiguous.

Implementations (Symbolics' for example) that want to be generous in
what they accept without error, can handle that themselves.

						This recursively invokes
		the reader. 
		    The reader reads 1.
		#+LISPM does not ignore the 1, so it returns it as the thing
		read.
	    #-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
paths.