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

Re: I/O proposal

Will-- A few questions and remarks about your I/O proposal:

-- What happened to the names PRIN1 and PRINC?  Are your WRITE and DISPLAY
meant to be equivalent, respectively, to PRIN1 and PRINC?  As I understand
page 382 of the Common LISP (CL) book, your WRITE is not incompatible with
CL's.  Likewise, CL doesn't seem to have a DISPLAY.  However, I am bothered
by my intuition that DISPLAY should be a terminal-oriented operation.

   Bottom line: I vote to go with WRITE and DISPLAY, but the names PRIN1
and PRINC should be reserved as well (as optional aliases).  The PRINT
operation should also be optional, with the CL-compatible meaning we agreed
on at the workshop.

-- DISPLAY-CHAR seems to be a redundant, restricted form of DISPLAY. Since
DISPLAY is essential, DISPLAY-CHAR should be dropped.

-- The name LISTEN? also is slightly unintuitive to me; how about INPUT?,
or MORE-INPUT?, or something with "peek" in it.

-- Does READ-CHAR wait for interactive input or return an eof token if
nothing has been buffered up from the keyboard (or comm device, etc)?

-- I oppose the term "stream" and thus the names STREAM?, CURRENT-INPUT-
STREAM, etc., for the reasons Gerry gave.  We use "port".

-- With my Pascal (and English) background, I can't help but think of
features named with "with", like WITH-INPUT-FROM-FILE, as syntax, not
procedures.  [Did you notice how I began the previous sentence?]  I would
prefer a special form: (WITH-INPUT-FROM-FILE <file-name> exp ...).  This is
more consistent with CL's macro WITH-INPUT-FROM-STRING.  The same goes for

-- I don't mind your OPEN- and CLOSE- operations, as long as they remain
optional, but I feel bound to implement OPEN and CLOSE compatibly with CL.

-- I like your approach to eof objects.

-- You have no READ-ATOM.  Is there general agreement that READ-ATOM is
unimportant?  We have it only by inheritance from Scheme 84.

David Bartley