> On 14 Nov 2017, at 10:20, Prof. Andrew P. Black <bl...@cs.pdx.edu> wrote: > > >> On 13 Nov 2017, at 20:27 , Sven Van Caekenberghe <s...@stfx.eu> wrote: >> >> There is a discussion about positioning (#position , #position: and related) >> but these cannot be supported _in general_ by the kind of streams described >> above. > > I agree with that. But I think that general streams can, and should support: > > # saveState “answers an opaque cookie” > # restoreState: aCookieObtainedFromTheSameStream > > This enables pone to read ahead, and then reset the state to the way that it > was. The implementation of the cookie will depend on the implementation of > the stream. In the simplest case it may be an integer position (sufficient > for an in-core stream); in the more general case it may include a copy of the > stream’s buffer, and the cookie obtained by saving the state of any wrapped > stream. > > Andrew
Yes and no: #saveState / #restoreState: need a possibly unlimited memory/buffer, similar to #position / #position: They cannot be offered in general (a socket stream is infinite, has no begin/end, in most cases). But I do think that a wrapper stream could add such feature, we only have to implement one and agree on the API (and the buffer size should probably be limited in size). I am curious though, why do you need it ? I mean, I got away (and try hard) to only use 1-element peeking and managed to implement STON, NeoJSON, NeoCSV, Stomp, PostgresSQL, Redis, and other protocols. A syntax that really requires multi element peeking is not so common. Sven
