Proposal for SentinelInputRange

[Artur Skawina]

On 02/28/13 16:00, Jacob Carlborg wrote:
> On 2013-02-28 15:47, Artur Skawina wrote:
> 
>> Define "fast". Lexing std.datetime takes at most ~10-20ms (possibly a single-digit
>> ms number, but i'd need to write some code to check the actual number). Smaller
>> objects take proportionally less. Meaning you'll be I/O bound, even /one/ (disk)
>> cache miss will have more impact then these kind of optimizations.
>> Lexing a hundred small files or one 100x as big file is basically the same operation;
>> the difference will be in I/O + setup/teardown costs, which will be /outside/ the
>> lexer, so aren't affected by how it accesses input.
> 
> You'll have to convince Walter.

Actually, no -- like i said: /I'd like to have such std ranges/ - there are
real gains to be had. I'm just saying that for the "fast lexer" case the
/absolute/ improvement isn't necessarily very large. Modern compilers can do
wonders.

The advantage of defining /std/ range types is, well, that they are "std";
everybody doesn't have to reinvent them, often with inadequate docs and
subtle differences in behavior. In this case the interesting properties are:

a) terminating sentinel
b) limited lookahead ("a" is a special case of "b")
c) lazyness

It's better to have a common interface than having everybody invent a
private one every time some of the above features are needed. 


artur