buffered input

[Andrei Alexandrescu]

On 2/5/11 5:09 AM, Jonathan M Davis wrote:
> Hmm. I think that I'd have to have an actual implementation to mess around with
> to say much. My general take on buffered input is that I don't want to worry
> about it. I want it to be buffered so that it's more efficient, but I don't want to
> have to care about it in how I use it. I would have expected a buffered input
> range to be exactly the same as an input range except that it doesn't really
> just pull in one character behind the scenes. It pulls in 1024 or whatever when
> popFront() would result in the end of the buffer being reached, and you just get
> the first one with front. The API doesn't reflect the fact that it's buffered at
> all except perhaps in how you initialize it (by telling how big the buffer is,
> though generally I don't want to have to care about that either).

Transparent buffering sounds sensible but in fact it robs you of 
important capabilities. It essentially forces you to use grammars with 
lookahead 1 for all input operations. Being able to peek forward into 
the stream without committing to read from it allows you to e.g. do 
operations like "does this stream start with a specific word" etc. As soon

Andrei