From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: change stream element-type on the fly?
Date: 1999/03/24
Message-ID: <3131225037178353@naggum.no>#1/1
X-Deja-AN: 458188372
References: <7d909t$btl$1@news-1.news.gte.net>
mail-copies-to: never
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Newsgroups: comp.lang.lisp

* rme@nightfly.apk.net (R. Matthew Emerson)
| It would be handy to be able to change the element-type of a stream
| on-the-fly.

  chuck the C mind-set and re-evaluate the problem.

| I wrote code to read PPM files.  One variation consists of an ASCII
| header (magic, width, height, max-sample-value) and then width*height
| samples, stored as raw bytes.

  this isn't all that uncommon.

| It would be cool to use READ to read the ASCII header, and then switch
| the element-type of the stream to (unsigned-byte 8) and use READ-SEQUENCE
| to slurp in the raw data all at once.  As it is now, I see no alternative
| but to use the moral equivalent of C's atoi() and friends.

  how about slurping a major portion of the file into a specialized vector
  of unsigned-byte 8, write a character stream class that can eat out of
  such a vector as its input buffer with an accessible buffer index you
  could use to retrieve individual bytes?

  if you need to read lines of data, or, say, until a double newline,
  search for the terminator as bytes with SEARCH, and use (map 'string
  #'code-char ...) of a subsequence of the full vector/buffer.  (use
  displaced arrays to cut the copying costs.)  use this form directly in
  WITH-INPUT-FROM-STRING.

  remember: bytes never _were_ characters.  just because two different
  objects have the same machine representation doesn't mean they are the
  same.  the whole notion of _type_ is about communicating intent.  C has
  never understood this, and gives you a short-cut that most people don't
  realize _is_ a short-cut.  a lot of really bad design follows from this.

#:Erik