buffered input

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:iijpp7$197f$1 at digitalmars.com...
> 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
>

That shouldn't be a problem for the cases where a lookahead of 1 is all 
that's needed. So both types can exist (with the traditional/automatic type 
most likely built on top of Andrei's type). Thus, I think the only question 
is "Are the appropriate use-cases for the traditional/automatic type minor 
enough and infrequent enough to actively discourage it by not providing it?" 
That I can't answer.