Phobos Wish List/Next in Review Queue?

[Steven Schveighoffer]

On Mon, 28 Nov 2011 08:18:38 -0500, so <so at so.so> wrote:

> On Mon, 28 Nov 2011 14:54:07 +0200, Steven Schveighoffer  
> <schveiguy at yahoo.com> wrote:
>
>> On Sat, 26 Nov 2011 16:39:38 -0500, Walter Bright  
>> <newshound2 at digitalmars.com> wrote:
>>
>>> On 11/26/2011 5:46 AM, Steven Schveighoffer wrote:
>>>> Ranges are not good for reading N bytes from a file
>>>> descriptor.
>>>
>>> Why not? Isn't that exactly what a range is supposed to be good for?
>>
>> A range has a specific interface:
>>
>> T front()
>> void popFront()
>> bool empty()
>>
>> An input stream has a specific interface:
>>
>> size_t read(ubyte[] buffer)
>> or alternatively:
>> ubyte[] read(ubyte[] buffer)
>>
>> How does one map that interface into an input range?  What is T?  I  
>> remember proposals where there was some extra function setFrontBytes,  
>> or an additional parameter to front, that allows you to set the number  
>> of bytes to read.  This seems like trying to fit a square peg in a  
>> round hole.
>>
>> Now, a range fits very well on top of an input stream with a given  
>> context.  That context defines *what* front() is going to return.  For  
>> example, the next line of text.
>>
>> But you still need a well-designed buffered stream interface that a  
>> range can use to do its work from.  Streams are not going to be the  
>> main interface for most users, but they will be the tools that range  
>> developers use to create easily iterated streams.  And when the user  
>> wants to read data from a file that has no well-defined T that you can  
>> define a range for, the stream should provide all the tools necessary  
>> to read that data.
>>
>> Now, an output stream *does* fit quite well as a range, since an output  
>> range's single put method coincides with an ouptut stream's write  
>> method.
>>
>> -Steve
>
> I was absent from range discussions, probably it has been said, sorry.
>
> A ### range means, a structure which implements:
>
> T front()
> void popFront()
> bool empty()
>
> This matches with:
>
> T peek()
> void seek(1)
> bool eof()
>
> T is ubyte.

The task is not to see if a stream can implement a range, it's to see if a  
range can implement a stream.  The target interface is the read function I  
mentioned.

Nobody wants to use the "one byte at a time" input range to interface with  
streams.  This just furthers my point.

> I believe we are asking the wrong questions, first question should be  
> why someone would like this simple range interface (3 functions) for  
> streams?
> Any use? Yes with these 3 we can do quite many things, not optimal but  
> we can. For the real use we need a new range.
>
> T[] get(size_t)
> bool put(size_t, T[])
> bool seek(size_t)
> ...
>
> Don't we need a range like this in any case? I doubt we can do much  
> without it.

Yes, but let's not call this a "range", since it does not work in  
functions that use ranges or with foreach (this is Walter's goal).

Ranges on top of streams make sense.  The most classic is byLine.  But  
byLine is not going to use a range interface to do it's underlying work.

IMO the layers from lowest to highest are:

device stream -> buffered stream -> range

In fact, that's *exactly* what phobos does today.  buffered stream (and  
the underlying device stream) is FILE *.

I'm working on a replacement for FILE * which allows much more  
flexibility, performance, while std.stdio will maintain the exact same  
interface.

-Steve