[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]

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

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

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?