I remember about a year and a half ago, there was talk of defining a wrapper module around ranges to make them more usable in cases where templates can't be used, such as virtual functions.  I've revisited that now that I'm cleaning up ranges.  I've created a fairly simple attempt at writing such a module.  (http://pastebin.com/aDew6Kgg)  This exercise has reinforced my conviction that about the only thing good about nominative typing is that it's easy to implement efficiently.

I decided to exclude ref access to elements and infiniteness propagation from the interface entirely because I couldn't see a good way to implement these.  I did, however, include assignable elements.  Please review this module and tell me whether it looks worth including in Phobos and if so, where.  Also, any suggestions on better naming would be greatly appreciated.

On 08/19/2010 10:42 PM, David Simcha wrote:
> I remember about a year and a half ago, there was talk of defining a wrapper module around ranges to make them more usable in cases where templates can't be used, such as virtual functions. I've revisited that now that I'm cleaning up ranges. I've created a fairly simple attempt at writing such a module. (http://pastebin.com/aDew6Kgg) This exercise has reinforced my conviction that about the only thing good about nominative typing is that it's easy to implement efficiently.

Well structural systems (which current ranges are) are also pretty easy to implement efficiently. Anyway, signs of OO clusterfrak are already visible in the explosion of iXxxAssignable interfaces.

Could you please add moveFront() and friends to the interfaces? Given that you've given up on ref returns (which I believe is a sound decision) we need some efficient means to destructively read stuff.

> I decided to exclude ref access to elements and infiniteness propagation
> from the interface entirely because I couldn't see a good way to
> implement these.
> I did, however, include assignable elements. Please
> review this module and tell me whether it looks worth including in
> Phobos and if so, where. Also, any suggestions on better naming would be
> greatly appreciated.

For starters, all types should start with a capital letter :o).

I think this is solid work that belongs to Phobos; thanks for doing it. The function runtimeRange will be the flagship of this module, and I hope we can find a very representative and memorable name for it. "runtimeRange" itself is no slouch, but I'm hoping for something even more descriptive. One problem is that the process of uniformizing templates under a common binary interface is not well known and not known under one definite name in all circles.

Here are some thoughts:

// weird typed range
auto r = chain(retro([1, 2]), SList!int(3, 4)[]);
// make it into a "nice" range
auto r1 = uniformize(r);
auto r1 = dynamic(r);
auto r1 = dynRange(r);
auto r1 = objectify(r);
auto r1 = rangeObject(r);
auto r1 = abiRange(r);

Of these, I guess I like rangeObject(r) the most. "Get me a range Object outta this range with some clusterfrak type."

Again, this is strong work. Congratulations, David.

About the code's place, I think it would simply belong inside std.range.


Andrei

On 8/20/2010 12:01 AM, Andrei Alexandrescu wrote:
> On 08/19/2010 10:42 PM, David Simcha wrote:
>> I remember about a year and a half ago, there was talk of defining a wrapper module around ranges to make them more usable in cases where templates can't be used, such as virtual functions. I've revisited that now that I'm cleaning up ranges. I've created a fairly simple attempt at writing such a module. (http://pastebin.com/aDew6Kgg) This exercise has reinforced my conviction that about the only thing good about nominative typing is that it's easy to implement efficiently.
>
> Well structural systems (which current ranges are) are also pretty easy to implement efficiently. Anyway, signs of OO clusterfrak are already visible in the explosion of iXxxAssignable interfaces.
>
> Could you please add moveFront() and friends to the interfaces? Given that you've given up on ref returns (which I believe is a sound decision) we need some efficient means to destructively read stuff.

Added moveFront, moveBack, moveAt and capitalized things.  For some reason I thought interface names were excluded from the capitalize typename convention if you're using the Hungarian IInterfaceName style. It may make sense to just drop the Hungarian stuff, but I don't know if D has a firm convention either way yet on using Hungarian for interfaces.

http://pastebin.com/sHiTNABe

Also, I found some nasty moveBack/moveAt bugs in std.range in the process, namely no default impl. for ranges of elements w/o postblits. I have no idea how they went this long without being found/fixed.

In addition to the changes I made last night, I've also made the following changes:

1.  Change name to inputRangeObject/InputRangeObject.
2.  Add support for output ranges as outputRangeObject/OutputRangeObject.
3.  Remove the now ridiculous looking Hungarian notation on the interfaces.

http://pastebin.com/U83YNJfJ is where it's at.

Any more comments from anyone, or does this look ready to be checked in?

On 8/20/2010 12:01 AM, Andrei Alexandrescu wrote:
> On 08/19/2010 10:42 PM, David Simcha wrote:
>> I remember about a year and a half ago, there was talk of defining a wrapper module around ranges to make them more usable in cases where templates can't be used, such as virtual functions. I've revisited that now that I'm cleaning up ranges. I've created a fairly simple attempt at writing such a module. (http://pastebin.com/aDew6Kgg) This exercise has reinforced my conviction that about the only thing good about nominative typing is that it's easy to implement efficiently.
>
> Well structural systems (which current ranges are) are also pretty easy to implement efficiently. Anyway, signs of OO clusterfrak are already visible in the explosion of iXxxAssignable interfaces.
>
> Could you please add moveFront() and friends to the interfaces? Given that you've given up on ref returns (which I believe is a sound decision) we need some efficient means to destructively read stuff.
>
>> I decided to exclude ref access to elements and infiniteness propagation
>> from the interface entirely because I couldn't see a good way to
>> implement these.
>> I did, however, include assignable elements. Please
>> review this module and tell me whether it looks worth including in
>> Phobos and if so, where. Also, any suggestions on better naming would be
>> greatly appreciated.
>
> For starters, all types should start with a capital letter :o).
>
> I think this is solid work that belongs to Phobos; thanks for doing it. The function runtimeRange will be the flagship of this module, and I hope we can find a very representative and memorable name for it. "runtimeRange" itself is no slouch, but I'm hoping for something even more descriptive. One problem is that the process of uniformizing templates under a common binary interface is not well known and not known under one definite name in all circles.
>
> Here are some thoughts:
>
> // weird typed range
> auto r = chain(retro([1, 2]), SList!int(3, 4)[]);
> // make it into a "nice" range
> auto r1 = uniformize(r);
> auto r1 = dynamic(r);
> auto r1 = dynRange(r);
> auto r1 = objectify(r);
> auto r1 = rangeObject(r);
> auto r1 = abiRange(r);
>
> Of these, I guess I like rangeObject(r) the most. "Get me a range Object outta this range with some clusterfrak type."
>
> Again, this is strong work. Congratulations, David.
>
> About the code's place, I think it would simply belong inside std.range.
>
>
> Andrei
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

David Simcha <dsimcha at gmail.com> wrote:
> In addition to the changes I made last night, I've also made the following changes:
> 
> 1.  Change name to inputRangeObject/InputRangeObject.
> 2.  Add support for output ranges as outputRangeObject/OutputRangeObject.
> 3.  Remove the now ridiculous looking Hungarian notation on the interfaces.
> 
> http://pastebin.com/U83YNJfJ is where it's at.
> 
> Any more comments from anyone, or does this look ready to be checked in?

Could you make OutputRangeObject able to accept multiple element types?

template outputRangeObject(E...) {
    auto outputRangeObject(R)(R range) { ... }
}


Shin

Hmm.  It's worth considering, but I see at least two problems.

1.  Do we have a practical use case for it?  I don't generally believe in adding complexity without clear use cases for said complexity.

2.  The base interface is OutputRange!(E).  If I change the base interface to OutputRange!(E...), then OutputRange!(uint, double) won't be a subtype of OutputRange!(uint).  This is self-evidently ridiculous. I could maybe make OutputRangeObject!(E...) inherit from OutputRange!(E[0]), OutputRange!(E[1]), ..., OutputRange!(E[$ - 1]), but other than nasty string mixins D doesn't provide a way to inherit from a tuple of interfaces.

On 8/20/2010 9:26 PM, Shin Fujishiro wrote:
> David Simcha<dsimcha at gmail.com>  wrote:
> 
>> In addition to the changes I made last night, I've also made the following changes:
>>
>> 1.  Change name to inputRangeObject/InputRangeObject.
>> 2.  Add support for output ranges as outputRangeObject/OutputRangeObject.
>> 3.  Remove the now ridiculous looking Hungarian notation on the interfaces.
>>
>> http://pastebin.com/U83YNJfJ is where it's at.
>>
>> Any more comments from anyone, or does this look ready to be checked in?
>> 
> Could you make OutputRangeObject able to accept multiple element types?
>
> template outputRangeObject(E...) {
>      auto outputRangeObject(R)(R range) { ... }
> }
>
>
> Shin
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
> 

David Simcha <dsimcha at gmail.com> wrote:
> Hmm.  It's worth considering, but I see at least two problems.
> 
> 1.  Do we have a practical use case for it?  I don't generally believe in adding complexity without clear use cases for said complexity.

I'm not sure.  I/O-related ranges tend to have chunk-writing overloads:

  void put(E value);
  void put(E[] chunk);

And the Appender has a similar overload for bulk appending.  But such ranges can work with only one of those overloads.


> 2.  The base interface is OutputRange!(E).  If I change the base interface to OutputRange!(E...), then OutputRange!(uint, double) won't be a subtype of OutputRange!(uint).  This is self-evidently ridiculous. I could maybe make OutputRangeObject!(E...) inherit from OutputRange!(E[0]), OutputRange!(E[1]), ..., OutputRange!(E[$ - 1]), but other than nasty string mixins D doesn't provide a way to inherit from a tuple of interfaces.

Oh, really?  That's bad.  I thought tuples could be used in the class inheritance list.  IIRC something like the following also does not work due to a deep inheritance bug:

interface OutputRange(E...) : OutputRange!(E[1 .. $]) {
    void put(E[0] e);
}

Then, maybe we should put off supporting this anyway...


> On 8/20/2010 9:26 PM, Shin Fujishiro wrote:
> > David Simcha<dsimcha at gmail.com>  wrote:
> > 
> >> In addition to the changes I made last night, I've also made the following changes:
> >>
> >> 1.  Change name to inputRangeObject/InputRangeObject.
> >> 2.  Add support for output ranges as outputRangeObject/OutputRangeObject.
> >> 3.  Remove the now ridiculous looking Hungarian notation on the interfaces.
> >>
> >> http://pastebin.com/U83YNJfJ is where it's at.
> >>
> >> Any more comments from anyone, or does this look ready to be checked in?
> >> 
> > Could you make OutputRangeObject able to accept multiple element types?
> >
> > template outputRangeObject(E...) {
> >      auto outputRangeObject(R)(R range) { ... }
> > }

Wow, you're right.  You can implement a tuple of interfaces.  When I wrote the last email saying you couldn't it was late at night in my time zone.  I didn't bother double-checking because I had never seen such a thing documented or done before.  I got your requested feature of implementing multiple output types working at the small cost of having to use a string mixin to write the put methods, since static foreach never made the cut.  The latest revision is at http://pastebin.com/azM0Xnqh .

On 8/21/2010 12:06 AM, Shin Fujishiro wrote:
> David Simcha<dsimcha at gmail.com>  wrote:
> 
>> Hmm.  It's worth considering, but I see at least two problems.
>>
>> 1.  Do we have a practical use case for it?  I don't generally believe
>> in adding complexity without clear use cases for said complexity.
>> 
> I'm not sure.  I/O-related ranges tend to have chunk-writing overloads:
>
>    void put(E value);
>    void put(E[] chunk);
>
> And the Appender has a similar overload for bulk appending.  But such ranges can work with only one of those overloads.
>
>
> 
>> 2.  The base interface is OutputRange!(E).  If I change the base
>> interface to OutputRange!(E...), then OutputRange!(uint, double) won't
>> be a subtype of OutputRange!(uint).  This is self-evidently ridiculous.
>> I could maybe make OutputRangeObject!(E...) inherit from
>> OutputRange!(E[0]), OutputRange!(E[1]), ..., OutputRange!(E[$ - 1]), but
>> other than nasty string mixins D doesn't provide a way to inherit from a
>> tuple of interfaces.
>> 
> Oh, really?  That's bad.  I thought tuples could be used in the class inheritance list.  IIRC something like the following also does not work due to a deep inheritance bug:
>
> interface OutputRange(E...) : OutputRange!(E[1 .. $]) {
>      void put(E[0] e);
> }
>
> Then, maybe we should put off supporting this anyway...
>
>
> 
>> On 8/20/2010 9:26 PM, Shin Fujishiro wrote:
>> 
>>> David Simcha<dsimcha at gmail.com>   wrote:
>>>
>>> 
>>>> In addition to the changes I made last night, I've also made the following changes:
>>>>
>>>> 1.  Change name to inputRangeObject/InputRangeObject.
>>>> 2.  Add support for output ranges as outputRangeObject/OutputRangeObject.
>>>> 3.  Remove the now ridiculous looking Hungarian notation on the interfaces.
>>>>
>>>> http://pastebin.com/U83YNJfJ is where it's at.
>>>>
>>>> Any more comments from anyone, or does this look ready to be checked in?
>>>>
>>>> 
>>> Could you make OutputRangeObject able to accept multiple element types?
>>>
>>> template outputRangeObject(E...) {
>>>       auto outputRangeObject(R)(R range) { ... }
>>> }
>>> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
> 

I think that's a good suggestion that hasn't been implemented yet. Is there a practical reason, or just not getting to it?

Thanks,

Andrei

On 8/20/10 20:26 CDT, Shin Fujishiro wrote:
> David Simcha<dsimcha at gmail.com>  wrote:
>> In addition to the changes I made last night, I've also made the following changes:
>>
>> 1.  Change name to inputRangeObject/InputRangeObject.
>> 2.  Add support for output ranges as outputRangeObject/OutputRangeObject.
>> 3.  Remove the now ridiculous looking Hungarian notation on the interfaces.
>>
>> http://pastebin.com/U83YNJfJ is where it's at.
>>
>> Any more comments from anyone, or does this look ready to be checked in?
>
> Could you make OutputRangeObject able to accept multiple element types?
>
> template outputRangeObject(E...) {
>      auto outputRangeObject(R)(R range) { ... }
> }
>
>
> Shin
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

The practical case is very simple - a formatter accepts a lot of types.

Andrei

On 8/20/10 20:35 CDT, David Simcha wrote:
> Hmm. It's worth considering, but I see at least two problems.
>
> 1. Do we have a practical use case for it? I don't generally believe in adding complexity without clear use cases for said complexity.
>
> 2. The base interface is OutputRange!(E). If I change the base interface
> to OutputRange!(E...), then OutputRange!(uint, double) won't be a
> subtype of OutputRange!(uint). This is self-evidently ridiculous. I
> could maybe make OutputRangeObject!(E...) inherit from
> OutputRange!(E[0]), OutputRange!(E[1]), ..., OutputRange!(E[$ - 1]), but
> other than nasty string mixins D doesn't provide a way to inherit from a
> tuple of interfaces.
>
> On 8/20/2010 9:26 PM, Shin Fujishiro wrote:
>> David Simcha<dsimcha at gmail.com> wrote:
>>> In addition to the changes I made last night, I've also made the following changes:
>>>
>>> 1. Change name to inputRangeObject/InputRangeObject.
>>> 2. Add support for output ranges as outputRangeObject/OutputRangeObject.
>>> 3. Remove the now ridiculous looking Hungarian notation on the
>>> interfaces.
>>>
>>> http://pastebin.com/U83YNJfJ is where it's at.
>>>
>>> Any more comments from anyone, or does this look ready to be checked in?
>> Could you make OutputRangeObject able to accept multiple element types?
>>
>> template outputRangeObject(E...) {
>> auto outputRangeObject(R)(R range) { ... }
>> }
>>
>>
>> Shin
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos