Re: DIP74 - where is at?
On 11 October 2015 at 14:35, Jonathan M Davis via Digitalmars-d wrote: > On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote: >> >> If we go these DIP road, there is no coming back and this will get in the >> way of a principled approach. > > > Then come up with an alternative DIP which shows a better way to solve this. > As it stands, it looks likely that we'll end up with some form of DIP 74, > and if you have a better proposal, then now is probably the time to do it. > > Personally, I obviously haven't been following this closely enough, because > I don't understand why something like RefCounted can't be made to do what we > need with regards to reference counting and classes. It does get a bit nasty > when inheritance and whatnot get involved, but C++ was able to solve that > easily enough, and we should be able to do the same. C++ didn't solve anything(?). C++ doesn't support ref-counting at all! shared_ptr is not a part of the language, or a proper ref counting mechanism. It's just a hack; it's awkward, and really inefficient (the compiler can't optimise it). ARC requires language knowledge. I don't know what language primitives can possibly allow the compiler to do proper ref fiddling optimisation with a lib?
Re: DIP74 - where is at?
On 11 October 2015 at 14:25, deadalnix via Digitalmars-d wrote: > On Sunday, 11 October 2015 at 02:01:09 UTC, Jonathan M Davis wrote: >> >> AFAIK, Walter and Andrei are still in favor of something that's at least >> similar to DIP 74. Andrei made a comment in a thread just the other day that >> indicated that he was in favor of having a way to build reference counting >> into classes. So, I don't know why you think that it's not going to be >> implemented other than the fact that it hasn't been implemented yet. It >> wouldn't surprise me if the DIP needed some tweaking though. >> > > Yes, and that's quite ridiculous. I mean this is getting into ridiculous ego > battle. Remind of that concept vs static if grand debate, the peak of > ridiculousness (everybody know you don't need type system when you have if > statement and vice versa, so the same must be true at compile time as well). > > When a direction obviously showed to be the wrong one, the rational thing to > do is not to double down in order to not admit one is wrong. > > DIP25 implementation showed a ton of limitations and pitfalls. It isn't even > possible to do a slice type with eager deallocation, just one with deferred > deallocation, with complex strategies to make it all safe. > > It is a sign of a poorly thought out language addition. > >> It wouldn't surprise me though if something like the possibility of >> getting D into another company relied on something like DIP 74 helped push >> it along and got it sorted out faster. Clearly, Walter and Andrei think that >> it's an issue and have done some work on it at the theoretical level, but I >> don't know where it sits on their priority list. And even if DIP 74 were >> fully sorted out tomorrow, it would still require Walter or someone else >> actually implementing it, and that's probably not a small undertaking. >> >> - Jonathan M Davis > > > Yeah, we saw what happens with attributes. Don't get me wrong, attribute are > a very useful addition to the language and all, but the current > implementation has some serious flaws, none of them could be addressed as it > was pushed out of the door in an inconsequent manner. The fact that > dlang.org is littered of antipaterns usage of them is quite telling. What's wrong with attributes? I can think of some needed additions to finish the job, but what would you say is fundamentally wrong with them as is? > I'm all for pushing useful feature, especially if that can drive adoption in > a company. But using it as an excuse for releasing half backed feature is > VERY short sighted. What would you do instead? I'm happy with DIP74, and I haven't followed threads where people have objected and why...?
Re: DIP74 - where is at?
On 11 October 2015 at 14:16, deadalnix via Digitalmars-d wrote: > On Sunday, 11 October 2015 at 01:48:05 UTC, Manu wrote: >> >> I'm rather in favour of DIP74... what's unprincipled about it? What would >> you do instead? >> > > Well, DIP25 and DIP74 are ad hoc adding to the language to support specific > use cases. I think the whole thing is wrong headed. I don't really see that DIP25 and DIP74 are particularly closely related. DIP25 is a lame cop-out with respect to scope. I was a major backer of a proper scope implementation, and given that, I don't/didn't support DIP25 at all. DIP74 on the other hand introduces 2 magic functions that the compiler calls as the appropriate moments to implement ref counting. The implementation is somewhat detail, theoretically changeable in the future, but I think language support for ref-counting primitives is critical for ref counting to be efficient and simple. Look at C++, and we see a disaster. C++ basically implemented rval-references to improve (not solve) the RC problem... we don't have rval-ref's in D, so we're screwed from the library angle. > Ideally when designing the language you want to have a set of principled > tools added to the language that enable the uses cases you want. You don't > bake the uses cases into the language. Inevitably, new use cases crop up, > they get poor support and/or ends up as new addition into the language, with > more and more complexity along the road. > > The problem at hand is fairly well know at this stage: it is ownership. > Everything else can be done as library. Yup, I was firmly behind scope (ie, borrowing), but that was destroyed, and DIP25 kinda cements the death of that :( That said, this has nothing to do with ref-counting. Scheduling (and optimising) calls to inc/dec is not something I've seen language tools implement efficiently. The compiler needs to understand that it has the authority to elide pairs appropriately, even when the optimiser is unable to see the code that implements the inc/dec pair. I can't think of any way to do this without a foundation like DIP74...? > The DIP25/DIP74 combo is quite limited. It doesn't solve ownership transfer, > it forces an ownership model on the user, it doesn't reduce friction with > the GC, it doesn't allow to delegate memory management to the user (the only > kind that make sense). and worse, as these issue aren't orthogonal to these > DIP, they actively make these problem harder to solve. How? I don't see how opInc/opDec really changes the underlying type system or allocations mechanisms much, it just gives the compiler the opportunity to understand the optimise reference counting, which is a well understood problem. > Solution have been proposed to solve these. It is not hardly new. I mean C++ > obviously got the hint: > https://github.com/isocpp/CppCoreGuidelines/blob/09aef9bd86d933bc1e1ffe344eb2e73d2de15685/docs/Lifetimes%20I%20and%20II%20-%20v0.9.1.pdf > > If we go these DIP road, there is no coming back and this will get in the > way of a principled approach. DIP25 is done, I rejected it but it's done... I don't really see how DIP74 ruins anything?
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 06:10:32 UTC, Jonathan M Davis wrote: On Sunday, 11 October 2015 at 05:52:45 UTC, Freddy wrote: On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote: [...] Speaking of DIP74 can't we just wrap a class in a struct with use reference counting with and use alias this? alias is problematic, because it allows the class reference to escape. opDispatch doesn't have that problem, though there may be other complications that it introduces (I don't know). It does get kind of complicated though when you consider member functions which return the a reference to the object and things like that. So, while it's generally feasible, it's not that hard for it to become unsafe. How much that matters is debatable, but it could make it so that reference counting classes is infeasible in @safe code. - Jonathan M Davis Ok dispatch has that problem. You can escape the this pointer from within member functions. Always. There is no @safe reference counting without language support. Either the RC is backed into the language (DIP74) or ownership is baked into the language, so that RC can be baked into the library.
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 05:52:45 UTC, Freddy wrote: On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote: [...] Speaking of DIP74 can't we just wrap a class in a struct with use reference counting with and use alias this? alias is problematic, because it allows the class reference to escape. opDispatch doesn't have that problem, though there may be other complications that it introduces (I don't know). It does get kind of complicated though when you consider member functions which return the a reference to the object and things like that. So, while it's generally feasible, it's not that hard for it to become unsafe. How much that matters is debatable, but it could make it so that reference counting classes is infeasible in @safe code. - Jonathan M Davis
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 05:52:45 UTC, Freddy wrote:
Speaking of DIP74 can't we just wrap a class in a struct with
use reference counting with and use alias this?
Also how will DIP74 work with incremental compilation?
---
extern (D) class RcClass;
void func(RcClass a)
{
//opps
auto b = a;
return;
}
---
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 05:52:45 UTC, Freddy wrote: On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote: [...] Speaking of DIP74 can't we just wrap a class in a struct with use reference counting with and use alias this? You can. It is not safe, but it will do. Using type qualifier, one can get better than C++'s shared_ptr already.
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 05:18:26 UTC, Jonathan M Davis wrote: Well, if they won't listen, they won't listen. And if they're wrong, we'll be worse off for it. Unfortunately, I wasn't involved in those discussions and haven't looked into DIP 25 much (I was too busy at the time of the major discussion for it IIRC). So, I'm not familiar enough with it to have a properly informed opinion. But convincing Walter and Andrei is typically pretty difficult. They do come around eventually at least some of the time though. So, as frustrating as such discussions can be, they do bear fruit at least some of the time (whether it's by them convincing you or by you convincing them). And since DIP 25 has only been implemented with a flag rather than adding it to the language proper yet, there's still time to convince them before we're fully committed to it - as difficult as convincing them may be. - Jonathan M Davis Truth be told at the time I was doubtful a DIP25 like approach, but willing to give it a try. They had me convinced of that much. Maybe that wasn't that powerful, but maybe that was powerful enough for basics uses cases and would cut it. Seeing what comes out of it confirmed that no, it won't, and once you get DIP25 + DIP74 you are in the same ballpark as other proposals in term of language additions, but barley measure in terms of capabilities.
Re: DIP74 - where is at?
On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote: [...] Speaking of DIP74 can't we just wrap a class in a struct with use reference counting with and use alias this?
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote: The problem at hand is fairly well know at this stage: it is ownership. Everything else can be done as library. This.
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 04:56:25 UTC, deadalnix wrote: On Sunday, 11 October 2015 at 04:35:03 UTC, Jonathan M Davis wrote: On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote: If we go these DIP road, there is no coming back and this will get in the way of a principled approach. Then come up with an alternative DIP which shows a better way to solve this. As it stands, it looks likely that we'll end up with some form of DIP 74, and if you have a better proposal, then now is probably the time to do it. I have, other have as well, in fact there was a lengthy discussion in private between Walter, Andrei, myself and some other where very precise proposal has been made. I'm sorry but that's bullshit. I'm tired of reexplaining the same thing again and again while is it clear that nobody cares about facts here. If people would care about facts, the DIP25 fiasco would have been enough to put the ideas back on the table. Well, if they won't listen, they won't listen. And if they're wrong, we'll be worse off for it. Unfortunately, I wasn't involved in those discussions and haven't looked into DIP 25 much (I was too busy at the time of the major discussion for it IIRC). So, I'm not familiar enough with it to have a properly informed opinion. But convincing Walter and Andrei is typically pretty difficult. They do come around eventually at least some of the time though. So, as frustrating as such discussions can be, they do bear fruit at least some of the time (whether it's by them convincing you or by you convincing them). And since DIP 25 has only been implemented with a flag rather than adding it to the language proper yet, there's still time to convince them before we're fully committed to it - as difficult as convincing them may be. - Jonathan M Davis
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 04:35:03 UTC, Jonathan M Davis wrote: On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote: If we go these DIP road, there is no coming back and this will get in the way of a principled approach. Then come up with an alternative DIP which shows a better way to solve this. As it stands, it looks likely that we'll end up with some form of DIP 74, and if you have a better proposal, then now is probably the time to do it. I have, other have as well, in fact there was a lengthy discussion in private between Walter, Andrei, myself and some other where very precise proposal has been made. I'm sorry but that's bullshit. I'm tired of reexplaining the same thing again and again while is it clear that nobody cares about facts here. If people would care about facts, the DIP25 fiasco would have been enough to put the ideas back on the table. The one place in-language where I'm sure that something like RefCounted doesn't do it is exceptions, since we really should have a way to make those reference counted, but you can only throw something derived from Throwable - which means a class and not a wrapper around one. So, we need a tweak of some kind to the language there, but that's pretty specific, whereas it _should_ be possible to get something like RefCounted to at least solve the normal cases. Clearly though, Walter and Andrei have come to the conclusion that it's not. Proposal included solution for this problem. Exception ownerhip is transferred to the runtime when thrown, and the runtime transfer it back to the catch block that effectively catches it.
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote: If we go these DIP road, there is no coming back and this will get in the way of a principled approach. Then come up with an alternative DIP which shows a better way to solve this. As it stands, it looks likely that we'll end up with some form of DIP 74, and if you have a better proposal, then now is probably the time to do it. Personally, I obviously haven't been following this closely enough, because I don't understand why something like RefCounted can't be made to do what we need with regards to reference counting and classes. It does get a bit nasty when inheritance and whatnot get involved, but C++ was able to solve that easily enough, and we should be able to do the same. The one place in-language where I'm sure that something like RefCounted doesn't do it is exceptions, since we really should have a way to make those reference counted, but you can only throw something derived from Throwable - which means a class and not a wrapper around one. So, we need a tweak of some kind to the language there, but that's pretty specific, whereas it _should_ be possible to get something like RefCounted to at least solve the normal cases. Clearly though, Walter and Andrei have come to the conclusion that it's not. - Jonathan M Davis
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 02:01:09 UTC, Jonathan M Davis wrote: AFAIK, Walter and Andrei are still in favor of something that's at least similar to DIP 74. Andrei made a comment in a thread just the other day that indicated that he was in favor of having a way to build reference counting into classes. So, I don't know why you think that it's not going to be implemented other than the fact that it hasn't been implemented yet. It wouldn't surprise me if the DIP needed some tweaking though. Yes, and that's quite ridiculous. I mean this is getting into ridiculous ego battle. Remind of that concept vs static if grand debate, the peak of ridiculousness (everybody know you don't need type system when you have if statement and vice versa, so the same must be true at compile time as well). When a direction obviously showed to be the wrong one, the rational thing to do is not to double down in order to not admit one is wrong. DIP25 implementation showed a ton of limitations and pitfalls. It isn't even possible to do a slice type with eager deallocation, just one with deferred deallocation, with complex strategies to make it all safe. It is a sign of a poorly thought out language addition. It wouldn't surprise me though if something like the possibility of getting D into another company relied on something like DIP 74 helped push it along and got it sorted out faster. Clearly, Walter and Andrei think that it's an issue and have done some work on it at the theoretical level, but I don't know where it sits on their priority list. And even if DIP 74 were fully sorted out tomorrow, it would still require Walter or someone else actually implementing it, and that's probably not a small undertaking. - Jonathan M Davis Yeah, we saw what happens with attributes. Don't get me wrong, attribute are a very useful addition to the language and all, but the current implementation has some serious flaws, none of them could be addressed as it was pushed out of the door in an inconsequent manner. The fact that dlang.org is littered of antipaterns usage of them is quite telling. I'm all for pushing useful feature, especially if that can drive adoption in a company. But using it as an excuse for releasing half backed feature is VERY short sighted.
Re: -> and :: operators
On 10/9/2015 12:48 PM, Dmitry Olshansky wrote: On 09-Oct-2015 21:44, Freddy wrote: Stole from D? You mean java right? There is no value type objects in Java so no. More likely C#. Since C# was an internal Microsoft project at the time this was developed for D, no.
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 01:48:05 UTC, Manu wrote: I'm rather in favour of DIP74... what's unprincipled about it? What would you do instead? Well, DIP25 and DIP74 are ad hoc adding to the language to support specific use cases. I think the whole thing is wrong headed. Ideally when designing the language you want to have a set of principled tools added to the language that enable the uses cases you want. You don't bake the uses cases into the language. Inevitably, new use cases crop up, they get poor support and/or ends up as new addition into the language, with more and more complexity along the road. The problem at hand is fairly well know at this stage: it is ownership. Everything else can be done as library. The DIP25/DIP74 combo is quite limited. It doesn't solve ownership transfer, it forces an ownership model on the user, it doesn't reduce friction with the GC, it doesn't allow to delegate memory management to the user (the only kind that make sense). and worse, as these issue aren't orthogonal to these DIP, they actively make these problem harder to solve. Solution have been proposed to solve these. It is not hardly new. I mean C++ obviously got the hint: https://github.com/isocpp/CppCoreGuidelines/blob/09aef9bd86d933bc1e1ffe344eb2e73d2de15685/docs/Lifetimes%20I%20and%20II%20-%20v0.9.1.pdf If we go these DIP road, there is no coming back and this will get in the way of a principled approach.
Re: DIP74 - where is at?
On Sunday, 11 October 2015 at 00:20:08 UTC, deadalnix wrote: It doesn't looks like it is getting implemented. And, to be honest, I'd rather go a principle approach + library support rather than a pie of hacks. The pile of hacks approach is what made C++ C++. AFAIK, Walter and Andrei are still in favor of something that's at least similar to DIP 74. Andrei made a comment in a thread just the other day that indicated that he was in favor of having a way to build reference counting into classes. So, I don't know why you think that it's not going to be implemented other than the fact that it hasn't been implemented yet. It wouldn't surprise me if the DIP needed some tweaking though. Regardless, now is not the best time to ask this sort of question, because Walter and Andrei are on their trip to Romania, and they're going to have a limited presence in the newsgroup at the moment. It wouldn't surprise me though if something like the possibility of getting D into another company relied on something like DIP 74 helped push it along and got it sorted out faster. Clearly, Walter and Andrei think that it's an issue and have done some work on it at the theoretical level, but I don't know where it sits on their priority list. And even if DIP 74 were fully sorted out tomorrow, it would still require Walter or someone else actually implementing it, and that's probably not a small undertaking. - Jonathan M Davis
Re: DIP74 - where is at?
I'm rather in favour of DIP74... what's unprincipled about it? What would you do instead? On 11 October 2015 at 10:20, deadalnix via Digitalmars-d wrote: > On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote: >> >> So I have another upcoming opportunity to introduce D in my workplace, >> this time as a front-end/plugin language to our C++ infrastructure, which is >> promising since I already have considerable experience in this area (my work >> at Remedy with Quantum Break), and there is a lot of recent work to interact >> better with C++, which we will stress-test extensively. >> >> You only get so many shots at this; but this is a particularly promising >> opportunity, since the C++ code is a nightmare, and the contrast against D >> will allow a lot of coders to see the advantage. >> >> There is however one critical missing feature, DIP74... where is it at >> currently? How is it going? Is it likely to be accepted in the near-term? >> Some sort of approximate timeline? >> >> I think it would be a mistake for me to introduce this without DIP74, >> since we will rely on it VERY heavily, and the machinery to work-around it >> will start to look just as heavy-weight as the C++ code I'm trying to >> deprecate... but then waiting on it starts to look like missing the window >> of opportunity. >> >> Thoughts? > > > It doesn't looks like it is getting implemented. And, to be honest, I'd > rather go a principle approach + library support rather than a pie of hacks. > > The pile of hacks approach is what made C++ C++. >
Re: -> and :: operators
On Saturday, 10 October 2015 at 22:54:15 UTC, Warwick wrote: On Friday, 9 October 2015 at 19:48:39 UTC, Dmitry Olshansky wrote: On 09-Oct-2015 21:44, Freddy wrote: Stole from D? You mean java right? There is no value type objects in Java so no. More likely C#. Delphi / Object Pascal had it in the mid 90s IIRC. Long before C#, and possibly before Java was released. Simula is the origin, it came about in the 60s.
Re: DIP74 - where is at?
On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote: So I have another upcoming opportunity to introduce D in my workplace, this time as a front-end/plugin language to our C++ infrastructure, which is promising since I already have considerable experience in this area (my work at Remedy with Quantum Break), and there is a lot of recent work to interact better with C++, which we will stress-test extensively. You only get so many shots at this; but this is a particularly promising opportunity, since the C++ code is a nightmare, and the contrast against D will allow a lot of coders to see the advantage. There is however one critical missing feature, DIP74... where is it at currently? How is it going? Is it likely to be accepted in the near-term? Some sort of approximate timeline? I think it would be a mistake for me to introduce this without DIP74, since we will rely on it VERY heavily, and the machinery to work-around it will start to look just as heavy-weight as the C++ code I'm trying to deprecate... but then waiting on it starts to look like missing the window of opportunity. Thoughts? It doesn't looks like it is getting implemented. And, to be honest, I'd rather go a principle approach + library support rather than a pie of hacks. The pile of hacks approach is what made C++ C++.
DIP74 - where is at?
So I have another upcoming opportunity to introduce D in my workplace, this time as a front-end/plugin language to our C++ infrastructure, which is promising since I already have considerable experience in this area (my work at Remedy with Quantum Break), and there is a lot of recent work to interact better with C++, which we will stress-test extensively. You only get so many shots at this; but this is a particularly promising opportunity, since the C++ code is a nightmare, and the contrast against D will allow a lot of coders to see the advantage. There is however one critical missing feature, DIP74... where is it at currently? How is it going? Is it likely to be accepted in the near-term? Some sort of approximate timeline? I think it would be a mistake for me to introduce this without DIP74, since we will rely on it VERY heavily, and the machinery to work-around it will start to look just as heavy-weight as the C++ code I'm trying to deprecate... but then waiting on it starts to look like missing the window of opportunity. Thoughts?
Re: Shout out to D at cppcon, when talkign about ranges.
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. 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 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.
Re: -> and :: operators
On Friday, 9 October 2015 at 19:48:39 UTC, Dmitry Olshansky wrote: On 09-Oct-2015 21:44, Freddy wrote: Stole from D? You mean java right? There is no value type objects in Java so no. More likely C#. Delphi / Object Pascal had it in the mid 90s IIRC. Long before C#, and possibly before Java was released.
Re: Shout out to D at cppcon, when talkign about ranges.
On 10/10/15 9:06 PM, Eric Niebler wrote:
On Saturday, 10 October 2015 at 06:15:10 UTC, Andrei Alexandrescu wrote:
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.
If I implied that I believe that D ranges were based on Boost.Range,
then I apologize. I don't believe that.
Well the simple fact is then that P.S. has done an awful job at
conveying your point.
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.
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.
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.
Andrei
Re: Shout out to D at cppcon, when talkign about ranges.
On Sat, Oct 10, 2015 at 06:06:59PM +, Eric Niebler via Digitalmars-d wrote: > On Saturday, 10 October 2015 at 06:15:10 UTC, Andrei Alexandrescu wrote: [...] > >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. [...] 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.
Re: Shout out to D at cppcon, when talkign about ranges.
On Saturday, 10 October 2015 at 06:15:10 UTC, Andrei Alexandrescu wrote: 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. 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. 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
Re: Marketing for D: Making D an official Cloud Foundry built-in language
On Saturday, 10 October 2015 at 02:49:23 UTC, Rikki Cattermole wrote: [...] Wrong way round. Bundle dub with dmd is already planned. I hoped 2.069 already contains dub, maybe with 2.070 [...] I am sure Walter will have no problem with you creating a custom archive, perhaps with tar? If that suits you better. Check with him however. [...] That may not be possible. Unless you want to make dub dependent upon git. Which it currently isn't. Right now it uses e.g. Github to create an archive of the repository and download that. Although some trade off will be possible. Also it all goes through code.dlang.org the last I remember. yes it would depend on git. I suggest a new dub attribute. The value starts with a protocol. Like file:// if it is a zip on the local pc or a file on a file server. git:// if it is a git repository. [...] It exists, the support is there. Just not in the dub configuration file. It is something that would be nice to have. This feature would also be a "work around" for 4). I will file feature requests
Re: Shout out to D at cppcon, when talkign about ranges.
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: > >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 assume .before would be implemented in a specialization of forward ranges, and .after in a specialization of bidirectional ranges? > 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.
Re: Categorizing Ranges
On Wednesday, 7 October 2015 at 15:39:03 UTC, Jonathan M Davis wrote: Eager is far more general. Also, while the drop* functions are eager, the take* functions are not. I don't recall the precise details of these particular ranges off the top of my head (away from computer so can't easily check), but one nasty little detail of supposedly lazy ranges is that they are often eager for the first element, lazy thereafter -- and even there it's subtly different from 'true' laziness inasmuch as the new values are generated at the point of popping rather than the point of access to the new front. In most cases that's an implementation detail, but it gets _very_ interesting when the elements of your range are non-deterministic.
