Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!sei!fs7.ece.cmu.edu!o.gp.cs.cmu.edu!SCHUBERT.PRODIGY.CS.CMU.EDU!dkahn
From: dkahn@SCHUBERT.PRODIGY.CS.CMU.EDU (Daniel Kahn)
Newsgroups: comp.lang.lisp
Subject: Re: weird common lisp feature
Keywords: read, read-line
Message-ID: <1991Feb22.194341.1744@cs.cmu.edu>
Date: 22 Feb 91 19:43:41 GMT
References: <12413@helios.TAMU.EDU> <12414@helios.TAMU.EDU>
Sender: netnews@cs.cmu.edu (USENET News Group Software)
Reply-To: dkahn@SCHUBERT.PRODIGY.CS.CMU.EDU (Daniel Kahn)
Organization: Carnegie Mellon University
Lines: 19


|> >
|> >(defun foo1 () (print 'hello) (read-line))
|> >(defun foo2 () (print 'hello) (read))

You might try something like this:

(defun foo1 () (print 'hello) (finish-output) (read-line))

It is conceivable that in foo1 the print sends its output to operating
system and then the read-line beats it to the control of the terminal
(is this a "race condition"?).  The read-line might then "block" the
print from working until it is done.  In foo2 the more complicated read would take so long to reach the terminal that the print would be the first one there.  

This will guarantee syncronicity in I/O so that the print finishes sending is output to the device before the read starts.  In general I use finish-output and I check my streams when I have weird output.

Also you might use the TRACE macro on print and read-line just to check the order of execution which should be left to right.

--dan