Permalink
Reply
With D3 either from phoboes or open d I was hoping there be the will to update the range api to be just better, from my half dozen posts trying to get something started; thats clearly not the case.
A brief history of how d's iterators came about as I understand it is: stepov wanted to make the bestest data structure and algorithm lib ever, he tried several languages before compromising and choosing c++ and the inadvertently turing complete templates; before c++ made any real usability decisions, before anyone had any practice with these things. Stl is successful, aa takes the "slices > pointers" idea, looks at stl iterators being based on pointers and makes a quick edit making "ranges" looks around find walter and makes some template api requests that he largely got. Again before anyone had practice or theory with d templates or the full feature set was in place. Theres no reason to believe ranges have the best possible api for d with a full feature set and a decade of practice with template metaprogramming with d's features.
I highly suggest that changing the range api design to be post- everyone practice and knowledge of templates and not based on some essays for c++ in the 90's
I made this proof of concept for a different api I thought would be better https://gist.github.com/crazymonkyyy/308bf3387ceec5c84883678d0fc097a7
To summarize I believe iteration and "shaping" should be separated; while ranges are "views of data" they should get a "key" from an array reference that should be a "smart reference" to real data. Rather then the stl concept of random access iterators being a subset of bi-directional iterators.
For the simplest possible version id suggest
range:
front
pop
empty
//optional
key
length
array:
opIndex(typeof(opSlice()).key)
opIndex(typeof(opDollar))
opSlice() (returns a range)
opDollar
//optional
opSlice(typeof(opSlice[].key),typeof(opDollar)) (returns an array)
For a phoboes version probably keep bidirectional for backward compatibility and whatever computer science theory that loves doubly linked lists, while deprecating "random access ranges".
To clarify the difference, sorting a range in this paradigm is incoherent, reducing an array without an opSlice is incorrect.
On fundamental vs composite algorithms; if you look at my code theres several extremely small blocks of code, my original notes where 10 fundamental algorithms and 34 composite algorithms, I still believe that phoboes is held back by refusing "to simple" "not optimized" code that can be an unituitive combination of the more fundamental algorithms(you can easily make max with reduce, you cant make reduce with max) however my plan of 1:3 was to greedy and I would suggest 1:2.5
