[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
| Date: Thu, 14 Jul 88 23:19:48 PDT
| From: firstname.lastname@example.org (Edward Wang)
| Subject: Re: read-line
| // From: email@example.com
| // 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