From: ············@gmail.com
Subject: unread more than one char
Date: 
Message-ID: <1191828434.705299.293110@o80g2000hse.googlegroups.com>
unread-char allows only one char to be unread at a time from a
stream.Is there any function (or can I write a function) which will
allow me to move back a desired number of characters back in a file
stream ?

From: Edi Weitz
Subject: Re: unread more than one char
Date: 
Message-ID: <uodfa3qcl.fsf@agharta.de>
On Mon, 08 Oct 2007 07:27:14 -0000, ·············@gmail.com" <············@gmail.com> wrote:

> unread-char allows only one char to be unread at a time from a
> stream.Is there any function (or can I write a function) which will
> allow me to move back a desired number of characters back in a file
> stream ?

You can wrap the streams you're interested in with Gray streams and
implement your own version of UNREAD-CHAR on top of them, i.e. you'd
write your own buffering code.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Thomas A. Russ
Subject: Re: unread more than one char
Date: 
Message-ID: <ymiprzpuyrz.fsf@blackcat.isi.edu>
·············@gmail.com" <············@gmail.com> writes:

> unread-char allows only one char to be unread at a time from a
> stream.Is there any function (or can I write a function) which will
> allow me to move back a desired number of characters back in a file
> stream ?

There is non such existing function.

You could, of course, write your own.  The simplest approach would be to
create your own wrapper class for the file stream (or, indeed, any
stream) and manage your own pushback buffer.


-- 
Thomas A. Russ,  USC/Information Sciences Institute
From: Alberto Riva
Subject: Re: unread more than one char
Date: 
Message-ID: <fee4fg$os5c$1@usenet.osg.ufl.edu>
············@gmail.com wrote:
> unread-char allows only one char to be unread at a time from a
> stream.Is there any function (or can I write a function) which will
> allow me to move back a desired number of characters back in a file
> stream ?

What about:

(defun stream-backup (stream n)
   (file-position stream
     (- (file-position stream) n)))



Alberto
From: Edi Weitz
Subject: Re: unread more than one char
Date: 
Message-ID: <u7ilxuykh.fsf@agharta.de>
On Mon, 08 Oct 2007 16:38:08 -0400, Alberto Riva <·····@nospam.ufl.edu> wrote:

> What about:
>
> (defun stream-backup (stream n)
>    (file-position stream
>      (- (file-position stream) n)))

The standard doesn't require streams to be able to represent the
notion of file position, i.e. what FILE-POSITION returns could be NIL,
or trying to change the file position doesn't have to succeed.

Also it says (in the FILE-POSITION dictionary entry) that for "a
character file, performing a single READ-CHAR or WRITE-CHAR operation
may cause the file position to be increased by more than 1."

Edi.

-- 

Lisp is not dead, it just smells funny.

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Alberto Riva
Subject: Re: unread more than one char
Date: 
Message-ID: <feeucu$9g4i$1@usenet.osg.ufl.edu>
Edi Weitz wrote:
> On Mon, 08 Oct 2007 16:38:08 -0400, Alberto Riva <·····@nospam.ufl.edu> wrote:
> 
>> What about:
>>
>> (defun stream-backup (stream n)
>>    (file-position stream
>>      (- (file-position stream) n)))
> 
> The standard doesn't require streams to be able to represent the
> notion of file position, i.e. what FILE-POSITION returns could be NIL,
> or trying to change the file position doesn't have to succeed.

Yes, but for a "file" stream on a "normal" platform it would probably 
work... I was offering a practical workaround.

> Also it says (in the FILE-POSITION dictionary entry) that for "a
> character file, performing a single READ-CHAR or WRITE-CHAR operation
> may cause the file position to be increased by more than 1."

True, I left discovering that as an exercise for the OP :) Of course if 
the positions to jump back to can be determined when they are 
encountered, it may be better to save their FILE-POSITIONs, so that this 
is not a problem anymore.


Alberto
From: Steven M. Haflich
Subject: Re: unread more than one char
Date: 
Message-ID: <2VdQi.58374$Um6.54956@newssvr12.news.prodigy.net>
Alberto Riva wrote:

> True, I left discovering that as an exercise for the OP :) Of course if 
> the positions to jump back to can be determined when they are 
> encountered, it may be better to save their FILE-POSITIONs, so that this 
> is not a problem anymore.

Even more, the notion of what might work on a file stream might not
always work on other kinds of streams idiomatic to the platform and
implementation.  Consider a stgream connected to a pipe or socket.
Unreading an arbitrary number of characters can only work if the
implementation of the stream is willing to remember a similarly
arbitrary number of previously-seen characters.

There is no way to implement this portably within the ANSI
specification, just as there is no way to do this in C or
most other languages.  Implementations of Gray streams or
simple-streams may allow you the ability to implement what
was needed, if the number of backup characters can be limited
to something taht will fit within the available heap, or file
storage, of whatever finite limits are thought reasonable.
From: Kaz Kylheku
Subject: Re: unread more than one char
Date: 
Message-ID: <1192053768.475665.198980@o80g2000hse.googlegroups.com>
On Oct 8, 12:27 am, ·············@gmail.com" <············@gmail.com>
wrote:
> unread-char allows only one char to be unread at a time from a
> stream.

If you need more than one character of lookahead in a lexical scanner,
you're probably doing something wrong.