In wake of the many excellent comments and suggestions made here, I made one more pass through the draft proposal for ranges.

http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

There are some comments in red illustrating some uncertainties (not all), and the names of the primitives have been updated. Bicycle shed galore! But don't forget to comment on the reactor as well :o).


Andrei

Andrei Alexandrescu wrote:
> In wake of the many excellent comments and suggestions made here, I made one more pass through the draft proposal for ranges.
> 
> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
> 
> There are some comments in red illustrating some uncertainties (not all), and the names of the primitives have been updated. Bicycle shed galore! But don't forget to comment on the reactor as well :o).

Well done. I think the design has come together very nicely. I'm especially happy with all the new names, which make a big difference for me in being able to visualize how the proposal works. The old names (fromLeft, etc) were very opaque to me.

(btw: head & toe? i love it!)

In its current state, this actually gets me pretty excited about D2. Maybe even enough to finally slog my way through all the const stuff.

One tiny typo, though: In the "Forward range" section, the code sample still uses "left" instead of "head".

And, there are two sections (which I think are related to one another) that left me scratching my head:

Input Ranges:
"In case ElementType!(R) has aliases (such as a reference, pointer, or array type), the iterator is free to recycle it it upon the call to r.next, so client code must do a deep copy if preserving the value is needed. [NOTE: This is a weakness in the design. A better way of figuring recycling should be found.] The call is defined only right after r.done returned false."

Forward Ranges:
"Also, forward ranges iterate over "real" elements, which makes in-place mutation of r.head possible."

Those paragraphs are completely greek to me. Can you elaborate?

--benji

Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> In wake of the many excellent comments and suggestions made here, I made one more pass through the draft proposal for ranges.
> 
> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
> 
> There are some comments in red illustrating some uncertainties (not all), and the names of the primitives have been updated. Bicycle shed galore! But don't forget to comment on the reactor as well :o).

I propose to finally move to D group from D.announce.  The best way would be to post your announcement there.

On Fri, Sep 12, 2008 at 2:44 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> In wake of the many excellent comments and suggestions made here, I made one more pass through the draft proposal for ranges.
>
> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
>
> There are some comments in red illustrating some uncertainties (not all), and the names of the primitives have been updated. Bicycle shed galore! But don't forget to comment on the reactor as well :o).

Reactor?  You meant "refactor" maybe?


--bb

Andrei Alexandrescu:

In some situations (longer functions, where there are 2 or more types, etc) It may be better to use longer & more descriptive names for types, instead of E T etc.

Bye,
bearophile

Andrei Alexandrescu Wrote:

> In wake of the many excellent comments and suggestions made here, I made one more pass through the draft proposal for ranges.
> 
> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
> 
> There are some comments in red illustrating some uncertainties (not all), and the names of the primitives have been updated. Bicycle shed galore! But don't forget to comment on the reactor as well :o).
> 
> 
> Andrei


Well, it looks prety clean! :D

However, I'm not completely sure I like these "head" and "toe" names selection.  It projects to much on it, doesn't it?  couldn't it be more neutral?  perhaps more conceptual?  I haven't been able to read the last days' comments... but my last impressions were that this "head" was not the best choice.

If "head" is the header item, why not call it "header"?

If ''toe" is the last item, why not call it "last"?

Other comment goes for the "done" property, for the seek of consistence shouldn't it better be named "isDone"?

Cheers!

Benji Smith wrote:
> Andrei Alexandrescu wrote:
>> In wake of the many excellent comments and suggestions made here, I made one more pass through the draft proposal for ranges.
>>
>> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
>>
>> There are some comments in red illustrating some uncertainties (not all), and the names of the primitives have been updated. Bicycle shed galore! But don't forget to comment on the reactor as well :o).
> 
> Well done. I think the design has come together very nicely. I'm especially happy with all the new names, which make a big difference for me in being able to visualize how the proposal works. The old names (fromLeft, etc) were very opaque to me.
> 
> (btw: head & toe? i love it!)
> 
> In its current state, this actually gets me pretty excited about D2. Maybe even enough to finally slog my way through all the const stuff.
> 
> One tiny typo, though: In the "Forward range" section, the code sample still uses "left" instead of "head".

Fixed, thanks.

> And, there are two sections (which I think are related to one another) that left me scratching my head:
> 
> Input Ranges:
> "In case ElementType!(R) has aliases (such as a reference, pointer, or array type), the iterator is free to recycle it it upon the call to r.next, so client code must do a deep copy if preserving the value is needed. [NOTE: This is a weakness in the design. A better way of figuring recycling should be found.] The call is defined only right after r.done returned false."
> 
> Forward Ranges:
> "Also, forward ranges iterate over "real" elements, which makes in-place mutation of r.head possible."
> 
> Those paragraphs are completely greek to me. Can you elaborate?

Consider iterating over an array of int[], specifically an int[][]. Then when you call r.head you see the current int[]. You can store it and use it a few steps later or even after the iteration is done for as long as the array is around.

Contrast that with iterating a file containing lines of integers. The file has a buffer of type int[]. Every time you call r.next, the file range reads a new line, parses the integers, and REFILLS the array with them. If if generated a new array every line, that would cause a great deal of allocations.

Same about the in-place thing. If you modify elements in the array, they stay modified. If you modify the buffer of a file, your changes get overwritten upon r.next.


Andrei

Bill Baxter wrote:
> On Fri, Sep 12, 2008 at 2:44 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> In wake of the many excellent comments and suggestions made here, I made one
>> more pass through the draft proposal for ranges.
>>
>> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
>>
>> There are some comments in red illustrating some uncertainties (not all),
>> and the names of the primitives have been updated. Bicycle shed galore! But
>> don't forget to comment on the reactor as well :o).
> 
> Reactor?  You meant "refactor" maybe?

I think the original bicicle shed story was about a nuclear plant design including a bicycle shed. So I meant to ask you to comment about the nuclear reactor, not only the bicycle shed.


Andrei

bearophile wrote:
> Andrei Alexandrescu:
> 
> In some situations (longer functions, where there are 2 or more types, etc) It may be better to use longer & more descriptive names for types, instead of E T etc.
> 
> Bye,
> bearophile

Fixed, thanks.

Andrei

Pablo Ripolles wrote:
> Andrei Alexandrescu Wrote:
> 
>> In wake of the many excellent comments and suggestions made here, I made one more pass through the draft proposal for ranges.
>>
>> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
>>
>> There are some comments in red illustrating some uncertainties (not all), and the names of the primitives have been updated. Bicycle shed galore! But don't forget to comment on the reactor as well :o).
>>
>>
>> Andrei
> 
> 
> Well, it looks prety clean! :D
> 
> However, I'm not completely sure I like these "head" and "toe" names selection.  It projects to much on it, doesn't it?  couldn't it be more neutral?  perhaps more conceptual?  I haven't been able to read the last days' comments... but my last impressions were that this "head" was not the best choice.
> 
> If "head" is the header item, why not call it "header"?
> 
> If ''toe" is the last item, why not call it "last"?
> 
> Other comment goes for the "done" property, for the seek of consistence shouldn't it better be named "isDone"?
> 
> Cheers!

Thanks. One problem in coding with first and last was that sometimes the code looks unnatural, especially when your range exposes a few more functions. In a stream parser, dealing with the "first" element is not the most natural way to think of it. But I agree that first and last are definitely palatable and natural most of the time. But then again, shouldn't any design have the inevitable cutesy that makes it memorable? :o)

Andrei