Minor changes to proposed reader syntax

[Kent M. Pitman <KMP at MIT-MC>]

I propose that bit vectors be read by #*nnnn rather than #"nnnn" since it's
a waste of a good matchfix operator "..." to use on something with so 
deterministic and endpoint. #*nnnn has its end clearly delimited by anything
not a base-2 digit.

I further propose extending #*nnn to allow #m*nnn meaning that the bit 
vector referred to is m times the number of digits and filled with the bits 
given by nnn in radix 2^m. So that #3*35 would be the same as #*011101 -- 
ie, the default radix would be 2 for bit vectors. This might be handy for 
people doing bit vectors with 4bit bytes so they could write #4*A3 meaning
#*10100011. It is somewhat symmetric with #nR. I'm amenable to arguments that
one should write radix rather than bitesize as in #8*35 and #16*A3. Also,
the choice of * as opposed to something else is completely arbitrary. NIL
used to use #* for something, I don't know if it still does.  Maybe they'd
prefer another character like underbar or something. I don't have any set
feeling for that, I just don't want to waste "..."'s expressiveness on 
something so simple as bits.

The reason I bring this up is that I found what I think is a really good use
of #"...". Following in the line of reasoning that `... should be like '...
when no comma is present, suppose #"..." were like "..." when no tilde was
present, but fully defined by:

    (defun read-sharpsign-doublequote (instream char)
      (uninch char instream)
      (format nil (read instream)))

so that something calling READ could not tell if the user had written, for
example, #"ABC~%DEF" or "ABC
DEF".

This #"..." has applications to indenting code nicely without requiring runtime
calls to FORMAT. Here's a case under discussion:

(defun f (x)
  "This is a doc string which looks nice only when indented
   but which has the problem that later when I do (GET-DOC 'F) I
   find that the second and third line of the string retain the indentation."
  x)

Could be re-written as

(defun f (x)
  #"This is a documentation string which does not share that bug~@
    and which is indented nicely."
  x)

This also makes it possible to consider Moon's last remark about putting the
doc string in the comment because it could be then indented nicely as in

(defun f (x)
  (declare (documentation #"This is a documentation string which is ~
			     indented quite a lot, but which still~@
			    looks nice later on when retrieved because ~
			     it is reformatted nicely at read time."))
  x)

This note does not mean to make any proposals related to declare or 
documentation strings. I was only using this as an exmaple. Here's another
example that shows how worthwhile it is -- I used to write code from time
to time that said:

(defun g (x) (h #.(format nil "This is a string to type out~%on two lines.")))

Sometimes I'd even leave out the #. and let the string get recomputed 
at runtime. But now I could just write:

(defun g (x) (h #"This is a string to type out~%on two lines."))

Does anyone buy this?