Subject: Re: Modifying stream printing ? Possible ? Portable ?
From: Erik Naggum <>
Date: 1998/01/20
Newsgroups: comp.lang.lisp
Message-ID: <>

* 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.

The year "98" was new 1900 years ago.  |  Help fight MULE in GNU Emacs 20!
Be year 2000 compliant, write "1998"!  |