Subject: [clisp-list] listen on binary streams?

From: [email-masked] (Don Cohen)
Date: Fri, 24 Mar 2000 20:48:29 -0800

I notice that when I do this
   (setf (stream-element-type stream) '(unsigned-byte 8))
the function LISTEN always returns NIL.
CLHS says of listen:
  Returns true if there is a character immediately available from input-stream

I'd have thought that it would also return true if a byte was
available.  How am I supposed to find out whether there's a byte
available?  I notice there's a read-char-no-hang but there seems
to be no read-byte-no-hang.

---

From: Bruno Haible <[email-masked]>
Date: Mon, 27 Mar 2000 12:05:27 +0200 (MET DST)

>   Returns true if there is a character immediately available from input-stream

Yuck. Reading a character and reading a byte are different things. In
previous versions, clisp behaved as you expected, because characters were
1 byte long.

> available?

There is no standardized function that permits you to do so.

Bruno

---

From: [email-masked] (Don Cohen)
Date: Mon, 27 Mar 2000 11:40:46 -0800 (PST)

Bruno Haible

  
  
  Bruno
  
Even in previous versions it seems to me that characters could not
always be one byte long, due to newline encoding.  If you see a CR
but nothing more, you can't say there's a character ready, cause you 
don't know whether it will be followed by LF.  Depending on the
next character you either want read-char to return #\return or 
#\newline.  Or do you take another approach here?

I suggest that when the stream element type is not character, the
listen function still return true if there is enough data available
to return the next element.  It's hard to believe that was not the
intention of the spec.

At the moment the way I (try to) see whether there is any data on my
stream is to set the stream element type to character and listen.
Unfortunately, it looks to me like that may fail in the CR case above.

---

From: Bruno Haible <[email-masked]>
Date: Tue, 4 Apr 2000 22:34:48 +0200 (MET DST)

Don Cohen wrote a week ago:

> #\newline.

You are right. In older clisp versions, a CR could probably cause the
'read-char-no-hang' function to hang.

In recent clisp releases this is fixed: The Mac end-of-line convention
is accepted too. This means that a lone CR without LF gives #\newline,
just like CR followed by LF. And 'listen' knows that it doesn't have to
wait for the LF in order to return #\newline.

> to return the next element.  It's hard to believe that was not the

In CLtL you had separate sections for "character I/O" (thick section,
including read-char-no-hang and listen) and "binary I/O" (containing
only read-byte and write-byte). I therefore believe they were aware
that the binary I/O API is not complete.

Bruno

---

From: [email-masked] (Don Cohen)
Date: Tue, 4 Apr 2000 13:50:34 -0700 (PDT)

Bruno Haible

  
  
I guess that means that read-char can never return #\return or
#\linefeed.  Is this another change?

  
Perhaps we could take a poll among those authors/reviewers
we can find.  Any idea who they are and how to reach them?

---

From: [email-masked] (Don Cohen)
Date: Tue, 4 Apr 2000 17:43:44 -0700 (PDT)

Below is a reply I got from Steve Haflich on this subject.
I guess what it comes down to is that when I switch the stream element 
type between character and byte I also must be toggling whether it's
interactive !  Needless to say, I'm not entirely satisfied.
I don't see that listen should have anything to do with interactivity
in the sense of whether it makes sense to ask a question.  It ought
to just tell you whether there's something ready for you to read.

     Date: Tue, 4 Apr 2000 14:43:31 -0700
     From: [email-masked] (Don Cohen)
     To: [email-masked]
     Subject: question about common lisp standard

     The listen function is described as telling you whether there's a
     "character" available.  Is this supposed to mean that on binary
     streams it whould always return false?  Or should it tell you whether
     there's a byte available?  Could this be a simple oversight?  Or is it 
     a conscious choice (and if so, why)?  Are you the right person to ask?
     If not, who is?

  I'm not the correct person to ask as I am no longer involved with
  Franz' Common Lisp products.  I'll give a quick (but unauthoritative)
  explanantion of the ANS as one of its drafters.

   listen &optional input-stream generalized-boolean

   Returns true if there is a character immediately available from
   input-stream; otherwise, returns false. On a non-interactive
   input-stream, listen returns true except when at end of file1. If an
   end of file is encountered, listen returns false. listen is intended
   to be used when input-stream obtains characters from an interactive
   device such as a keyboard.

  In the portable language there is no way to create an interactive
  stream.  An implementation might idiomatically provide one for an
  interactive connection to the user, and that stream is implied to be a
  character stream.  The only portable way a user can create a stream
  (ignoring compound streams) is with OPEN, which is necessarily a
  file-stream and non-interactive.  (Ignore the irregularity that Unix
  devices and named pipes have names in the file system and might
  sometimes be more usefully connected to interactive streams.)

  These portable capabilities of LISTEN (as well as stream creation and
  stream capabilities) are so impoverished as to be nearly irrelevant to
  real current programming needs, unless you can survive by writing dumb
  tty-in tty-out applications.  For real use, programmers need to depend
  on the particular platform's (i.e. ACL) extensions, and keep in mind
  the directions in which those are developing for the future.  That
  question is best directed to the regular [email-masked] support
  channels.