VLERange: a range in between BidirectionalRange and RandomAccessRange

[spir]

On 01/18/2011 07:11 AM, Andrei Alexandrescu wrote:
> On 1/17/11 11:48 PM, Jonathan M Davis wrote:
>> On Monday 17 January 2011 15:13:42 spir wrote:
>>> See range bug evoked above. opApply is the only workaround AFAIK.
>>> Also, ranges cannot yet provide indexed iteration like
>>> foreach(i, char ; text) {...}
>>
>> While it would be nice at times to be able to have an index with
>> foreach when
>> using ranges, I would point out that it's trivial to just declare a
>> variable
>> which you increment each iteration, so it's easy to get an index even
>> when using
>> foreach with ranges. Certainly, I wouldn't consider the lack of index
>> with
>> foreach and ranges a good reason to use opApply instead of ranges.
>> There may be
>> other reasons which make it worthwhile, but it's so trivial to get an
>> index that
>> the loss of range abilities (particularly the ability to use such
>> ranges with
>> std.algorithm) dwarfs it in importance.
>>
>> - Jonathan M Davis
>
> It's a bit more difficult than that. When iterating a variable-length
> encoded range, what you need more than the current item being iterated
> is the physical offset reached inside the range. That's not all that
> difficult either as the range can always provide an extra primitive, but
> a bit annoying (e.g. because it makes iteration with foreach impossible
> if you want the index, unless you return a tuple with each step).

This is a very valid point: a range's logical offset is not necessary 
equal to physical (hum) offset, even on a plain sequence.
But for the case of Text it is in fact, precisely because codepoints 
have been grouped in "piles" each representing true character 
(grapheme). This is actually one third of the purpose of Text (the 
others beeing to ensure unique representation of each character, and to 
provide users with clear interface).
Thus, Jonathan's point simply applies to Text.

> At any rate, I agree with two things - one, we need to fix the foreach
> situation. Two, even before we find a fix, at this point committing to
> iteration with opApply essentially commits the iteratee to an island
> where all basic algorithms need to be reinvented from first principles.

I agree. The situation would be different if D had not proposed indexed 
iteration already, and programmers would routinely count manually and/or 
call an extra range primitive, as you say.

Upon using opApply: it works fine nevertheless, at least for a first 
rough implementation like in the case of Text.
Reinventing basic algos is not an issue at this stage, as long as they 
are simple enough, and mainly for testing. (Actually, it can be an 
advantage in avoiding integration issues, possibly due to D's current 
beta stage --I mean bugs that pop up only when combinng given features-- 
like we had eg with range & formatValue).

> Andrei

Denis
_________________
vita es estrany
spir.wikidot.com