Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!tcdcs!swift.cs.tcd.ie!ccvax.ucd.ie!bnolan
From: bnolan@ccvax.ucd.ie (Breanndan O Nuallain)
Newsgroups: comp.lang.lisp
Subject: Re: weird common lisp feature
Summary: empirical studies of lisp implementations
Keywords: read read-line #\newline
Message-ID: <47967.27ce32d5@ccvax.ucd.ie>
Date: 1 Mar 91 10:54:13 GMT
References: <12413@helios.TAMU.EDU> <12414@helios.TAMU.EDU> <4211@skye.ed.ac.uk>
Organization: University College Dublin
Lines: 106

In article <4211@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
> In article <12414@helios.TAMU.EDU> e343ca@tamuts.tamu.edu (Colin Allen) writes:
>>In article <12413@helios.TAMU.EDU> e343ca@tamuts.tamu.edu I asked:
>>>Can anyone tell me why foo1 below appears to execute the read-line
>>>before the print, but foo2 executes the print before the read?
>>>
>>>(defun foo1 () (print 'hello) (read-line))
>>>(defun foo2 () (print 'hello) (read))
>>
>>I should add that I have checked this code now in Kyoto and Franz
>>Allegro Common Lisp and the weird behavior occurs only in kcl.  So
>>possibly this is a bug in kcl.  Anyone run into this before?

Yup, VAX Lisp does this too. It puzzled me for a while
because it's not realy what you'd expect. 

> 
> The behavior I get in KCL is that foo2 does what yuo expect but
> foo1 does something like this:
> 
>    >(foo1)
>    HELLO ""
> 
>    >
> 
> That is, read-line returns an empty string and I don't have to type
> anything.  There is no evidence that the read-line happens before the
> print, and indeed it doesn't.
> 
> What happens is that the newline after "(foo1)" is still there when
> read-line is called, and since read-line takes the characters up to
> the next newline and returns them as a string, you get "".
> 
I go along with this. Further evidence is the following (at
least on VAX Lisp, can't say for KCL): 

   > (foo1)Goodbye
   HELLO
   "Goodbye";
   NIL
   >

(The extra value of NIL is the line-terminated-abnormally 
flag which I assume Jeff left out for clarity above.)

My best guess at what is happening is this. The lisp reader
checks what you are typing at it, character by character,
until it sees a #\newline at which time it evaluates any
completed forms it has collected and holds onto what's left
for later evaluation. For example: 

   > (first '(a b c)) (+ 1 2
   A
   > 3)
   6
   >

But it seems to check the typed characters by doing
something like a PEEK-CHAR for them since the #\newline
character is not consumed when it is taken as an "evaluate
what you've got" instruction. This means that in the
following, 

   > (foo1)
   HELLO
   "" ;
   NIL
   >

the lisp reader "peeks" a #\newline and so attempts to
evaluate the forms typed so far. When it comes to evaluate
(READ-LINE) it does as prescribed and reads everything from
the #\) at the end of "(foo1)" until the next #\newline (the
one peeked in this case) and returns it minus the #\newline.
This also accounts for the previous example. 

The VAX Lisp implementation (and presumably KCL) seems to
stem from the preconception that the lisp reader should be
like a conventional operating system interface, where the
usual mode of interaction is to type some text at it and
indicate that you want it to act on your text by finishing
with a #\newline. Of course, in lisp we have a different
idea about when we're finished typing in a form; we close
the last #\). But in VAX Lisp, you have to finish with a
#\newline regardless. The question mark hangs over the
purpose of a #\newline. VAX treats it as a "yes, I'm happy
with what I've typed so far, evaluate it for me if it's a 
complete form", while CLtL doesn't seem to consider the
possibility that a completed form should remain unevaluated 
until an explicit instruction.

> This is, in my opinion, a bug in KCL.  But it could be argued that
> such behavior is allowed by CLtL.
> 
I agree. It's not desirable but I can't find anything in
CLtL that proscribes it. It _does_ present portability
problems and so should be tied down. 

-- 
____________________________________________________________
       ,  ,      ,
Breanndan O Nuallain        Department of Computer Science
                            University College Dublin
Phone: +353-1-693244        Belfield, Dublin 4
        ext 2487            Ireland
------------------------------------------------------------