Subject: Re: Modifying stream printing ? Possible ? Portable ? From: Erik Naggum <clerik@naggum.no> Date: 1998/01/20 Newsgroups: comp.lang.lisp Message-ID: <3094282731377906@naggum.no> * Rainer Joswig | My LWW 4.0.1 does support [the Gray Streams proposal]. ACL? not having looked at the Gray proposal, I cannot say for sure, yet, but Allegro 4.3.x for Unix and NT does have a STREAM package and allows extensions to their streams via generic functions in that package. a chapter in the User Guide explains how. I'll have to compare the proposal and that chapter to determine if they are the same or even sufficiently close. | Is there a portable implementation? The wish to extend the existing | streams seems very natural for me - all kinds of application would | benefit from a portable implementation. I don't think there can be a portable implementation. the current streams design does not allow sufficient introspection to be able to do the kinds of things that would be needed, but I fully agree on the desirability of such portable extensions. | A chapter on stream extensions might be good for an advanced CL book | (MIME encoding, (de)compression, format conversion, base64, encryption, | ...). (Hint, hint.) I think it would be useful to see if some of this could be handled by the EXTERNAL-FORMAT argument to existing streams functions. unfortunately, only the framework for this functionality is specified by the standard: all values are implementation-defined. a means of registering various external formats would be more useful to me than subclassing on streams because entirely new ways of opening files, etc, would be needed with those subclasses. use of EXTERNAL-FORMAT could, however, mean that mixins were added to the stream class at runtime. then we could also have a list of external formats, to be applied in order. while we're on the topic of streams, I have long wished for a means to extract strings directly from the stream (input) buffer by means of a (movable) marker that denoted the start of such extraction (from which suitable offsets would apply, of course). if the marker was still in a buffer, a new buffer would be allocated when needed, instead of just replacing data in the old buffer. when the marker was moved or disabled, the buffer(s) it held on to could be recycled. this would allow for much reduced data copying when scanning input for tokens. (the Lisp reader would be noticeably faster if it did not have to manage its own token buffer, for instance.) I can implement this today with READ-SEQUENCE and private buffer handling, but that still means copying data, although one could imagine an implementation of READ-SEQUENCE that did not read into a buffer first. #:Erik -- The year "98" was new 1900 years ago. | Help fight MULE in GNU Emacs 20! Be year 2000 compliant, write "1998"! | http://sourcery.naggum.no/emacs/