From ... From: Erik Naggum 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