<div class="gmail_quote">On Tue, Jul 27, 2010 at 07:20, Andrei Alexandrescu <span dir="ltr">&lt;<a href="mailto:SeeWebsiteForEmail@erdani.org">SeeWebsiteForEmail@erdani.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><div class="im">* slicing a sorted range should produce a sorted range. so your wrapper range opIndex must be modified to account for this.<br>
</div>
<br>
Cool, makes sense.<br>
<br></blockquote><div><br><br>Another thing, though I&#39;m not sure it&#39;s a good idea, it to have them define an opIndex[ElementType!R e], that would just either forward to .find() or do a simple binary search by itself: O(lg(n)) is quite good.<br>
 <br>Yeah, isAssociativeRange!R  ;)<br>But that&#39;s blurring the line between container and range, I guess. <br><br><br>In the same vein, a sorted range could optionally define opIn_r that also promises O(lg(n)) complexity. <br>
<br>As for taking ideas from other languages: in Clojure, data structures 
for which it makes sense (maps, sets?) are functions of their element and
 return true if the provided value is in the structure. That allows one 
to use them as predicate for finding and such, which makes for very 
clean code, as they also have encoded literal values. <br>
<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
* ditto for .save()<br>
</blockquote>
<br>
Yah.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
* Take(sortedRange, 5) should indicate it&#39;s also sorted.<br>
</blockquote>
<br></div>
Fortunately take already returns the type of the slice if the range supports slice, so that&#39;s in place already.</blockquote><div><br>I was about to reply that not all sorted ranges have slicing, but I think it&#39;s better to restrict this to &#39;rich&#39; ranges: Random-Access and slicing. So, OK.<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
* The same for retro(sorted), but with a predicate being Not!pred (or something akin to this anyway)<br>
</blockquote>
<br></div>
Whoa, interesting.</blockquote><div><br>It&#39;s the only case where I found that you could act on the predicate without analyzing it. <br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
* filter ! predicate (sortedRange) is also sorted<br>
* stride<br>
etc, etc.<br>
</blockquote>
<br></div>
Yah... that is all cool. My only reservations are that with what we have right now this looks like a lot of manual special casing. By the way, chain() with ranges sorted with the same predicate is also sorted...<br>
<br>
Then, such an effort would be much better motivated if sorted ranges had some really interesting properties. Aside from those discussed - there&#39;s not a lot of them!<br></blockquote><div><br>Yes, I agree. Maybe for retro() it&#39;s interesting, as retro could replace foreach_reverse...<br>
<br>Btw, should they really be called &quot;sorted&quot; or &quot;ordered&quot;? &quot;sorted&quot; implies there was a sorting action, which is not always the case. It may very well have been created that way.<br><br>Maybe (just maybe, I&#39;m extending myself there) it&#39;s because you tend to use ranges this way:<br>
<br>- read from a file some content over which you had no control.<br>- act on the read stuff, most probably sort it to prepare for the real action<br>- do the heavy-duty computation.<br><br>Whereas I tend to produce my own ranges, so I design them to be ordered/sorted, always positive or whatever.<br>
<br><br>Philippe<br><br></div></div>