buffered input

[Heywood Floyd]

Nice!
And evenin'!



Layman's view:
- - - - - - - - - - -
(I'm serious, please don't take my post too seriously. I'm not a heavy user of D and I don't want to pollute. I know in NGs exposure means influence and I babble a lot. Still, my thoughts, or rather reactions, could be of interest, I assume, or I wouldn't be writing this : )


I'm not sure how these buffered input ranges are supposed to be used (some mockup sample code would be very cool!), but it seems to me, and please correct me if I'm wrong, that it's very desirable for these ranges to be interchangeable?

As in, you've built some library that passes around ranges, but then some part of it is slow and needs buffered ones. Isn't the point that you can then swap out your ranges for buffered ones here and there, but continue to have a functioning library?

Reusability, generics, bend the spoon neo and all that?

If not, then ok.

But if yes, then I think these buffered ranges look very troublesome! Naughty even!



* * *



Then there's the sneaky break of consistency of the D semantics.

Even if these ranges are not intended to be interchangeable, still, changing the (human langauge) semantics that the input ranges already define is not good! This makes D a difficult language to get an intuitive feel for, I think.

By the definition of input ranges, the word "front" symbolizes the first _element_ in a forwards facing queue of elements.

| 1:st |     	<-- front()
| 2:nd |   v-- hidden --v
| 3:rd |
| .....  |
| n:th | <-- "back"

..as front() returns a T.

Then follows that popFront() means "discard the first _element_, so that the element that was second now becomes first." And if we can agree to that, then shiftFront() is possibly very confusing, and so is appendToFront(). They sound like they operate on the first element! 

So it seems these buffered ranges have redefined the semantics for the word "front", as meaning "the view window into the front part of the queue". Sneaky!

I mean, imagine being new with D and skimming through the API docs for ranges, and picking up these function names at a glance. You'd be setting yourself up for one of those "aaahaa-now-I-get-why-I-didn't-get-it"-moments for sure. Hmmm.

Still, front() could very well refer to the "front part"—to a list of elements (or the "view window"), and first() could refer to the first element. Actually, that would make the most sense! Then an input range would be first()/popFirst()/empty(), and a buffered one would have all those, but also amend something like front(n)/widenFront(n)/popFront(n), but yeah, erhm.

I call for stricter and more consistent semantics!
Decide what "front" means when talking about ranges, and stick to it!
(And I'm talking about human language semantics, not what a function (or "primitive"?) does.)

Erh, I tried to sound resolute there. Not my thing really.



* * *



Besides that, "shiftFront" got me thinking about sliding windows, and that would actually be cool! As in

| 1st |   '\	     <-- first()
| 2nd |   |-- front() // "view window"
| 3rd |  ./
| 4th | v-- hidden --v
| 5th |
| ...... |
| n:th |

and then calling shiftFront(2) would shift the view window 2 elements forward (thus fetching 2 and discarding 2). Seems like a useful feature when parsing some encoding with variable point width and known distance to the "event horizon", no? As in

code.viewDistance = 8;
do{
	auto p = code.front()
	if(isLongPoint(p)){
		processLong(p)
		code.shiftFront(8);
	}else if(isPoint(p)){
		process(p)
		code.shiftFront(4);
	}else break;
}while(p);

or something like that.

But the semantic that "shiftFront" would mean the same as popFront(), but on a list of elements? Confusing! Surely, at least popFront(n)...

Hm, yeah
Ok I'm all out of coffee!!!
Thanks for your time!
BR
/HF