[no subject]

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

B1 Make both halves of a complex match in type:		No opinion.

B2 Let SQRT, etc. return complex values:		Yes.
   I see no other choice. This is the generic name; if it doesn't do the
   generic thing, then complex numbers in Common Lisp will be a joke.
   For the case where Fateman worries that a correct (albeit complex)
   answer from SQRT is the wrong thing, I don't see why he can't just
   write his own error checking. I had a bit of trouble finding how you'd
   do the declarations in my Colander edition; in Maclisp, however, I 
   would write something like:
	(LAMBDA (X)
	  (DECLARE (FLONUM X))
	  (IF (MINUSP X) (ERROR "Arg is negative" X))
          (FLONUM-IDENTITY (SQRT X)))

B3 Make MULTIPLE-VALUE-SETQ take multiple arg pairs:	Yes.
   I know people who'd probably write their own macro 
   to do this sort of thing if it weren't provided 
   primitively. Since it must be absolutely trivial
   to implement, I'd just as soon people use a standard 
   name rather than force them to make up their own name 
   for what amounts to the exact same thing.

B4 FLOAT-SIGNIFICAND proposals:				No opinion.

B5 Changes to READ arguments:				No.
   I am not sure I understand all the issues that are being dealt with,
   but for the set that I have thought about (read eof in middle of object,
   flushing extra close parens quietly at toplevel, flushing whitespace after
   toplevel read, etc), I am fairly convinced that the SUBREAD/READ 
   distinction is a valid one in so far as I think that READ is being stretched
   too far and I think that this extra argument for recursive-p will cause us
   trouble later on.

   If we had flavorized streams, I would suggest that all streams support
   a :READ-TOPLEVEL message, such that
	(SEND STANDARD-INPUT :READ-TOPEVEL #'READ)
   was the thing to do to instantiate any read. Note that this doesn't force
   one to write pairs of functions, since any reader can replace #'READ. The
   :READ-TOPLEVEL thing would be responsible for peeking for EOF and exiting
   quietly, for flushing toplevel parens and whitespace, etc. The reader itself
   would just read characters and would err if an eof was encountered within.
   This is essentially a variation of the way :RUBOUT-HANDLER works on the 
   LispM; the application is slightly different, but I expect it is the right
   thing.

   The problem one might expect to have with this is that people writing 
   normal user programs with toplevel READ calls such as:
	(DEFUN PROMPT-AND-ADD-NUMBERS ()
	  (FORMAT T "~&Input numbers (end with a NIL): ")
	  (DO ((L NIL (CONS FORM L))
	       (FORM (READ) (READ)))
	      ((NULL FORM) (APPLY #'+ L))))
   will have to bite the bullet and admit they are calling a toplevel
   READ. Hence, they would write:
	... (FORM (SEND STANDARD-INPUT :READ-TOPLEVEL #'READ)
		  (SEND STANDARD-INPUT :READ-TOPLEVEL #'READ)) ...
   which is admittedly a bit cumbersome. 

   Of course, we don't have message passing yet (do we? -- things change so
   fast...), so it'd have to be slightly different syntax. I suggest
	(READ-TOPLEVEL #'READ)
   where, on the LispM, for example, you'd probably implement this as a call
   to the stream with a :RUBOUT-HANDLER message.

   Oh, there's one other thing that would make this a LOT more comfortable.
   The LispM has a function called PROMPT-AND-READ which is a nice abstract
   way of getting a prompt and doing a toplevel read with some datatype 
   checking built in. I suggest that if we had this function, people would
   probably rarely use READ anyway, since its features are very much nicer.

   In summary, all I'm doing is funneling a lot of other people's ideas 
   through in the form of an alternate proposal:
    * Flush the RECURSIVE-P extra arg.
    * Introduce a new function which can be called to do a toplevel READ so 
      that we don't need function pairs.
    * Also introduce PROMPT-AND-READ as on the LispM which really does more
      what people usually want anyway. (Specifying how to extend 
      PROMPT-AND-READ would also be helpful; I know it's extensible but I'm
      not sure if the LispM people tell their users how).

B6 MERGE-PATHNAMES:					Yes.

B7 CONVENTION						Yes.