Hey,
CL seems to be lacking...
Other languages don't make such a distinction about binary streams
vs. character streams. But, because of this, I cannot do the equivalent of
the following operations:
peek-byte
peek-byte-no-hang
this is problematic to me. I need to read from a binary socket stream, but
the problem is that I don't know if there's data there waiting for me. (in
this case, it happens to be an ACL socket stream, if that helps). I think
that CL would benefit from getting rid of this distinction, which renders
#'format and #'read-line useless on binary streams. For example, just to
print a string out to a binary stream, I've had to define these simple yet
ideally unnecessary helpers, like:
(defun format* (binary-stream format-string &rest args)
(let* ((string (apply #'format nil format-string args)))
(dotimes (i length)
(write-byte (char-code (schar string i)) binary-stream))))
Does anyone know how to get the equivalent what #'peek-byte[-no-hang] would
do?
thanks,
dave
In article <···············@acs5.bu.edu>,
David Bakhash <·····@acs.bu.edu> wrote:
>Other languages don't make such a distinction about binary streams
>vs. character streams.
Actually, many do. For instance, in C you specify mode "r" or "rb" for
character versus binary input streams. The "b" modifier tells the library
to translate from the native representation of line breaks to the single
character '\n'. It's a no-op on Unix, but it's important on many other
operating systems.
> But, because of this, I cannot do the equivalent of
>the following operations:
>
>peek-byte
>peek-byte-no-hang
PEEK-CHAR was included in the language for the benefit of parsing
applications, which often need to do look-ahead (in particular, it's
necessary to implement the Lisp READ algorithm in Lisp). These
applications are virtually always text-based, so PEEK-BYTE was not needed
as much.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
* David Bakhash <·····@acs.bu.edu>
| CL seems to be lacking...
you're staring at a C legacy, where characters _are_ bytes, and you
conclude that Common Lisp is lacking a feature from C? hello?
| Other languages don't make such a distinction about binary streams
| vs. character streams.
yes, they do. C is relatively unique in not having a character concept.
| Does anyone know how to get the equivalent what #'peek-byte[-no-hang]
| would do?
use LISTEN and read one byte if returns true.
not sure this is a spoiler, but Allegro CL 5.0.1 has bivalent streams so
people who have to talk C protocols can do it in Common Lisp, too.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
Erik Naggum <····@naggum.no> writes:
> * David Bakhash <·····@acs.bu.edu>
> | CL seems to be lacking...
>
> you're staring at a C legacy, where characters _are_ bytes, and you
> conclude that Common Lisp is lacking a feature from C? hello?
Okay. Let me say it another way. It's not that the distinction is so bad,
but that CL socket streams are meant to be raw binary streams. But this
complicates matters when you try to write strings to them. Of course, now I
see your point, which I didn't see before: strings are arrays of type
character, not unsigned-byte, so
(format my-socket-stream "Hello world~&")
can (and probably should) fail. But I'm when trying to talk to a server
written in C++, this becomes an irritation.
Franz's new bivalent socket streams will fix this, as I've already looked into
this.
> use LISTEN and read one byte if returns true.
thanks. I'll try it, though I thought it worked only on character streams.
dave
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> yes, they do. C is relatively unique in not having a character concept.
Unix is relatively unique in not having a character stream concept. But C
itself is pretty ordinary in having it; it was added when implementations
for non-Unix systems were created.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
David Bakhash <·····@acs.bu.edu> writes:
> Other languages don't make such a distinction about binary streams
> vs. character streams.
Other languages don't provide binary streams of arbitrary bytes.
> to print a string out to a binary stream, I've had to define these
> simple yet ideally unnecessary helpers, like:
>
> (defun format* (binary-stream format-string &rest args)
> (let* ((string (apply #'format nil format-string args)))
> (dotimes (i length)
> (write-byte (char-code (schar string i)) binary-stream))))
You're specifying the character-to-binary conversion there, that's the
interesting part. How could the system know which conversion you
want? (It might be that what you really want for your current
application is external formats, not binary streams, but of course
most Lisps don't have a very wide selection. LispWorks has a few
useful ones now, and it would be easy to add more.)
Anyway, it might be more efficient to convert the string to the right
vector type and use WRITE-SEQUENCE (or, if you have Gray streams, to
write a filtering stream to pass to FORMAT).
--
Pekka P. Pirinen Harlequin Group plc, Cambridge, UK
"A computer lets you make more mistakes faster than any
invention in human history with the possible exceptions of handguns
and tequila." Mitch Ratliffe, _Technology Review_ April, 1992