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

Re: buffered output and prompting



	
    Date: Thu, 20 Feb 1986  18:41 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
    To:   SANDRA <LOOSEMORE@UTAH-20.ARPA>
    Subject: buffered output and prompting
    
	Date: Wednesday, 19 February 1986  13:10-EST
	From: SANDRA <LOOSEMORE at UTAH-20.ARPA>
	To:   common-lisp at SU-AI.ARPA
	Re:   buffered output and prompting
    
	I'm having trouble coming up with a portable way for a CL application
	program to read with a prompt string.  What I would like to do is
	something like, but more general than, the y-or-n-p and yes-or-no-p
	functions: specify a prompt string and then call read, read-line, or
	read-char.  For a usual terminal-style interaction, I'd like to have
	the prompt message printed out without a newline so the cursor is left
	at the end of the same line, and then read.
    
....
    I think it is definitely wrong for a FORCE-OUTPUT or FINISH-OUTPUT to
    implicitly cause a newline to be written.
I agree.  I don't think pg. 22 implicitly allows FORCE-OUTPUT or
FINISH-OUTPUT to postpend a newline.  All pg. 22 says (to me) is that
in some implementations:

1. For output that contains a newline, the output medium may be such
that a newline neither appears as a visible glyph nor causes some
state-change in the carriage-control mechanism or linefeed mechanism
of the output medium (since some output mediums have no such
mechanisms, e.g., a card-punch.)  But, the newline must be manifested
in some way, e.g., ending the current card without punching a
line-contiuation indicator (card-punches w/o such a mech. cannot be
used as the output medium for CL, since you couldn't print tokens
conatining more chars. than could be fit onto a single card.)

2. For input that contains a newline, the input medium may be such
that the newline character is not represented as a distinct entity,
e.g. a byte in memory; rather the newline is implicit in the structure
of an input record, e.g., based on the length of the record.  But,
there is usually a way to overide such an implicit interpretation, in
order to allow tokens and/or lines which might otherwise be
input with an embedded newline to be input without a newline being
implicitly embedded, e.g., on an input card there is a continuation
indicator that allows lines longer than the number of chars. on a
single card.  (note that such an override would be required on card
readers that read cards that could not contain enough chars. for the
longest CL defined symbol (which one is the longest? :-)).

It does not allow printing to or reading from such mediums to throw in
extraneous newlines merely because of peculiarites in nature the
medium, e.g., record-length limits and default interpretations of
distinct records as distinct lines.

For example, FORCE-OUTPUT may cause the current card to be flipped
into the ouput bin, but if it does so, it had better punch the
continuation indicator before doing so.

I think it would be a good idea to clarify FORCE-OUTPUT and
FINISH-OUTPUT so that it is clear that they cannot generate an
implicit newline.

	-- Nick