[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Common-Lisp @ SU-AI
- From: Kent M. Pitman <KMP @ MIT-MC>
- Date: Tue, 07 Jun 1983 01:54:00 -0000
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:
(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
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
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.