range stuff

[Chris Nicholson-Sauls]

Andrei Alexandrescu wrote:
> Michel Fortin wrote:
>> On 2009-02-16 20:21:00 -0500, superdan <super at dan.org> said:
>>
>>> a'ight i've read all range stuff n ruminated on it for a while. yer 
>>> ranges suck goat balls. something's amiss.
>>>
>>> yer have ranges that generate stuff.  some even ferever. then yer 
>>> have ranges that eat stuff output ranges that is. but there's no 
>>> range that has both input and output. some sort of filter ranges. yer 
>>> should connect stuff together to get chains n stuff. see? i'm sayin': 
>>> why would ya have a piehole & an asshole if yer don't have a stomach.
>>>
>>> i/o ranges are a missing link. if yer smart u can unify range stuff 
>>> and stream stuff together. then stream or range it's all the same. 
>>> not sure its possible but if it is only yer can pull it. that would 
>>> be dogs bollocks.
>>
>> Interesting. In fact I started a prototype of some kind of filter 
>> range for tokenizing XML: takes characters and gives tokens. That 
>> said, what you get is an input range (you can read tokens) that you 
>> build from an other input range (character range). So while it may fit 
>> the definition of a filter range, it may not be what you're thinking 
>> about.
>>
>> What you want, an output range linked to an input range makes me think 
>> of the XmlEventReaderToWriter class in BerkelyDB XML, although in 
>> reverse (writer to reader) since ranges aren't pushing events, but 
>> pulling data when requested.
>> <http://www.oracle.com/technology/documentation/berkeley-db/xml/api_cxx/frame.html> 
>>
>>
> 
> I think filtering ranges are a great idea. Some were already present 
> without a formal interface, e.g. map has an input and an output. All I 
> need is to define a common interface for connecting a range to another. 
> To that end, I will proclaim that if a range has the primitive
> 
> setInput(SomeRange input)
> 
> then it is a filtering range. This will be very useful for e.g. 
> transcoding (we'll need at some point to rewrite std.encoding): a 
> newly-defined character type SomeChar must define a filtering range that 
> eats ranges of SomeChar and outputs dchar, and also a filtering range 
> that eats dchar and produces SomeChar. Then that filter can be used to 
> transfer characters across strings but also any combination of ranges 
> including files.
> 
> 
> Andrei

Which would, incidentally, not only be a godsend for folks who still 
need to work with non-Unicode text once in a while -- typedef'ing ubyte 
just possibly became useful -- but also potentially simplifies bridging 
between protocols, incremental multiple dispatch (if each range is also 
a dispatcher for example), structure-to-structure conversions, and a 
whole host of other nifties.

-- Chris Nicholson-Sauls