I would like to write a new Common Lisp input stream type for a
particular purpose (filtering), and need some guidance or examples to
get started. Writing new stream types, or, to be particular, stream
buffer types, is fairly common in C++. The framework is small and
fairly easy to grasp in that there are only two or three functions
necessary to create a minimal character source (or input stream
buffer). Does Common Lisp offer a similar extension framework?
I read the full HyperSpec section on streams and saw the related
functions. Some appear to be dependent on others. For example,
read-char could be used to implement read-string. In C++, one starts
minimally by providing a means to extract a single character. The
related function to extract a sequence of characters will by default
rely upon multiple calls to the single character extractor. To improve
performance where possible, the customized stream buffer can offer its
own function to extract a sequence of characters, and that function
will be used instead of the generalized iterative one.
I expected to find a related arrangement in CL. For example, a custom
stream would first specialize a read-char generic function. Then
read-string would be a generic function with a specialization on the
basic stream type, implemented with repeated calls to read-char. But a
new stream type could optionally specialize the read-string or
read-sequence methods to provide more efficient versions. A lazy
programmer could at least get started on a new input stream with
these:
[direction-independent]
close
Might pass this on to an underlying wrapped stream.
stream-element-type
Probably a character.
input-stream-p
True.
interactive-stream-p
Delegate to wrapped stream.
interactive-stream-p
False.
output-stream-p
False.
[input]
listen
Not sure, maybe delegate.
peek-char
Need this.
read-char
Need this.
read-char-no-hang
Not sure if I can do this.
unread-char
Need this.
The rest of the stream-related functions should preserve their default
behavior. That approach sounds fine as a proposal, but I don't see any
comments in the HyperSpec to suggest that writing new stream-derived
types is normal and encouraged. Is my proposal above at all related to
reality in CL? If so, what should I consult next to find an example?
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <···············@raytheon.com>,
Steven E. Harris <········@raytheon.com> wrote:
>The rest of the stream-related functions should preserve their default
>behavior. That approach sounds fine as a proposal, but I don't see any
>comments in the HyperSpec to suggest that writing new stream-derived
>types is normal and encouraged. Is my proposal above at all related to
>reality in CL? If so, what should I consult next to find an example?
Common Lisp doesn't provide a standard way to define your own streams.
However, most implementations do, and I think they generally implement an
architecture called "Gray Streams". Do a google search for this.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, 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.
Barry Margolin <··············@level3.com> writes:
> Common Lisp doesn't provide a standard way to define your own
> streams. However, most implementations do, and I think they
> generally implement an architecture called "Gray Streams".
I have heard of "Gray Streams" mentioned, but never looked into why
such an improvement was necessary. This is exactly what I was looking
for. In fact, check out the table "Generic functions for character
input"� in the Franz Gray Streams documentation; it's almost exactly
like the list I posted.
Perfect. Thanks for the pointer.
Footnotes:
� http://www.franz.com/support/documentation/6.2/doc/gray-streams.htm#gs-char-input-1
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Barry Margolin wrote:
> In article <···············@raytheon.com>,
> Steven E. Harris <········@raytheon.com> wrote:
>
>>The rest of the stream-related functions should preserve their default
>>behavior. That approach sounds fine as a proposal, but I don't see any
>>comments in the HyperSpec to suggest that writing new stream-derived
>>types is normal and encouraged. Is my proposal above at all related to
>>reality in CL? If so, what should I consult next to find an example?
>
>
> Common Lisp doesn't provide a standard way to define your own streams.
> However, most implementations do, and I think they generally implement an
> architecture called "Gray Streams". Do a google search for this.
>
Franz Lisp modified this Gray stream code into something more
polished, called "simple streams." Has been ported to CMUCL and SBCL.
http://www.cliki.net/simple-stream
Regs.
Henry
From: Marco Antoniotti
Subject: Re: Creating a new stream type
Date:
Message-ID: <3F11A353.60305@cs.nyu.edu>
synthespian wrote:
> Barry Margolin wrote:
>
>> In article <···············@raytheon.com>,
>> Steven E. Harris <········@raytheon.com> wrote:
>>
>>> The rest of the stream-related functions should preserve their default
>>> behavior. That approach sounds fine as a proposal, but I don't see any
>>> comments in the HyperSpec to suggest that writing new stream-derived
>>> types is normal and encouraged. Is my proposal above at all related to
>>> reality in CL? If so, what should I consult next to find an example?
>>
>>
>>
>> Common Lisp doesn't provide a standard way to define your own streams.
>> However, most implementations do, and I think they generally implement an
>> architecture called "Gray Streams". Do a google search for this.
>>
>
> Franz Lisp modified this Gray stream code into something more polished,
> called "simple streams." Has been ported to CMUCL and SBCL.
I think this is incorrect. AFAIK, Gray Streams and Franz Simple Streams
are partially incommensurable.
Cheers
--
Marco
synthespian <···········@uol.com.br> writes:
> Franz Lisp modified this Gray stream code into something more
> polished, called "simple streams." Has been ported to CMUCL and
> SBCL.
Thanks for following up. I noticed simple-streams while trying to
learn about Gray streams, as the Franz documentation point out some
deficiencies with Gray streams and recommend using simple-streams
instead. I didn't read too much further, though, because I figured
that simple-streams were limited to Allegro CL and found that CLISP,
my current implementation, supports Gray streams. Since Gray streams
seem to have wider support and offer a design similar to what I was
expecting to find, I figured I'd play with those first.
This is just experimental curiosity driving me. Looking forward, I
would like to gain enough knowledge, experience, and -- to borrow from
Graham -- taste to understand and sympathize with the Franz criticism,
perhaps changing implementations then to find simple-streams support.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com