digitalmars.D - Shout out to D at cppcon, when talkign about ranges.
- deadalnix (4/4) Sep 29 2015 https://www.youtube.com/watch?v=mFUXNMfaciE
- deadalnix (9/13) Sep 29 2015 Shared on reddit:
- Arjan (4/20) Sep 30 2015 I had the same feeling, as a lot of the ideas clearly comes from
- Freddy (2/6) Sep 29 2015 So this is what APL feels like. /s
- Wyatt (3/4) Sep 30 2015 Nah, the APL version would be shorter and only use builtins. ;)
- Steven Schveighoffer (6/10) Sep 30 2015 Ditto!
- Andrei Alexandrescu (3/15) Sep 30 2015 One great action item is to backport some of Eric's ideas to the D
- H. S. Teoh via Digitalmars-d (57/75) Sep 30 2015 [...]
- lobo (22/48) Sep 30 2015 This is a key reason I am using D. I really like C++14+boost but
- bitwise (41/43) Sep 30 2015 Special features are not necessary to do this. C++ for loop works
- bitwise (5/9) Sep 30 2015 Curiosity got the best of me:
- lobo (6/16) Sep 30 2015 Yes, that's what we have always done with iterators. The point is
- bitwise (6/26) Sep 30 2015 I understand, but the C++ committee seems very conservative to
- Eric Niebler (24/28) Sep 30 2015 As of C++11, C++ has the for(auto e:range) control structure you
- deadalnix (16/44) Oct 01 2015 Well, yes and no. Sure I'm sure there are precedent for ranges,
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (10/14) Oct 05 2015 Yes, certainly in the 70s, but I would be surprised if something
- Walter Bright (32/37) Oct 01 2015 Range iteration over arrays have been around in D since the beginning
- Walter Bright (4/4) Oct 01 2015 Ranges because a D core language feature with D 2.021 Nov 25, 2008.
- Jack Stouffer (2/7) Oct 01 2015 Please be excited to see ranges in C++20
- Joakim (3/8) Oct 01 2015 That site is still up, at least for me:
- Walter Bright (10/21) Oct 01 2015 I have the Oct 2004 issue of CUJ where Matthew Wilson writes about range...
- =?UTF-8?Q?Ali_=c3=87ehreli?= (9/12) Oct 01 2015 Thank you for mining for that.
- Walter Bright (12/17) Oct 01 2015 It was Andrei's talk "Iterators Must Go" that was the turning point for ...
- Eric Niebler (2/4) Oct 02 2015 Why not?
- Walter Bright (18/22) Oct 02 2015 Because it returns iterators. It should expose functions (or operators) ...
- Steven Schveighoffer (12/32) Oct 05 2015 The solution to this is cursors. i.e. ranges that point at exactly one
- Eric Niebler (14/40) Oct 05 2015 For a D range, what happens if you popFront from an empty range?
- Walter Bright (8/25) Oct 05 2015 Yes, you can build debug iterators that know their limits, or iterators ...
- Eric Niebler (13/18) Oct 05 2015 The design of the D ranges and algorithms owe quite a lot to C++,
- Jonathan M Davis (6/23) Oct 05 2015 D's ranges and their use in D's standard library owe a _lot_ to
- Ulrich Kuettler (5/25) Oct 05 2015 There is no denying that D owns a lot to C++. Then again D comes
- Jonathan M Davis (14/24) Oct 06 2015 Obviously, Eric would have to respond for us to know what his
- Ulrich =?UTF-8?B?S8O8dHRsZXI=?= (7/33) Oct 06 2015 Yes, this is an explanation. Thanks. So the argument being C++
- Trass3r (2/11) Oct 07 2015
- John Colvin (5/18) Oct 07 2015 Hmm. That seems really contrived and/or missing the point. You
- Jonathan M Davis (38/57) Oct 07 2015 As I understand it, there are algorithms that inherently need 3
- John Colvin (3/42) Oct 07 2015 Couldn't we define a TriRange or something for this?
- Timon Gehr (16/26) Oct 07 2015 I think the most obvious way to generalize, such that ranges cater to
- Trass3r (2/13) Oct 08 2015
- Kagamin (13/26) Oct 08 2015 Hmm... conceptually a bidirectional range should be able to
- Kagamin (8/8) Oct 08 2015 The backward range can have an input range interface, like retro:
- John Colvin (6/27) Oct 08 2015 What you're effectively describing is a trio of iterators wrapped
- Kagamin (14/18) Oct 08 2015 The C++ example doesn't work with generic iterators, it needs a
- John Colvin (6/25) Oct 08 2015 I much prefer this second version:
- H. S. Teoh via Digitalmars-d (43/74) Oct 08 2015 Bidirectional ranges do have a fundamental lack in their definition, in
- Kagamin (15/22) Oct 08 2015 It should be probably possible to undo the history range too, but
- Kagamin (11/11) Oct 08 2015 OK, I thought a little more and... Name: divisible range. It
- Timon Gehr (4/13) Oct 08 2015 Isn't this the same as my suggestion?
- Eric Niebler (36/64) Oct 09 2015 Glad that you guys found my rationale. Yes, those are the two big
- Andrei Alexandrescu (8/18) Oct 09 2015 Only it's the other way around, which makes the matter quite ironic. You...
- Eric Niebler (12/36) Oct 10 2015 If I implied that I believe that D ranges were based on
- H. S. Teoh via Digitalmars-d (20/27) Oct 10 2015 [...]
- Andrei Alexandrescu (23/55) Oct 10 2015 Well the simple fact is then that P.S. has done an awful job at
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (22/26) Oct 12 2015 You've already published the background for your library approach
- Kagamin (3/9) Oct 12 2015 http://forum.dlang.org/post/hmtj0e$1qmg$1@digitalmars.com
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (3/4) Oct 12 2015 Meh, library solutions are no good. Insertions and deletions mess
- deadalnix (18/31) Oct 10 2015 Ho come on, that's pretty obvious that C++ is playing catch up
- Andrei Alexandrescu (11/14) Oct 09 2015 I agree that ranges are a weaker basis than iterators. But it's not
- H. S. Teoh via Digitalmars-d (11/26) Oct 10 2015 I assume .before would be implemented in a specialization of forward
- Walter Bright (5/15) Oct 06 2015 D ranges owe plenty to C++ iterators and algorithms, no doubt. Boost ran...
- lobo (7/16) Oct 01 2015 It does, thank you.
- bitwise (13/32) Oct 01 2015 Did you look at my example(this one is updated)?
- Manu via Digitalmars-d (17/23) Oct 03 2015 OMG, this!
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (8/15) Oct 05 2015 What do you need delegates for when you have flexible
- =?UTF-8?Q?Ali_=c3=87ehreli?= (14/18) Sep 30 2015 Yay! :)
- =?UTF-8?Q?Ali_=c3=87ehreli?= (4/5) Sep 30 2015 Oops! I've mixed up the years. I did go to DConf 2014 but not DConf
- Joakim (14/18) Sep 30 2015 Thanks for the link, I watched the whole video today and it was a
- wobbles (6/27) Sep 30 2015 Another thing I noticed that showed D nice-ness is when he was
- Brad Roberts via Digitalmars-d (4/26) Sep 30 2015 The 'start from the bottom' part of that part of the code was because he...
- Timon Gehr (3/6) Oct 01 2015 It's easy to write a clean Haskell version, in case you were trying to
- Jim Hewes (3/3) Sep 30 2015 I haven't watched it yet, but it seems to be similar to this one from
- rsw0x (3/7) Sep 30 2015 D's ranges are inarguably the best part of the language and one
https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. Teoh
Sep 29 2015
On Wednesday, 30 September 2015 at 01:45:49 UTC, deadalnix wrote:https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohShared on reddit: https://www.reddit.com/r/programming/comments/3mwu4e/cppcon_2015_eric_niebler_ranges_for_the_standard/ Also disappointed by Herb talk. It was very interesting, but he was blatantly dishonest when comparing other languages. He goes to claim GC in other languages is costly (it is) but then goes to propose "cost free" smart pointer kind of solution that are not cost free. Many paper show how both solution are on a continuum and he MUST know this.
Sep 29 2015
On Wednesday, 30 September 2015 at 01:55:43 UTC, deadalnix wrote:On Wednesday, 30 September 2015 at 01:45:49 UTC, deadalnix wrote:I had the same feeling, as a lot of the ideas clearly comes from languages (like D / Rust / ..) but were presented to the public as inventions of their own.https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohShared on reddit: https://www.reddit.com/r/programming/comments/3mwu4e/cppcon_2015_eric_niebler_ranges_for_the_standard/ Also disappointed by Herb talk. It was very interesting, but he was blatantly dishonest when comparing other languages. He goes to claim GC in other languages is costly (it is) but then goes to propose "cost free" smart pointer kind of solution that are not cost free. Many paper show how both solution are on a continuum and he MUST know this.
Sep 30 2015
On Wednesday, 30 September 2015 at 01:45:49 UTC, deadalnix wrote:https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohSo this is what APL feels like. /s
Sep 29 2015
On Wednesday, 30 September 2015 at 02:59:40 UTC, Freddy wrote:So this is what APL feels like. /sNah, the APL version would be shorter and only use builtins. ;) -Wyatt
Sep 30 2015
On 9/29/15 9:45 PM, deadalnix wrote:https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohDitto! Here is the link to the video at the time where D is credited, very nice compliment: https://youtu.be/mFUXNMfaciE?t=115 -Steve
Sep 30 2015
On 09/30/2015 09:31 AM, Steven Schveighoffer wrote:On 9/29/15 9:45 PM, deadalnix wrote:One great action item is to backport some of Eric's ideas to the D example. Currently Eric's final code looks nicer than the D code. -- Andreihttps://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohDitto! Here is the link to the video at the time where D is credited, very nice compliment: https://youtu.be/mFUXNMfaciE?t=115 -Steve
Sep 30 2015
On Wed, Sep 30, 2015 at 10:32:16AM -0400, Andrei Alexandrescu via Digitalmars-d wrote:On 09/30/2015 09:31 AM, Steven Schveighoffer wrote:[...] I watched most of the video (mainly the first half where he goes through the C++ version of the code), and I have to confess I couldn't help noticing just how ugly the C++ syntax is. I mean, overloading operator|() for chaining, seriously? UFCS is superior any day, IMNSHO. And overloading operator%() for string interpolation, ugh. (Though this one seems to be a Boost thing, not specific to the ranges proposal.) And this is on top of the usual ugliness of C++ template syntax. Not to mention the RANGE_FOREACH macro (I assume it's a macro), where D's foreach has supported natively for years now. (D has seriously ruined my life; I simply can't bring myself to go back to C++ anymore. At least not voluntarily.) Also, this seems to confirm that C++ is gradually falling to the position where it's playing catch-up with respect to innovations in newer languages like D and Rust. The fact that ranges are being proposed for the C++ standard library is a big endorsement of D, IMO. It's also clear that the imperative crowd is slowly but surely moving towards a more functional approach to programming. As the presenter said, having mutable state and branching/looping is what makes code explode in combinatorial complexity, making it hard to analyse, hard to prove correct, and more prone to bugs. I feel like he didn't hit on the central point of my article, though. The whole thrust behind that article was the idea of impedance mismatch between code structure and data structure, an idea I picked up from the Jackson Structured Programming paradigm in my college years. When code structure and data structure don't map 1-to-1, there's a structure conflict, and the usual response is to invent ad hoc hacks to compensate for the mismatch, usually in the form of boolean flags or other such band-aids. JSP, however, proposes that the *right* way to resolving the conflict is to change the program structure so that it *does* match the structure of the data. I have applied this in various forms throughout my career, and have found that it works very well not only in solidifying the way I write loops, but it also gives me a tangible handle on how to better shape the large-scale of my programs. Where ranges come in, is that ranges, due to their modular, encapsulated nature and their standardized API, essentially guides the programmer into the correct data-matching code structure in an unobtrusive, even spontaneous manner. In order to make range-based code work at all, you pretty much have to write your code in a way that exactly matches your data -- hacks like boolean flags and other such ugliness are spontaneously excluded (unless you deliberately warp your code to bring them back in -- and who in their right mind would want to do that?). To me, this is what makes ranges such a great innovation: you get the best of JSP (which I suspect almost nobody these days has even heard about!), many of the benefits of pure functional programming, code readability, testability, etc., all in one package. And it's not even hard to use.On 9/29/15 9:45 PM, deadalnix wrote:https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohDitto! Here is the link to the video at the time where D is credited, very nice compliment: https://youtu.be/mFUXNMfaciE?t=115One great action item is to backport some of Eric's ideas to the D example. Currently Eric's final code looks nicer than the D code. -- AndreiDo you have a list of ideas that should be backported? One that I can think of is using transpose() to do the columnar pasting, instead of the more specific function that I wrote specifically for that purpose. That was very clever, since by making all the formatted months exactly the same dimensions, it avoided the need to write a specific function, but can simply use transpose(). Great idea indeed! T -- VI = Visual Irritation
Sep 30 2015
On Wednesday, 30 September 2015 at 22:51:24 UTC, H. S. Teoh wrote:On Wed, Sep 30, 2015 at 10:32:16AM -0400, Andrei Alexandrescu[...]I watched most of the video (mainly the first half where he goes through the C++ version of the code), and I have to confess I couldn't help noticing just how ugly the C++ syntax is.This is a key reason I am using D. I really like C++14+boost but that syntax brings me back to D every time.I mean, overloading operator|() for chaining, seriously? UFCS is superior any day, IMNSHO.I seem to recall that in a previous on ranges Niebler said that operator|() was simply available and had a vague notion of chaining thanks to *nix shell. He went on to say it would probably need to change to get through the ISO committee. I hope it does. If the current plans for overloading operator.() get up I wonder how well it would fit as a replacement operator.And overloading operator%() for string interpolation, ugh. (Though this one seems to be a Boost thing, not specific to the ranges proposal.)This is also a Python thing so it's quite prevelant in the wild. I find D's ~ much nicer, although minutely slower to type than %And this is on top of the usual ugliness of C++ template syntax. Not to mention the RANGE_FOREACH macro (I assume it's a macro), where D's foreach has supported natively for years now. (D has seriously ruined my life; I simply can't bring myself to go back to C++ anymore. At least not voluntarily.) Also, this seems to confirm that C++ is gradually falling to the position where it's playing catch-up with respect to innovations in newer languages like D and Rust. The fact that ranges are being proposed for the C++ standard library is a big endorsement of D, IMO.C++ has been playing catchup for the last 10 yrs and it's been an amazing transition for the language. If ranges are accepted into ISO C++ I can't imagine it would be long before for(auto e:range). [snip]I really liked the namespaces view:: and action:: because it is immediately clear just reading the code what was lazy and what was not. bye, loboOne great action item is to backport some of Eric's ideas to the D example. Currently Eric's final code looks nicer than the D code. -- AndreiDo you have a list of ideas that should be backported?
Sep 30 2015
On Thursday, 1 October 2015 at 00:42:43 UTC, lobo wrote:If ranges are accepted into ISO C++ I can't imagine it would be long before for(auto e:range).Special features are not necessary to do this. C++ for loop works on anything with begin()/end() functions. Real ranges could just be a pair of iterators, and lazy ranges could give out dummies: template<class T> struct iota { T first, last; iota(T first, T last) : first(first), last(last) {} T front() const { return first; } void popFront() { ++first; } bool empty() const { return first == last; } struct iterator { iota *_iota; bool operator!=(const iterator& that) const { assert(_iota == that._iota); return !_iota->empty(); } void operator++() { _iota->popFront(); } T operator*() const { return _iota->front(); } }; iterator begin() { return iterator{this}; } iterator end() { return iterator{this}; } }; int main(int argc, const char * argv[]) { for(int x : iota<int>(0, 5)) printf("%d ", x); return 0; } I don't think it would be that hard to make something this possible: for(int x : iota<int>(0, 5).to<take>(3)) printf("%d ", x); The iterator dummy could probably be generalized with a template. Bit
Sep 30 2015
On Thursday, 1 October 2015 at 01:32:17 UTC, bitwise wrote:I don't think it would be that hard to make something this possible: for(int x : iota<int>(0, 5).to<take>(3)) printf("%d ", x);Curiosity got the best of me: http://ideone.com/RoJxLa output doesn't show up for some reason, but it works. Bit
Sep 30 2015
On Thursday, 1 October 2015 at 01:54:22 UTC, bitwise wrote:On Thursday, 1 October 2015 at 01:32:17 UTC, bitwise wrote:Yes, that's what we have always done with iterators. The point is users shouldn't have to write or instantiate iterators explicitly for any custom range. bye, loboI don't think it would be that hard to make something this possible: for(int x : iota<int>(0, 5).to<take>(3)) printf("%d ", x);Curiosity got the best of me: http://ideone.com/RoJxLa output doesn't show up for some reason, but it works. Bit
Sep 30 2015
On Thursday, 1 October 2015 at 02:53:25 UTC, lobo wrote:On Thursday, 1 October 2015 at 01:54:22 UTC, bitwise wrote:I understand, but the C++ committee seems very conservative to me, so when it's this easy to add for(:) support by giving ranges begin()/end() functions, it makes me doubt they will actually change the language for it. BitOn Thursday, 1 October 2015 at 01:32:17 UTC, bitwise wrote:Yes, that's what we have always done with iterators. The point is users shouldn't have to write or instantiate iterators explicitly for any custom range. bye, loboI don't think it would be that hard to make something this possible: for(int x : iota<int>(0, 5).to<take>(3)) printf("%d ", x);Curiosity got the best of me: http://ideone.com/RoJxLa output doesn't show up for some reason, but it works. Bit
Sep 30 2015
On Thursday, 1 October 2015 at 04:08:00 UTC, bitwise wrote:I understand, but the C++ committee seems very conservative to me, so when it's this easy to add for(:) support by giving ranges begin()/end() functions, it makes me doubt they will actually change the language for it.As of C++11, C++ has the for(auto e:range) control structure you are looking for. I would be using it here except for one thing: in my proposal, begin() and end() don't have to return objects of the same type! begin() must return an iterator and end() must return something that is EqualityComparable with the iterator -- but it doesn't have to be an iterator. That makes many types of iterators vastly simpler to implement and more efficient at runtime. C++'s built-in range-based for(:) loop expects begin() and end() to return objects of the same type. The committee is already talking about loosening that constraint so that the ranges I'm proposing Just Work with the existing built-in looping construct. Until then, there is an ugly macro. It's a temporary hack, nothing more. Hope that clears things up. Eric P.S. I see lots of people here assuming that C++ is playing catch-up to D because D has ranges and C++ doesn't yet. That is ignoring the long history of ranges in C++. C++ got ranges in the form of the Boost.Range library by Thorsten Ottoson sometime in the early 00's. Andrei didn't implement D's ranges until many years after. The ranges idea is older than dirt. It's not a D invention.
Sep 30 2015
On Thursday, 1 October 2015 at 05:47:25 UTC, Eric Niebler wrote:On Thursday, 1 October 2015 at 04:08:00 UTC, bitwise wrote:That's good news !I understand, but the C++ committee seems very conservative to me, so when it's this easy to add for(:) support by giving ranges begin()/end() functions, it makes me doubt they will actually change the language for it.As of C++11, C++ has the for(auto e:range) control structure you are looking for. I would be using it here except for one thing: in my proposal, begin() and end() don't have to return objects of the same type! begin() must return an iterator and end() must return something that is EqualityComparable with the iterator -- but it doesn't have to be an iterator. That makes many types of iterators vastly simpler to implement and more efficient at runtime. C++'s built-in range-based for(:) loop expects begin() and end() to return objects of the same type. The committee is already talking about loosening that constraint so that the ranges I'm proposing Just Work with the existing built-in looping construct. Until then, there is an ugly macro. It's a temporary hack, nothing more. Hope that clears things up. EricP.S. I see lots of people here assuming that C++ is playing catch-up to D because D has ranges and C++ doesn't yet. That is ignoring the long history of ranges in C++. C++ got ranges in the form of the Boost.Range library by Thorsten Ottoson sometime in the early 00's. Andrei didn't implement D's ranges until many years after. The ranges idea is older than dirt. It's not a D invention.Well, yes and no. Sure I'm sure there are precedent for ranges, be it in C++ or even I'm sure one can find them in other languages. I'm sure someone in the 70s had something like ranges already. But for years, it was a fringe idea in the C++ world, the consensus being the iterator were enough. Meanwhile, D adopted the idea and ran with it, doing so, proving how powerful the concept is. Some may be bitter, but I'm actually happy that C++ is adopting ranges, as these are a great tool. As long as the Jobs "we reinvented hot water with shiny corners and it is a revolution" style of presenting things do not become the norm. On that note, I think Herb's pissed of a lot of people with his talk. On the other hand, I think you did a fine job.
Oct 01 2015
On Thursday, 1 October 2015 at 07:37:28 UTC, deadalnix wrote:Well, yes and no. Sure I'm sure there are precedent for ranges, be it in C++ or even I'm sure one can find them in other languages. I'm sure someone in the 70s had something like ranges already.Yes, certainly in the 70s, but I would be surprised if something like it was not done for Lisp in the 60s? What D/C++ call ranges is iterators/generators. C++ mislabeled "table-pointers" as "iterators", which is a source for endless confusion. Co-routines, like the ones in Simula which was "stackless", can be viewed as a heavy async version of iterators/generators too. Adapters can be hooked up at runtime also (if speed is not a priority). So, "ranges" are very common, with varying syntax/performance.
Oct 05 2015
On 9/30/2015 10:47 PM, Eric Niebler wrote:P.S. I see lots of people here assuming that C++ is playing catch-up to D because D has ranges and C++ doesn't yet. That is ignoring the long history of ranges in C++. C++ got ranges in the form of the Boost.Range library by Thorsten Ottoson sometime in the early 00's. Andrei didn't implement D's ranges until many years after. The ranges idea is older than dirt. It's not a D invention.Range iteration over arrays have been around in D since the beginning and a more general proposal first appears here: http://www.digitalmars.com/d/archives//12773.html and Matthew Wilson did his range library for D in 9/2004 (and one for C++, too). He said he was going to propose it for Boost, I don't know if he ever did. It does appear in his "Imperfect C++" book. Matthew, a bit to my frustration, would always implement the D ideas first for C++ :-) but I don't think they garnered any attention from the C++ community. news://news.digitalmars.com/rangelib Here's something I wrote to Matthew in Feb 2004: "I think ranges in D are the same thing as slices. C++ doesn't have slices, so ranges makes sense as a distinct object. In D, slices over a collection or array simply yield a subset collection or subset array, not a separate object, so I'm not sure what value they would add to D." I found a link to Thorsten's Boost range: http://www.boost.org/doc/libs/1_34_0/libs/range/doc/intro.html http://www.boost.org/doc/libs/1_34_0/libs/range/doc/range.html It returns an iterator, so I don't think it is what we'd consider a range to be today. Matthew's ranges had the following members: current advance is_open corresponding to front, popFront, and empty. So I'd say given what I can dig up, that D's ranges were more advanced than Boost's were at the time. Sadly, Matthew's work seems to have disappeared from the internets and his web sites have vanished (rangelib.org). Update: found it on web.archive.org! https://web.archive.org/web/20050427085507/http://rangelib.synesis.com.au/ Anyhow, this is what I could dig up in an hour or so.
Oct 01 2015
Ranges because a D core language feature with D 2.021 Nov 25, 2008. Core language feature meaning it was no longer just a library construction, it was supported by foreach loops. As a library feature, it appeared in D 2.008 Nov 27, 2007.
Oct 01 2015
On Thursday, 1 October 2015 at 09:25:37 UTC, Walter Bright wrote:Ranges because a D core language feature with D 2.021 Nov 25, 2008. Core language feature meaning it was no longer just a library construction, it was supported by foreach loops. As a library feature, it appeared in D 2.008 Nov 27, 2007.Please be excited to see ranges in C++20
Oct 01 2015
On Thursday, 1 October 2015 at 08:37:37 UTC, Walter Bright wrote:Sadly, Matthew's work seems to have disappeared from the internets and his web sites have vanished (rangelib.org). Update: found it on web.archive.org! https://web.archive.org/web/20050427085507/http://rangelib.synesis.com.au/ Anyhow, this is what I could dig up in an hour or so.That site is still up, at least for me: http://rangelib.synesis.com.au/
Oct 01 2015
On 10/1/2015 2:31 AM, Joakim wrote:On Thursday, 1 October 2015 at 08:37:37 UTC, Walter Bright wrote:I have the Oct 2004 issue of CUJ where Matthew Wilson writes about ranges: "Ranges are simple to use and implement and, for most of the components written so far, are compilable by a majority of commonly used compilers. They're so simple that you may wonder why no one has defined them before." Boost ranges are still not modern ranges: http://www.boost.org/doc/libs/1_59_0/libs/range/doc/html/range/concepts/single_pass_range.html Eric's ranges are modern ranges for C++. Matthew had them for C++ 10 years ago, but his work was forgotten. He was going to propose it for Boost, but I don't know what happened.Sadly, Matthew's work seems to have disappeared from the internets and his web sites have vanished (rangelib.org). Update: found it on web.archive.org! https://web.archive.org/web/20050427085507/http://rangelib.synesis.com.au/ Anyhow, this is what I could dig up in an hour or so.That site is still up, at least for me: http://rangelib.synesis.com.au/
Oct 01 2015
On 10/01/2015 01:37 AM, Walter Bright wrote:Update: found it on web.archive.org!https://web.archive.org/web/20050427085507/http://rangelib.synesis.com.au/Anyhow, this is what I could dig up in an hour or so.Thank you for mining for that. From the days that I used to frequent comp.lang.c++.moderated (before around 2009 or so), I remember an individual who was trying to sell the idea of ranges to the C++ community. As I remember, nobody took him seriously at that time. Reading the page above, I think that individual must have been John Torjo or Matthew Wilson. Ali
Oct 01 2015
On 10/1/2015 11:18 AM, Ali Çehreli wrote:From the days that I used to frequent comp.lang.c++.moderated (before around 2009 or so), I remember an individual who was trying to sell the idea of ranges to the C++ community. As I remember, nobody took him seriously at that time. Reading the page above, I think that individual must have been John Torjo or Matthew Wilson.It was Andrei's talk "Iterators Must Go" that was the turning point for C++ to start paying attention to ranges. C++ was inspirational to D in the foundational work with iterators. But iterators are not ranges, and I don't see evidence that C++ had ranges before D. Boost ranges are not what we think of as ranges. It is true that Matthew first implemented ranges in C++, and then D. But the C++ version never got any interest from the C++ community, and went nowhere. I am credited with helping Matthew in the CUJ article talking about his range library. What I helped with was a D design, which he then implemented in C++ :-( There's probably more in the thousands of emails I have, but I don't want to spend more time spelunking them.
Oct 01 2015
On Thursday, 1 October 2015 at 21:03:16 UTC, Walter Bright wrote:I don't see evidence that C++ had ranges before D. Boost ranges are not what we think of as ranges.Why not?
Oct 02 2015
On 10/2/2015 10:49 AM, Eric Niebler wrote:On Thursday, 1 October 2015 at 21:03:16 UTC, Walter Bright wrote:Because it returns iterators. It should expose functions (or operators) that do this: front popFront empty not iterators. Instead, it has: begin end empty The begin and end are iterators, and don't encapsulate (i.e. constrain) what can be done with those iterators. For example, begin can return an iterator that can be used to increment right on past the end. The iterator itself has no knowledge of where the end is. This is the issue that D ranges (and Matthew's and your's) solve. I believe the difference is fundamental. http://www.boost.org/doc/libs/1_34_0/libs/range/doc/range.html It's possible I misunderstand it, please correct me if so.I don't see evidence that C++ had ranges before D. Boost ranges are not what we think of as ranges.Why not?
Oct 02 2015
On 10/2/15 6:57 PM, Walter Bright wrote:On 10/2/2015 10:49 AM, Eric Niebler wrote:The solution to this is cursors. i.e. ranges that point at exactly one element. All dcollection ranges have begin and end accessors for cursors to the first and one beyond the last element, but unlike iterators you cannot do anything dangerous with them. What you CAN do, is construct ranges from them safely (there is a slight cost for this). The interface is much superior IMO to how containers do ranges in std.container. There is a deficiency in ranges in that they are very fragile when it comes to pointing at one element. Iterators are much better in this regard. -SteveOn Thursday, 1 October 2015 at 21:03:16 UTC, Walter Bright wrote:Because it returns iterators. It should expose functions (or operators) that do this: front popFront empty not iterators. Instead, it has: begin end empty The begin and end are iterators, and don't encapsulate (i.e. constrain) what can be done with those iterators. For example, begin can return an iterator that can be used to increment right on past the end. The iterator itself has no knowledge of where the end is.I don't see evidence that C++ had ranges before D. Boost ranges are not what we think of as ranges.Why not?
Oct 05 2015
On Friday, 2 October 2015 at 22:57:52 UTC, Walter Bright wrote:On 10/2/2015 10:49 AM, Eric Niebler wrote:For a D range, what happens if you popFront from an empty range? An assertion, I'm guessing. It is not hard for a C++ iterator to do the same, and many debug standard libraries have iterators that do that.On Thursday, 1 October 2015 at 21:03:16 UTC, Walter Bright wrote:Because it returns iterators. It should expose functions (or operators) that do this: front popFront empty not iterators. Instead, it has: begin end empty The begin and end are iterators, and don't encapsulate (i.e. constrain) what can be done with those iterators. For example, begin can return an iterator that can be used to increment right on past the end. The iterator itself has no knowledge of where the end is.I don't see evidence that C++ had ranges before D. Boost ranges are not what we think of as ranges.Why not?This is the issue that D ranges (and Matthew's and your's) solve. I believe the difference is fundamental.A C++ iterator can store a pointer back to its range and implement all its core functionality in terms of simple operations like current, next, and done. The Boost.Iterators and Boost.Range libraries made that possible and have been around a long time. Some iterators can be implemented more efficiently without an indirection to the range. Those iterators are unsafe in the way you describe. The win is that iterators are a more powerful basis for building algorithms (i.e., you can express more with them).http://www.boost.org/doc/libs/1_34_0/libs/range/doc/range.html It's possible I misunderstand it, please correct me if so.
Oct 05 2015
On 10/5/2015 9:39 AM, Eric Niebler wrote:On Friday, 2 October 2015 at 22:57:52 UTC, Walter Bright wrote:You'd be right, and this is easy to do because a range encapsulates this knowledge.The begin and end are iterators, and don't encapsulate (i.e. constrain) what can be done with those iterators. For example, begin can return an iterator that can be used to increment right on past the end. The iterator itself has no knowledge of where the end is.For a D range, what happens if you popFront from an empty range? An assertion, I'm guessing.It is not hard for a C++ iterator to do the same, and many debug standard libraries have iterators that do that.Yes, you can build debug iterators that know their limits, or iterators with back pointers to the range. This is not an inherent property of Boost ranges, does not appear in the Boost description of ranges (unless I missed it), and is a kludge. I do not agree that D ranges owe anything to that design. In fact, it looks like an attempt to make iterators themselves ranges, rendering the Boost:range rather pointless?This is the issue that D ranges (and Matthew's and your's) solve. I believe the difference is fundamental.A C++ iterator can store a pointer back to its range and implement all its core functionality in terms of simple operations like current, next, and done. The Boost.Iterators and Boost.Range libraries made that possible and have been around a long time. Some iterators can be implemented more efficiently without an indirection to the range. Those iterators are unsafe in the way you describe.
Oct 05 2015
On Monday, 5 October 2015 at 21:57:31 UTC, Walter Bright wrote:Yes, you can build debug iterators that know their limits, or iterators with back pointers to the range. This is not an inherent property of Boost ranges, does not appear in the Boost description of ranges (unless I missed it), and is a kludge. I do not agree that D ranges owe anything to that design.The design of the D ranges and algorithms owe quite a lot to C++, and I've heard Andrei say as much. Stepanov did the hard work of defining common algorithms in terms of iterators of different strength. Given that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another. When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++. My work is based on Boost.Range. I only posted here to clear up what appeared to me to be confusion about that. \e
Oct 05 2015
On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:On Monday, 5 October 2015 at 21:57:31 UTC, Walter Bright wrote:D's ranges and their use in D's standard library owe a _lot_ to C++ - especially to the STL. They just don't owe anything to Boost's ranges. They're two different paths from the same root.Yes, you can build debug iterators that know their limits, or iterators with back pointers to the range. This is not an inherent property of Boost ranges, does not appear in the Boost description of ranges (unless I missed it), and is a kludge. I do not agree that D ranges owe anything to that design.The design of the D ranges and algorithms owe quite a lot to C++, and I've heard Andrei say as much. Stepanov did the hard work of defining common algorithms in terms of iterators of different strength. Given that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another.When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++. My work is based on Boost.Range.It'll be interesting to see where that goes. - Jonathan M Davis
Oct 05 2015
On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:On Monday, 5 October 2015 at 21:57:31 UTC, Walter Bright wrote:There is no denying that D owns a lot to C++. Then again D comes with great ideas of its own and success has many fathers.Yes, you can build debug iterators that know their limits, or iterators with back pointers to the range. This is not an inherent property of Boost ranges, does not appear in the Boost description of ranges (unless I missed it), and is a kludge. I do not agree that D ranges owe anything to that design.The design of the D ranges and algorithms owe quite a lot to C++, and I've heard Andrei say as much. Stepanov did the hard work of defining common algorithms in terms of iterators of different strength.Given that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another. When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++.What is your thinking here? Did you write it down somewhere? This would be very interesting.My work is based on Boost.Range. I only posted here to clear up what appeared to me to be confusion about that. \e
Oct 05 2015
On Tuesday, 6 October 2015 at 06:52:13 UTC, Ulrich Kuettler wrote:On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:Obviously, Eric would have to respond for us to know what his reasoning was, but I expect that it least part of it stems from the fact that C++ already uses iterators heavily. So, having a range-based solution that doesn't interact with iterators (like D has) doesn't fit in well with the existing code and paradigms. Even if you were to assume that D's approach is superior (which is debatable), that doesn't mean that it's a good fit for C++. D has the advantage of having considerably less baggage to deal with, so we have more freedom in the direction that we go. Whether we go in the right direction or not is another matter, but C++ has considerably more constraints than we have, so it's no surprise if we end up with different solutions. - Jonathan M DavisGiven that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another. When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++.What is your thinking here? Did you write it down somewhere? This would be very interesting.
Oct 06 2015
On Tuesday, 6 October 2015 at 07:09:21 UTC, Jonathan M Davis wrote:On Tuesday, 6 October 2015 at 06:52:13 UTC, Ulrich Kuettler wrote:Yes, this is an explanation. Thanks. So the argument being C++ customs. Now that you mention it, this seems to be the argument in Eric's D4128 paper, too. I was hoping for a somewhat deeper reasoning. Out of curiously, I am still trying to grasp all the implications. Ranges are hard.On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:Obviously, Eric would have to respond for us to know what his reasoning was, but I expect that it least part of it stems from the fact that C++ already uses iterators heavily. So, having a range-based solution that doesn't interact with iterators (like D has) doesn't fit in well with the existing code and paradigms. Even if you were to assume that D's approach is superior (which is debatable), that doesn't mean that it's a good fit for C++. D has the advantage of having considerably less baggage to deal with, so we have more freedom in the direction that we go. Whether we go in the right direction or not is another matter, but C++ has considerably more constraints than we have, so it's no surprise if we end up with different solutions.Given that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another. When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++.What is your thinking here? Did you write it down somewhere? This would be very interesting.
Oct 06 2015
On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler wrote:Yes, this is an explanation. Thanks. So the argument being C++ customs. Now that you mention it, this seems to be the argument in Eric's D4128 paper, too. I was hoping for a somewhat deeper reasoning. Out of curiously, I am still trying to grasp all the implications. Ranges are hard.Another one is "odd number of iterators algorithms"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexity D’s choice of algorithmic basis operations is inherently less efficient than C++’s.
Oct 07 2015
On Wednesday, 7 October 2015 at 14:59:28 UTC, Trass3r wrote:On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler wrote:Hmm. That seems really contrived and/or missing the point. You would never design a function like that for use with ranges, but that doesn't mean you're any less able to efficiently find word boundaries using ranges.Yes, this is an explanation. Thanks. So the argument being C++ customs. Now that you mention it, this seems to be the argument in Eric's D4128 paper, too. I was hoping for a somewhat deeper reasoning. Out of curiously, I am still trying to grasp all the implications. Ranges are hard.Another one is "odd number of iterators algorithms"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexity D’s choice of algorithmic basis operations is inherently less efficient than C++’s.
Oct 07 2015
On Wednesday, 7 October 2015 at 16:33:21 UTC, John Colvin wrote:On Wednesday, 7 October 2015 at 14:59:28 UTC, Trass3r wrote:As I understand it, there are algorithms that inherently need 3 iterators to do whatever is they do, and the question of how to deal with them has come up before in the newsgroup. I think that it's pretty clear that such algorithms are relatively few in number, but they do exist, and solving them with ranges does get potentially awkward. Similarly, using iterators with containers when you have to pass them to the container generally works better than ranges do. We've had to add overloads to the std.container types which take the results of the various take functions in order to work around that problem. So, there are clearly cases where ranges become awkward and iterators aren't. On the other hand, when dealing with algorithms, ranges tend to be far cleaner - especially when you need to chain them. And they tend to form a better basis of how to think about algorithms (even when dealing with iterators, you pretty much have to think in terms of ranges on some level at least). And ranges handle laziness far better than iterators do. So, I'm not the least bit convinced that iterators are a better way to go (quite the opposite), and I'm not convinced that trying to mix iterators and ranges is at all a good idea. But I do think that it's clear that using only ranges is not without its downsides, and since we're the first folks to seriously use ranges heavily in a language or standard library, we're bound to be making mistakes due to inexperience. At this point, I would guess that trying to mix iterators and ranges is just going to over-complicate things in an already over-complicated language, but it may actually be a big win for the C++ folks. We'll have to wait and see. If we _were_ to look at doing something more than straight ranges, we'd probably look more at something like Steven's cursors than adding iterators, though I think that there's a decent chance that that only really helps with containers (it's been a while since I looked at what he did with cursors, and I really don't remember the details), though for the most part, I think that containers are the primary place where ranges tend to get annoying. Algorithms where they're problematic do exist, but they seem to be rare. - Jonathan M DavisOn Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler wrote:Hmm. That seems really contrived and/or missing the point. You would never design a function like that for use with ranges, but that doesn't mean you're any less able to efficiently find word boundaries using ranges.Yes, this is an explanation. Thanks. So the argument being C++ customs. Now that you mention it, this seems to be the argument in Eric's D4128 paper, too. I was hoping for a somewhat deeper reasoning. Out of curiously, I am still trying to grasp all the implications. Ranges are hard.Another one is "odd number of iterators algorithms"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexity D’s choice of algorithmic basis operations is inherently less efficient than C++’s.
Oct 07 2015
On Wednesday, 7 October 2015 at 17:13:45 UTC, Jonathan M Davis wrote:As I understand it, there are algorithms that inherently need 3 iterators to do whatever is they do, and the question of how to deal with them has come up before in the newsgroup. I think that it's pretty clear that such algorithms are relatively few in number, but they do exist, and solving them with ranges does get potentially awkward. Similarly, using iterators with containers when you have to pass them to the container generally works better than ranges do. We've had to add overloads to the std.container types which take the results of the various take functions in order to work around that problem. So, there are clearly cases where ranges become awkward and iterators aren't. On the other hand, when dealing with algorithms, ranges tend to be far cleaner - especially when you need to chain them. And they tend to form a better basis of how to think about algorithms (even when dealing with iterators, you pretty much have to think in terms of ranges on some level at least). And ranges handle laziness far better than iterators do. So, I'm not the least bit convinced that iterators are a better way to go (quite the opposite), and I'm not convinced that trying to mix iterators and ranges is at all a good idea. But I do think that it's clear that using only ranges is not without its downsides, and since we're the first folks to seriously use ranges heavily in a language or standard library, we're bound to be making mistakes due to inexperience. At this point, I would guess that trying to mix iterators and ranges is just going to over-complicate things in an already over-complicated language, but it may actually be a big win for the C++ folks. We'll have to wait and see. If we _were_ to look at doing something more than straight ranges, we'd probably look more at something like Steven's cursors than adding iterators, though I think that there's a decent chance that that only really helps with containers (it's been a while since I looked at what he did with cursors, and I really don't remember the details), though for the most part, I think that containers are the primary place where ranges tend to get annoying. Algorithms where they're problematic do exist, but they seem to be rare. - Jonathan M DavisCouldn't we define a TriRange or something for this?
Oct 07 2015
On 10/07/2015 07:13 PM, Jonathan M Davis wrote:... If we _were_ to look at doing something more than straight ranges, we'd probably look more at something like Steven's cursors than adding iterators, though I think that there's a decent chance that that only really helps with containers (it's been a while since I looked at what he did with cursors, and I really don't remember the details), though for the most part, I think that containers are the primary place where ranges tend to get annoying. Algorithms where they're problematic do exist, but they seem to be rare. - Jonathan M DavisI think the most obvious way to generalize, such that ranges cater to those use cases, is to introduce a type of range that additionally requires the primitives: full(); // pushFront cannot be called unless false pushFront(); // restores one element at the front of the range The idea is: auto r=..., s=r.save; assert(r.full); r.popFront(); assert(!r.full); r.pushFront(); assert(r.full); assert(equal(s,r)); This is analogous to list zippers in functional languages in the same way that input ranges are analogous to lists.
Oct 07 2015
Here's the original discussion with Eric's elaborate answer: http://ericniebler.com/2014/02/21/introducing-iterables/#comment-403Because I want to leverage the vast amount of iterator-based code already written, and because in my experience, I don’t find that ranges as primitives solve all the problems that iterators do.Many algorithms return positions. These all suffer the same problem as find. One algorithm implementation isn’t sufficient; you need bunches of differently-named algorithms that differ only in the subrange they return.As for the political argument: I want ranges in the standard. There is just no way the C++ standardization committee would ever consider a range-only interface.
Oct 08 2015
On Wednesday, 7 October 2015 at 14:59:28 UTC, Trass3r wrote:On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler wrote:Hmm... conceptually a bidirectional range should be able to iterate back and forth: void is_word_boundary(Bidi r) { bool is_word_prev = r.re.empty ? false : isword(r.re.back); bool is_word_this = r.empty ? false : isword(r.front); return is_word_prev != is_word_this; } auto i = myrange; for(; !i.empty; i.popFront()) if( is_word_boundary(i) ) break;Yes, this is an explanation. Thanks. So the argument being C++ customs. Now that you mention it, this seems to be the argument in Eric's D4128 paper, too. I was hoping for a somewhat deeper reasoning. Out of curiously, I am still trying to grasp all the implications. Ranges are hard.Another one is "odd number of iterators algorithms"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexity D’s choice of algorithmic basis operations is inherently less efficient than C++’s.
Oct 08 2015
The backward range can have an input range interface, like retro: void is_word_boundary(Bidi r) { bool is_word_prev = r.prev.empty ? false : isword(r.prev.front); bool is_word_this = r.empty ? false : isword(r.front); return is_word_prev != is_word_this; }
Oct 08 2015
On Thursday, 8 October 2015 at 12:35:08 UTC, Kagamin wrote:Hmm... conceptually a bidirectional range should be able to iterate back and forth: void is_word_boundary(Bidi r) { bool is_word_prev = r.re.empty ? false : isword(r.re.back); bool is_word_this = r.empty ? false : isword(r.front); return is_word_prev != is_word_this; } auto i = myrange; for(; !i.empty; i.popFront()) if( is_word_boundary(i) ) break;On Thursday, 8 October 2015 at 12:53:24 UTC, Kagamin wrote:The backward range can have an input range interface, like retro: void is_word_boundary(Bidi r) { bool is_word_prev = r.prev.empty ? false : isword(r.prev.front); bool is_word_this = r.empty ? false : isword(r.front); return is_word_prev != is_word_this; }What you're effectively describing is a trio of iterators wrapped to give an interface of two linked ranges. popFront grows the first one and shrinks the second. I'd be interested to see how to construct that, given a generic range as input.
Oct 08 2015
On Thursday, 8 October 2015 at 13:10:24 UTC, John Colvin wrote:What you're effectively describing is a trio of iterators wrapped to give an interface of two linked ranges. popFront grows the first one and shrinks the second. I'd be interested to see how to construct that, given a generic range as input.The C++ example doesn't work with generic iterators, it needs a specific ability to iterate in both directions, hence a bidirectional range. The way ranges are used for iteration, they can be seen as adapters for iterators providing various consistent interfaces depending on their capabilities. In this example we need a bidirectional range that can go back and forth, one way to do it is to provide undo mechanism like undoPopFront and frontUndoEmpty to allow the range grow back, thus remaining a range that is a list of items and not an iterator. Another way is to provide a reverse range of previously popped items - this can be seen as iterator or not, more like a range with history rather than an undoable input range, so maybe the getter should be `history`.
Oct 08 2015
On Thursday, 8 October 2015 at 14:36:03 UTC, Kagamin wrote:On Thursday, 8 October 2015 at 13:10:24 UTC, John Colvin wrote:Of course.What you're effectively describing is a trio of iterators wrapped to give an interface of two linked ranges. popFront grows the first one and shrinks the second. I'd be interested to see how to construct that, given a generic range as input.The C++ example doesn't work with generic iterators, it needs a specific ability to iterate in both directions, hence a bidirectional range.The way ranges are used for iteration, they can be seen as adapters for iterators providing various consistent interfaces depending on their capabilities. In this example we need a bidirectional range that can go back and forth, one way to do it is to provide undo mechanism like undoPopFront and frontUndoEmpty to allow the range grow back, thus remaining a range that is a list of items and not an iterator.I much prefer this second version:Another way is to provide a reverse range of previously popped items - this can be seen as iterator or not, more like a range with history rather than an undoable input range, so maybe the getter should be `history`.my question is: How, in practice, does one take a bidirectional range and make one of these new things? I foresee some difficulty, but perhaps I'm just not being imaginative enough.
Oct 08 2015
On Thu, Oct 08, 2015 at 02:46:05PM +0000, John Colvin via Digitalmars-d wrote:On Thursday, 8 October 2015 at 14:36:03 UTC, Kagamin wrote:Bidirectional ranges do have a fundamental lack in their definition, in that the bidirectionality is weaker than the C++ form of bidirectionality. For example, suppose you're given some bidirectional range r, with swappable elements. Clearly, reverse(r) is easily implementable (just swap .front and .back, then popFront() and popBack() until the range is empty). However, suppose you want to reverse the last n elements of r. How would you do it? Conceptually speaking, if the range is bidirectional, then its last segment of n elements ought to be bidirectional too, right? However, there is currently no (easy) way to get a bidirectional subrange out of r, using the current range primitives. One brute force way to do it, is to iterate a .save'd copy of r (since bidirectionality implies forward range) from the front, until there are only n elements left, then perform the reverse() operation. However, this is horribly inefficient if n is relatively small w.r.t. the total number of elements in r. It gets worse if r does not have .length, so you may have to iterate over *two* .save'd copies of r so that you know the subrange you end up with has exactly n elements (since you can't tell how many elements are in the subrange until you reach the end). Ideally, though, we'd like to be able to iterate from the end of r, so that we only incur the cost of calling .popBack n times. However, no amount of trickery with the current bidirectional range API is going to get you this subrange by iterating from the back. The problem is that once you call .popBack n times, there's no way to turn .back into the new .front of the subrange. You can't unpop .back once you've called popBack(), so you can't implement .front on the subrange. Whereas with iterators, you *could* just do iter-- n times, then use iter with the original .end() to form the n element subrange. So D's bidirectional ranges are inherently weaker than a pair of C++ bidirectional iterators, because D's bidirectional ranges are, under the hood, a pair of *uni-directional* iterators in opposite directions. Once you advance either iterator, you can't go back anymore without resorting to ugly inefficient hacks (e.g., allocate a stack of .save'd positions), whereas in C++ both ends are bidirectional, and can go forward/back at anytime. If we were to add an .unpop primitive to bidirectional ranges, though, then we could solve this problem. However, I'm not sure how this fits in with the overall concept of ranges. T -- Век живи - век учись. А дураком помрёшь.On Thursday, 8 October 2015 at 13:10:24 UTC, John Colvin wrote:Of course.What you're effectively describing is a trio of iterators wrapped to give an interface of two linked ranges. popFront grows the first one and shrinks the second. I'd be interested to see how to construct that, given a generic range as input.The C++ example doesn't work with generic iterators, it needs a specific ability to iterate in both directions, hence a bidirectional range.The way ranges are used for iteration, they can be seen as adapters for iterators providing various consistent interfaces depending on their capabilities. In this example we need a bidirectional range that can go back and forth, one way to do it is to provide undo mechanism like undoPopFront and frontUndoEmpty to allow the range grow back, thus remaining a range that is a list of items and not an iterator.I much prefer this second version:Another way is to provide a reverse range of previously popped items - this can be seen as iterator or not, more like a range with history rather than an undoable input range, so maybe the getter should be `history`.my question is: How, in practice, does one take a bidirectional range and make one of these new things? I foresee some difficulty, but perhaps I'm just not being imaginative enough.
Oct 08 2015
On Thursday, 8 October 2015 at 14:46:07 UTC, John Colvin wrote:It should be probably possible to undo the history range too, but it would be future, so it looks like there can be a better interface: beforeFront returns a normal bidirectional range of items before current front, afterBack returns a normal bidirectional range of items after back, so r.beforeFront.back is an item right before current front. This makes it more symmetric, and properties return ranges of the same type as the source range, but I don't know how to name such a range :) A range with shadows? Those ranges can be seen as shadows (before and after). Yes D's bidirectional range provides less guarantees than C++ bidirectional iterator, but you can build it on a random access range that provides more guarantees than bidirectional iterator, or you can provide a range with shadows, that provides as much guarantees as C++ bidirectional iterator, no less, no more.Another way is to provide a reverse range of previously popped items - this can be seen as iterator or not, more like a range with history rather than an undoable input range, so maybe the getter should be `history`.my question is: How, in practice, does one take a bidirectional range and make one of these new things? I foresee some difficulty, but perhaps I'm just not being imaginative enough.
Oct 08 2015
OK, I thought a little more and... Name: divisible range. It occurred to me that we only need to reverse logic of bidirectional range: while bidirectional range is a pair of ranges that shrink towards each other, divisible range is divided into two ranges that shrink away from each other. The C++ example implies that begin and end must be bidirectional iterators, but that is not really needed as they are used for bounds checks only, ranges have empty for that, so the divisible range can be a normal input range that provides access to its left part that shrinks from back (backward input range?) and provides access to the right part.
Oct 08 2015
On 10/08/2015 10:08 PM, Kagamin wrote:OK, I thought a little more and... Name: divisible range. It occurred to me that we only need to reverse logic of bidirectional range: while bidirectional range is a pair of ranges that shrink towards each other, divisible range is divided into two ranges that shrink away from each other. The C++ example implies that begin and end must be bidirectional iterators, but that is not really needed as they are used for bounds checks only, ranges have empty for that, so the divisible range can be a normal input range that provides access to its left part that shrinks from back (backward input range?) and provides access to the right part.Isn't this the same as my suggestion? http://forum.dlang.org/post/mv3q34$bbg$1 digitalmars.com If not, what is the difference?
Oct 08 2015
On Thursday, 8 October 2015 at 22:57:01 UTC, Timon Gehr wrote:Isn't this the same as my suggestion? http://forum.dlang.org/post/mv3q34$bbg$1 digitalmars.com If not, what is the difference?Your range is undoable. The difference I see is that you use full (should be frontFull) and pushFront to go left, I use normal backward input range, empty and popBack - existing primitives. Also pushFront may suggest you're adding new items at the front, maybe your methods should be frontUndoEmpty and undoPopFront?
Oct 09 2015
Also imagine you want to write an algorithm that iterates backwards, you must choose which set of primitives to use: back+empty+popBack or front+frontUndoEmpty+undoPopFront, and an undoable bidirectional range will support both.
Oct 09 2015
On Wednesday, 7 October 2015 at 14:59:28 UTC, Trass3r wrote:On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler wrote:Glad that you guys found my rationale. Yes, those are the two big reasons. Trying to express algorithms without any clear abstraction of "position within range" (independent of ranges) is hard and awkward, and occasionally causes algorithms to be less efficient. IMO, James Touton's "position-based ranges"[1] was/is a viable design of a ranges-first interface that also had a (very weak but sufficient) notion of position. It might be a direction for D if you ever find it necessary. It's true that the initial version of Boost.Range wasn't terribly interesting. As early as 12/2004, I was working on a set of extensions to Boost.Range that added range adaptors that chain. (See https://svn.boost.org/svn/boost/sandbox/boost/range_ex.) Lazy range operations that compose is where range-based design starts. That's as far back as I can trace my work on "real ranges". This work was eventually merged into Boost.Range as Range v2. On Thursday, 1 October 2015 at 08:37:37 UTC, Walter Bright wrote:Yes, this is an explanation. Thanks. So the argument being C++ customs. Now that you mention it, this seems to be the argument in Eric's D4128 paper, too. I was hoping for a somewhat deeper reasoning. Out of curiously, I am still trying to grasp all the implications. Ranges are hard.Another one is "odd number of iterators algorithms"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexityD’s choice of algorithmic basis operations is inherently less efficient than C++’s.Range iteration over arrays have been around in D since the beginning and a more general proposal first appears here: http://www.digitalmars.com/d/archives//12773.htmlI don't see any generic description there of what constitutes a range or how to leverage it in user code, just a discussion of the foreach language construct.I found a link to Thorsten's Boost range: http://www.boost.org/doc/libs/1_34_0/libs/range/doc/intro.html http://www.boost.org/doc/libs/1_34_0/libs/range/doc/range.html It returns an iterator, so I don't think it is what we'd consider a range to be today. Matthew's ranges had the following members: current advance is_open corresponding to front, popFront, and empty. So I'd say given what I can dig up, that D's ranges were more advanced than Boost's were at the time.Walter, you seem to suggest that Real Ranges have a popFront/front interface. Naturally by that metric C++ ranges don't count! But IMO that's not what matters. What matters is the programming model that ranges permit. Boost.Range's model where ranges are a layer over iterators can and does support that model, as my range proposal and my range_ex library from 2004 demonstrate. To be honest, this whole conversation is kind of funny to me. It reminds me of the Bugs Bunny cartoon where Marvin the Martian plants his flag on Earth and says, "I claim this planet in the name of [Digital] Mars!" We Earthlings respectfully disagree. :-) Eric [^1] http://www.open-std.org/pipermail/ranges/2014-March/000499.html
Oct 09 2015
On 10/10/15 12:58 AM, Eric Niebler wrote:To be honest, this whole conversation is kind of funny to me. It reminds me of the Bugs Bunny cartoon where Marvin the Martian plants his flag on Earth and says, "I claim this planet in the name of [Digital] Mars!" We Earthlings respectfully disagree. :-)Only it's the other way around, which makes the matter quite ironic. You wrote:P.S. I see lots of people here assuming that C++ is playing catch-up to D because D has ranges and C++ doesn't yet. That is ignoring the long history of ranges in C++. C++ got ranges in the form of the Boost.Range library by Thorsten Ottoson sometime in the early 00's. Andrei didn't implement D's ranges until many years after. The ranges idea is older than dirt. It's not a D invention.I think it would be a bit of a stretch to describe D ranges as derivative of Boost ranges. Anyhow, it's best for us all to focus on doing good work instead of pettily fighting for irrelevant credit. Andrei
Oct 09 2015
On Saturday, 10 October 2015 at 06:15:10 UTC, Andrei Alexandrescu wrote:On 10/10/15 12:58 AM, Eric Niebler wrote:If I implied that I believe that D ranges were based on Boost.Range, then I apologize. I don't believe that. I suspect (but don't know) that ranges in D were independently invented without knowledge of the long history of them in C++. Which is fine except for the claims that C++ is playing catch-up. It's not.To be honest, this whole conversation is kind of funny to me. It reminds me of the Bugs Bunny cartoon where Marvin the Martian plants his flag on Earth and says, "I claim this planet in the name of [Digital] Mars!" We Earthlings respectfully disagree. :-)Only it's the other way around, which makes the matter quite ironic. You wrote:P.S. I see lots of people here assuming that C++ is playing catch-up to D because D has ranges and C++ doesn't yet. That is ignoring the long history of ranges in C++. C++ got ranges in the form of the Boost.Range library by Thorsten Ottoson sometime in the early 00's. Andrei didn't implement D's ranges until many years after. The ranges idea is older than dirt. It's not a D invention.I think it would be a bit of a stretch to describe D ranges as derivative of Boost ranges.Anyhow, it's best for us all to focus on doing good work instead of pettily fighting for irrelevant credit.I only jumped in when I saw some disparagement of C++ and my work which (IMO) was both petty and wrong. I would very much like to drop this and get back to productive work. \e
Oct 10 2015
On Sat, Oct 10, 2015 at 06:06:59PM +0000, Eric Niebler via Digitalmars-d wrote:On Saturday, 10 October 2015 at 06:15:10 UTC, Andrei Alexandrescu wrote:[...][...] Eric, if I came across as disparaging your work, I apologize, as that was never my intention. As the author of the article that you used as the basis for your presentation, I am very honored to have you acknowledge my work in the C++ community. My comment about C++ playing catchup wasn't intended to be petty disparagement either, it's a reflection of my consideration that C++ has been heading in the wrong direction (IMO), and only now is "turning the ship", so to speak, toward where other languages have already gone ahead. I'm a C++ programmer myself, and for many years have faced many problems and issues that arose from certain design decisions in C++. After discovering D and realizing that I don't *need* to deal with such issues after all, because D made different design decisions, only to learn later on that C++ is now also trying to head in the same directions, it's a bit hard not to perceive C++ as playing catch-up. T -- Gone Chopin. Bach in a minuet.Anyhow, it's best for us all to focus on doing good work instead of pettily fighting for irrelevant credit.I only jumped in when I saw some disparagement of C++ and my work which (IMO) was both petty and wrong. I would very much like to drop this and get back to productive work.
Oct 10 2015
On 10/10/15 9:06 PM, Eric Niebler wrote:On Saturday, 10 October 2015 at 06:15:10 UTC, Andrei Alexandrescu wrote:Well the simple fact is then that P.S. has done an awful job at conveying your point.On 10/10/15 12:58 AM, Eric Niebler wrote:If I implied that I believe that D ranges were based on Boost.Range, then I apologize. I don't believe that.To be honest, this whole conversation is kind of funny to me. It reminds me of the Bugs Bunny cartoon where Marvin the Martian plants his flag on Earth and says, "I claim this planet in the name of [Digital] Mars!" We Earthlings respectfully disagree. :-)Only it's the other way around, which makes the matter quite ironic. You wrote:P.S. I see lots of people here assuming that C++ is playing catch-up to D because D has ranges and C++ doesn't yet. That is ignoring the long history of ranges in C++. C++ got ranges in the form of the Boost.Range library by Thorsten Ottoson sometime in the early 00's. Andrei didn't implement D's ranges until many years after. The ranges idea is older than dirt. It's not a D invention.I think it would be a bit of a stretch to describe D ranges as derivative of Boost ranges.I suspect (but don't know) that ranges in D were independently invented without knowledge of the long history of them in C++.Well that's easy to figure. "Iterators Must Go" at https://archive.org/details/AndreiAlexandrescuKeynoteBoostcon2009 starting around minute 1:01:50 mentions "Ranges are not Boost ranges. They're very different". Same talk at 1:02:34 describes how Boost and Adobe defined their own ranges ("Boost and Adobe did make an interesting step in a good direction, however things must be taken way further than that." So there was knowledge of said long history of ranges in C++. Far as I can tell "Iterators Must Go" was immediately and universally recognized as a turning point in how people approached getting work done using ranges. (Existing work I only found out recently: Matthew Wilson did define ranges as a generalization of D slices; his work was not based on C++ idioms, and made no inroads in the C++ community. His work _is_ strongly related to today's D ranges, I ought to have found that, and it is my mistake to not have.)Which is fine except for the claims that C++ is playing catch-up. It's not.Eric, I don't know about others but I respect and like your work. I appreciate its originality, too. What I see here is a simple case when someone said something wrong and got his behind appropriately handed on a dish constructed of a precious metal. AndreiAnyhow, it's best for us all to focus on doing good work instead of pettily fighting for irrelevant credit.I only jumped in when I saw some disparagement of C++ and my work which (IMO) was both petty and wrong. I would very much like to drop this and get back to productive work.
Oct 10 2015
On Saturday, 10 October 2015 at 22:06:31 UTC, Andrei Alexandrescu wrote:So there was knowledge of said long history of ranges in C++. Far as I can tell >"Iterators Must Go" was immediately and universally recognized as a turning point in >how people approached getting work done using ranges.You've already published the background for your library approach here: http://www.informit.com/articles/article.aspx?p=1407357&seqNum=4 Which basically states the foundation: GoF iterators + STL. So you've already killed the novelty game yourself. GoF patterns is just an attempt to describe _common_ patterns in software design. Stepanov "C++ pointer-iterators" was an attempt to break away from the heavier GoF iterators (which D calls ranges) with something more lightweight. If one tries to enumerate all kinds of types of iterators one will end up with a combinatorial explosion, so much for generality. Stepanovs approach was probably also an attempt to get away from this combinatorial explosion by providing pointer-semantics instead. One of the most important and convenient iterators (which C++ fails to deliver) are what GoF calls "roboust iterators": iterators that allow deletions. To get there safely and conveniently iterators have to be made a language feature, since it requires static analysis in the general case, IMO. Want to innovate? Provide language support.
Oct 12 2015
On Monday, 12 October 2015 at 07:08:19 UTC, Ola Fosheim Grøstad wrote:One of the most important and convenient iterators (which C++ fails to deliver) are what GoF calls "roboust iterators": iterators that allow deletions. To get there safely and conveniently iterators have to be made a language feature, since it requires static analysis in the general case, IMO. Want to innovate? Provide language support.http://forum.dlang.org/post/hmtj0e$1qmg$1 digitalmars.com
Oct 12 2015
On Monday, 12 October 2015 at 12:29:28 UTC, Kagamin wrote:http://forum.dlang.org/post/hmtj0e$1qmg$1 digitalmars.comMeh, library solutions are no good. Insertions and deletions mess up many things that effects performance, including vectorisation.
Oct 12 2015
On Saturday, 10 October 2015 at 18:07:02 UTC, Eric Niebler wrote:If I implied that I believe that D ranges were based on Boost.Range, then I apologize. I don't believe that. I suspect (but don't know) that ranges in D were independently invented without knowledge of the long history of them in C++. Which is fine except for the claims that C++ is playing catch-up. It's not.Ho come on, that's pretty obvious that C++ is playing catch up with all the new goodies there are in modern programming languages (which includes D, but not only). There is nothing wrong with it. This is why the dev cycle went from eternity between 2 versions to few years. The talking point of the C++ inner circle has been super weird to say the least. It is like admitting it would be a supreme shame, while it is in fact the sign of a community that which to bring the best to its users, something nobody should be ashamed of.This is where you get it wrong. Looking at what others are doing and adopting the good ideas is the characteristic of a language community that is focused on improving the language rather than participating in some ego battle. There was no disparagement of your work as far as I can tell. The fact you choose to take it that way is what elicit this conversation in the first place.Anyhow, it's best for us all to focus on doing good work instead of pettily fighting for irrelevant credit.I only jumped in when I saw some disparagement of C++ and my work which (IMO) was both petty and wrong. I would very much like to drop this and get back to productive work. \e
Oct 10 2015
On 10/10/15 12:58 AM, Eric Niebler wrote:Trying to express algorithms without any clear abstraction of "position within range" (independent of ranges) is hard and awkward, and occasionally causes algorithms to be less efficient.I agree that ranges are a weaker basis than iterators. But it's not necessarily that a notion of position is the only way out. Ranges can be made as strong a basis by adding the O(1) primitives r1.before(r2) and r1.after(r2) that return the prefix/suffix following r2 within r1. With those I hope to be able to show easily that algorithms needing "iterator in the middle" can be redone. I think I need to sit down and define these primitives (albeit they aren't used that frequently) and use them in a few fundamental algorithms to just close the matter once and for all. Andrei
Oct 09 2015
On Sat, Oct 10, 2015 at 09:52:22AM +0300, Andrei Alexandrescu via Digitalmars-d wrote:On 10/10/15 12:58 AM, Eric Niebler wrote:I assume .before would be implemented in a specialization of forward ranges, and .after in a specialization of bidirectional ranges?Trying to express algorithms without any clear abstraction of "position within range" (independent of ranges) is hard and awkward, and occasionally causes algorithms to be less efficient.I agree that ranges are a weaker basis than iterators. But it's not necessarily that a notion of position is the only way out. Ranges can be made as strong a basis by adding the O(1) primitives r1.before(r2) and r1.after(r2) that return the prefix/suffix following r2 within r1. With those I hope to be able to show easily that algorithms needing "iterator in the middle" can be redone.I think I need to sit down and define these primitives (albeit they aren't used that frequently) and use them in a few fundamental algorithms to just close the matter once and for all.[...] It would also fix the current bug in nextPermutation that claims that it supports bidirectional ranges, when in fact it requires random access ranges, precisely because reversing the last n elements requires the "iterator in the middle" construct. T -- Gone Chopin. Bach in a minuet.
Oct 10 2015
On 10/5/2015 7:31 PM, Eric Niebler wrote:The design of the D ranges and algorithms owe quite a lot to C++, and I've heard Andrei say as much.D ranges owe plenty to C++ iterators and algorithms, no doubt. Boost ranges, I can't agree.Stepanov did the hard work of defining common algorithms in terms of iterators of different strength. Given that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another.It seems obvious in retrospect, I agree. But looking at the early Boost ranges, they didn't take the obvious step :-)When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++. My work is based on Boost.Range. I only posted here to clear up what appeared to me to be confusion about that.
Oct 06 2015
On Thursday, 1 October 2015 at 05:47:25 UTC, Eric Niebler wrote: ...[snip]...Hope that clears things up.It does, thank you.Eric P.S. I see lots of people here assuming that C++ is playing catch-up to D because D has ranges and C++ doesn't yet. That is ignoring the long history of ranges in C++. C++ got ranges in the form of the Boost.Range library by Thorsten Ottoson sometime in the early 00's. Andrei didn't implement D's ranges until many years after. The ranges idea is older than dirt. It's not a D invention.Fair point, I did overlook boost.range when considering the C++ range options. bye lobo
Oct 01 2015
On Thursday, 1 October 2015 at 05:47:25 UTC, Eric Niebler wrote:On Thursday, 1 October 2015 at 04:08:00 UTC, bitwise wrote:Did you look at my example(this one is updated)? http://ideone.com/X1JAEn I've factored out a 'range_iterator' in this version. I would probably rethink the way I've done the chaining, but there is nothing complicated about adding foreach support as I've implemented it in my example. From the callers point of view, it's a typedef and two functions. I really doubt anything could be done that would offer a perceptible performance gain over what I've done in my example. I suppose it's a moot point if C++ is actually planning native range support. BitI understand, but the C++ committee seems very conservative to me, so when it's this easy to add for(:) support by giving ranges begin()/end() functions, it makes me doubt they will actually change the language for it.As of C++11, C++ has the for(auto e:range) control structure you are looking for. I would be using it here except for one thing: in my proposal, begin() and end() don't have to return objects of the same type! begin() must return an iterator and end() must return something that is EqualityComparable with the iterator -- but it doesn't have to be an iterator. That makes many types of iterators vastly simpler to implement and more efficient at runtime. C++'s built-in range-based for(:) loop expects begin() and end() to return objects of the same type. The committee is already talking about loosening that constraint so that the ranges I'm proposing Just Work with the existing built-in looping construct. Until then, there is an ugly macro. It's a temporary hack, nothing more.
Oct 01 2015
On 1 October 2015 at 08:47, H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> wrote:[...] (D has seriously ruined my life; I simply can't bring myself to go back to C++ anymore. At least not voluntarily.)OMG, this! Seriously, this is more true than I can express in words ;) My career is severely damaged by D, because I can't use D at work (no matter how hard I try, for however many years), and I can't enjoy coding C++ anymore! >_<Also, this seems to confirm that C++ is gradually falling to the position where it's playing catch-up with respect to innovations in newer languages like D and Rust. The fact that ranges are being proposed for the C++ standard library is a big endorsement of D, IMO.My strategy has been to backport D ideas into C++ over the past year since my last failed attempt to get D into my office, and this has been an AGONISING and extremely time consuming process. I have slices, ranges (as best I can), delegates, and my code is generally D-ish. Most people in the office like working with it, and they're starting to realise the connection to D ;) None of it would be possible without C++11 variadic templates. It's been the biggest improvement to C++ for a long time, even though some of the constructs they lead to are far more obtuse than anything I've ever seen emerge in C++ before.
Oct 03 2015
On Saturday, 3 October 2015 at 08:58:26 UTC, Manu wrote:My strategy has been to backport D ideas into C++ over the past year since my last failed attempt to get D into my office, and this has been an AGONISING and extremely time consuming process. I have slices, ranges (as best I can), delegates, and my code is generally D-ish.What do you need delegates for when you have flexible function-object lambdas? Microsoft GSL have array_view for slicing and transferring views of arrays/memory to functions. It supports fixed sized slices (so you don't transfer length) and multi dimensional slices). A bit rough, but usable: https://github.com/Microsoft/GSL/blob/master/tests/array_view_tests.cpp
Oct 05 2015
On 09/29/2015 06:45 PM, deadalnix wrote:https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohYay! :) I almost gave the same talk! This talk could have been a part of DConf 2014 if H. S. Teoh or I could go to the conference. Here is an email exchange between us in January 2014: Ali -- "I wanted to let you know that your article "Component programming with ranges" would be an excellent topic for DConf 2014 and I would love to hear it from you. :) In case you are presenting something else or simply cannot make it to the conference, I would like to propose the same topic for DConf 2014. (But I am sure you and others have done the same already. :) )" H. S. Teoh -- "please feel free to propose this topic; it would be nice (for me!) to hear it from somebody else's viewpoint! ;-)" Ali
Sep 30 2015
On 09/30/2015 08:02 AM, Ali Çehreli wrote:if H. S. Teoh or I could go to the conference.Oops! I've mixed up the years. I did go to DConf 2014 but not DConf 2015. Still... :) Ali
Sep 30 2015
On Wednesday, 30 September 2015 at 01:45:49 UTC, deadalnix wrote:https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohThanks for the link, I watched the whole video today and it was a very good presentation by Niebler. He mentions D and Teoh's example right at the top and gets an ovation at the 49 minute-mark, once he's gone through his entire C++ version of Teoh's D example. Interesting that they're using the pipe symbol for chaining, more explicitly mimicking the unix command line. The fact that scoping meant that views and actions were explicitly labeled could be a nice benefit, though I generally dislike such verbosity normally. It is amazing how noisy some of the implementation code with templates is in C++: I felt like I was looking at some Haskell variant compared to how clean D would look for the same code.
Sep 30 2015
On Wednesday, 30 September 2015 at 16:06:59 UTC, Joakim wrote:On Wednesday, 30 September 2015 at 01:45:49 UTC, deadalnix wrote:Another thing I noticed that showed D nice-ness is when he was converting the weeks ranges to a string, the flow of the functions went from the bottom up (he specifically said "start from the bottom"). It looks so weird to me after using UFCS for so long.https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohThanks for the link, I watched the whole video today and it was a very good presentation by Niebler. He mentions D and Teoh's example right at the top and gets an ovation at the 49 minute-mark, once he's gone through his entire C++ version of Teoh's D example. Interesting that they're using the pipe symbol for chaining, more explicitly mimicking the unix command line. The fact that scoping meant that views and actions were explicitly labeled could be a nice benefit, though I generally dislike such verbosity normally. It is amazing how noisy some of the implementation code with templates is in C++: I felt like I was looking at some Haskell variant compared to how clean D would look for the same code.
Sep 30 2015
On 9/30/15 12:12 PM, wobbles via Digitalmars-d wrote:On Wednesday, 30 September 2015 at 16:06:59 UTC, Joakim wrote:The 'start from the bottom' part of that part of the code was because he wanted to talk about it in that order. The logic in the code flowed in exactly the order you'd expect it to: leading padding bytes first followed by formatted days.On Wednesday, 30 September 2015 at 01:45:49 UTC, deadalnix wrote:Another thing I noticed that showed D nice-ness is when he was converting the weeks ranges to a string, the flow of the functions went from the bottom up (he specifically said "start from the bottom"). It looks so weird to me after using UFCS for so long.https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohThanks for the link, I watched the whole video today and it was a very good presentation by Niebler. He mentions D and Teoh's example right at the top and gets an ovation at the 49 minute-mark, once he's gone through his entire C++ version of Teoh's D example. Interesting that they're using the pipe symbol for chaining, more explicitly mimicking the unix command line. The fact that scoping meant that views and actions were explicitly labeled could be a nice benefit, though I generally dislike such verbosity normally. It is amazing how noisy some of the implementation code with templates is in C++: I felt like I was looking at some Haskell variant compared to how clean D would look for the same code.
Sep 30 2015
On 09/30/2015 06:06 PM, Joakim wrote:It is amazing how noisy some of the implementation code with templates is in C++: I felt like I was looking at some Haskell variant compared to how clean D would look for the same code.It's easy to write a clean Haskell version, in case you were trying to imply otherwise.
Oct 01 2015
I haven't watched it yet, but it seems to be similar to this one from NWCPP I watched recently: https://www.youtube.com/watch?v=8yV2ONeWXyI
Sep 30 2015
On Wednesday, 30 September 2015 at 01:45:49 UTC, deadalnix wrote:https://www.youtube.com/watch?v=mFUXNMfaciE From http://wiki.dlang.org/Component_programming_with_ranges Congrat H. S. TeohD's ranges are inarguably the best part of the language and one of the major reasons to use it despite its shortcomings.
Sep 30 2015