[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- To: Common-Lisp at SU-AI
- From: MOON at SCRC-TENEX
- Date: Mon, 09 Aug 1982 04:36:00 -0000
- In-reply-to: The message of Sunday, 8 August 1982 19:54-EDT from Fahlman at Cmu-20c
I guess some recipient of this list had better to take responsibility
to forward my message to whatever the hell "slisp: at CMU-20C" is.
I have a couple things to say about Scott's message, aside from Symbolics'
own comments which should get mailed to GLS today or tomorrow.
Page 130: Has anyone got a reasonable algorithm coded up for
rationalize? If not, this function must be flushed from the white
pages.
RATIONAL and the main part of RATIONALIZE have existed in the Lisp machine
for a long time. I wouldn't know whether MIT considers these its property.
The algorithm seems reasonable although its implementation could be made
more efficient.
Page 132: As noted before, the tolerance arguments to MOD and REM must
go.
One of my comments is that I was mistaken in suggesting these; the operation
should be a separate function.
Page 213: We need a kind of stream that really passes the commands and
data to a user-supplied function of closure and another kind where the
user-supplied function gets the commands and supplies the data.
Probably the right way to do this is to pass the command (OUCH,
FLUSH-OUTPUT, or whatever) as the first arg to the function and the
evaluated args to that command as the &rest arg. This is sort of flavor
like, but as long as we don't get into inheritance and mixing I have
objection to this. That would give us enough rope to do all sorts of
weird I/O things.
This is totally incomprehensible. Could we have a clarification?