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

[Derrick Baumer]

 >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.
 >
 
Thank you for the quick reply.  Actually, the problem isn't
just cosmetic - I didn't make that clear.  The extra carriage
return that comes in provides an answer to the next question
being asked.  If you have (y-or-n-p ...) followed by another
input function, (forgive me if my terminology is bad) the
y-or-n-p takes the first letter of the input (the y or n)
and leaves the rest in some kind of buffer? for the next
function that reads input to grab.  Typing "y<return>" at
the y-or-n-p prompt leaves a carriage return (is ^G part of
the carriage return?) on the input stack? so the next
input is "auto-answered" with just a carriage return.  If
you type "yes" at the prompt, the next input's value becomes
"es".  I can type in a small example program to illustrate
if it helps.

If I'm worrying about nothing with a function I'll likely
never use, tell me and I'll shut up ;)

Derrick