buffered input

spir denis.spir at gmail.com
Sat Feb 5 16:53:46 PST 2011


On 02/05/2011 06:42 PM, Heywood Floyd wrote:
>
> 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.

+++ (everything above)

> 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.

pleased to see there is at least one other programmer still considering that 
"semantic" applies to human thoughts, rather than machine process...

> * * *
>
>
>
> 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 |

There is an off-by-one error between 1st & first, I guess ;-)
What's your "view window"? Is it buffer, or the needed amount of lookahead, or 
what else?
How would you draw the buffer, on the first picture or the one above?

"Sliding window" is, for me, the mental picture my brain intuitively forms when 
thinking at buffered input. But the sliding move may not be smooth (element per 
element), instead could happen as is most practical or efficient; as long as it 
remains a point not exposed on the interface (or only on request by client 
code). Meaning there would be an independant index pointing to 
current/first/front element, in the buffer or the window, & automagically 
maintained when sliding happens (index -= offset).

> 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

Veeery interesting message, thank you. I share your care for correct naming. 
And the rest, actually. Wish you would post regularly.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



More information about the Digitalmars-d mailing list