On Sunday, 29 December 2013 at 22:02:57 UTC, Dmitry Olshansky
wrote:
[snip]
Hmm, just yesterday I was rewriting a parser to use a buffer
instead of loading the whole file in memory, so this is quite
timely for me.
Questions:
1. What happens when the distance between the pinned and current
position exceeds the size of the buffer (sliding window)? Is the
buffer size increased, or is the stream rewound if possible and
the range returned by the slice does seeking?
2. I don't understand the rationale behind the current semantics
of lookahead/lookbehind. If you want to e.g. peek ahead/behind to
find the first whitespace char, you don't know how many chars to
request. Wouldn't it be better to make these functions return the
ENTIRE available buffer in O(1)?
I guess I see the point when applied to regular expressions,
where the user explicitly specifies how many characters to look
ahead/behind. However, I think in most use cases the amount is
not known beforehand (without imposing arbitrary limitations on
users like "Thou shalt not have variable identifiers longer than
32 characters"), so the pattern would be "try a cheap
lookahead/behind, and if that fails, do an expensive one".
3. I think ideally the final design would use something like what
std.allocator does with "unbounded" and "chooseAtRuntime" - some
uses might not need lookahead or lookbehind or other features at
all, so having a way to disable the relevant code would benefit
those cases.
