Re: read-line

[quiroz@cs.rochester.edu]

| Date: Thu, 14 Jul 88 23:19:48 PDT
| From: edward@ucbarpa.berkeley.edu (Edward Wang)
| Subject: Re: read-line
| 
| // From: iuvax!att!ihlpf!clarisse@rutgers.edu
| 
| // Read-line should start reading as soon as you close the parenthesis
| // and it does this properly in KCL.
| 
| Read-line is fine, but the toplevel doesn't read the newline
| if you type (read-line)<return>.  It's clearly difficult
| to deal with if you write a program that begins by reading
| some interactive input.  It has to know to skip over the
| first newline.

As `listen' and `clear-input' are no-ops, and `read-char-no-hang' is
just the same as `read-char', I suppose there is no way you can
synchronize your input streams in KCl.  How do you distinguish a
#\Newline left behind from a previous interaction from one meaning
an empty response to your query?

(Asides: (1) As a matter of practice, I don't often write fancy
interactive programs in Lisp.  My preferred front-end is (break).
But I see how this departure from well-accepted semantics will make
life difficult to other users.  (2) I don't see strong reasons why
the correct semantics of I/O as per the book couldn't be implemented
in Unix, at least in BSD and derivatives.  Perhaps with some
guidance from the authors, some of us could put together a more
robust I/O system.  (3) Whatever happened to the bug that made the
interpreter and the compiler behave differently, as reported by
ilan@ucbvax?)

Cesar