[Openmcl-devel] Practical Common Lisp tutorial: y-or-n-p problem

[Gary Byers]

On Sun, 7 Aug 2005, Derrick Baumer wrote:

> Hello.  I have been learning Lisp for about two weeks.
> Forgive me if my question is foolish or misstated.  I
> am going through the online book at
>
> http://www.gigamonkeys.com/book/
>
> and am working on the initial tutorial section.  The
> example code asks me to use (y-or-n-p "Prompt: ") to get
> a yes or no anwer (code from Chapter 3), but when I run
> the code through Slime/Emacs or the standalone OpenMCL
> interpreter, y [return] has the effect of hitting the
> return button twice, with a ^G being thrown in for good
> measure.
>   Best I can figure is maybe there's a CR/LR translation
> issue, but I don't yet know enough to poke around and
> find out/make sure.
>
> I'm running Ubuntu Linux on a G3 IMac, using v.0.14.3 of
> the OpenMCL source, compiled per the directions on your
> website after updating via CVS.  Thank you for your time.
>
> I figure this isn't a huge issue - this doesn't seem
> like the kind of function I'd be using frequently in my
> own code, but it still *might* be a bug :)
>
> Derrick
>

The spec says that Y-OR-N-P "reads an answer in an implementation-
dependent manner (intended to be short and simple, such as reading
a single character such as Y or N.)"  I read that to mean that if
the implementation -can- put *QUERY-IO* into some non-line-buffered
mode when reading the reply and wants to do so, that'd be fine
and desirable.  Whether the implementation can do this may depend
on what type of stream *QUERY-IO* is; I think that I remember how
to do this if there's a TTY device behind the scenes, it's less
clear how to do this if the underlying device is a pipe or socket,
and we don't generally know what type of buffering (if any) is
going on on the other end of the connection (Emacs).

As things are, the #\NewLine that's necessary to terminate input
is echoed (causes the cursor to advance to the beginning of the
next line), but nothing notices the effect that that echoing
that #\NewLine has on the current output position.  When the
REPL does a FRESH-LINE before printing Y-OR-N-P's return value,
FRESH-LINE doesn't realize that the output position is already
at column 0, so it writes a #\NewLine just to be sure.  That
looks ugly, and to be honest it bothers me a little more than
the requirement that Y-OR-N-P's input be terminated with a
#\NewLine.