digitalmars.D - Array focused iterators
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
Apr 11
On Thursday, 11 April 2024 at 18:19:00 UTC, monkyyy wrote: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. 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.Why I see the simplification I have a few questions. Can you tell a learner what the benefits would be for an end user (programmer not implementing libraries). - Can this be extended for a complete substitution of Phobos' `std.algorithm`? - Would this allow for nogc or even -betterC throughout?
Apr 13
monkyyy <crazymonkyyy gmail.com> On Saturday, 13 April 2024 at 15:12:56 UTC, rkompass wrote:Can you tell a learner what the benefits would be for an end userRn std.sreaching sux. "CountUntil" is the right name for a wrong function for something slightly complex like unicode strings countUntil doesn't function as an indexOf because the information is dropped; if you had a .key in the interface you could filter a list and get a valid index/key trivailly and you could make better functions in general then the confusing mess of an api rn.- Can this be extended for a complete substitution of Phobos' `std.algorithm`?On a technical level, yes on a organization level, std algorithm has had 96 contributors over 10 years, I havnt convinced a single person this is important and have patience's for like 2 weeks alone- Would this allow for nogc or even -betterC throughout?Thats more a data structure question then an algorithms one
Apr 13