digitalmars.D - Perhaps we need to defer const for a while (3.0?)
- Russell Lewis (25/25) Jan 02 2008 Originally, Walter argued that we didn't need const in D because it was
- Janice Caron (6/8) Jan 02 2008 We don't? I'm happy enough with what's been promised for D2.009. There
- Russell Lewis (9/18) Jan 02 2008 !
- Jarrett Billingsley (6/8) Jan 02 2008 Hear hear. I've had about a bellyfull of discussions on a feature whose...
- Carlos Santander (8/20) Jan 02 2008 True. Having found (not long ago) how much can be done with metaprogramm...
- 0ffh (7/10) Jan 03 2008 Well, there is at least the admirable std2 effort of bb, who has
- Bill Baxter (5/17) Jan 03 2008 Thanks, frank.
- John Reimer (26/56) Jan 02 2008 It's actually a problem of molding an idea to fit a language that has
- Russell Lewis (12/20) Jan 02 2008 Heh. I agree on both points. I made a passing reference to this in my
- Walter Bright (4/7) Jan 02 2008 I agree. And I've learned a hell of a lot in the process of working on
- Don Clugston (2/10) Jan 03 2008 Any plans for papers on it?
- Christopher Wright (7/18) Jan 03 2008 The popular topics for papers are systems, algorithms, and experimental
- Bruce Adams (8/25) Jan 03 2008 You'd be surprised. I remember reading an interesting paper about the
- Walter Bright (2/13) Jan 05 2008 Andrei thinks we've broken new ground with it, and a paper is in order.
- Carlos Santander (5/74) Jan 02 2008 ... and this one are very good points, IMHO.
- 0ffh (7/10) Jan 02 2008 Well I just hope the const fans are more or less satisfied (I'm
- Sean Kelly (12/15) Jan 03 2008 Personally, I think the current design feels pretty good. It doesn't
- Russell Lewis (9/25) Jan 03 2008 I agree, but the thing that concerns me is that I suspect that the
- Bruce Adams (6/29) Jan 03 2008 It depends on the language (designer) and the community. Larry Wall seem...
- bearophile (4/5) Jan 03 2008 That's just one of the many things that makes me (happily) use Python in...
- Bruce Adams (13/19) Jan 04 2008 Disclaimer: I am not a serious Perl user. Its just a language built on t...
- bearophile (8/13) Jan 04 2008 From Python 2.4 we have the subprocess module in the std lib:
- Bruce Adams (19/33) Jan 04 2008 =
Originally, Walter argued that we didn't need const in D because it was confusing and didn't solve the optimization problems that it was intended to solve. But then people made very good arguments about why we need const. So Walter brought const into the language, but with better semantics (than C++). Problem was, it was confusing to many people, and it didn't solve all the problems that it was intended to solve. Sound familiar? Now we've gone through additional iterations (how many so far?) and we still don't have it working quite right. IMHO, this is the time to recognize the *empirical* fact that as yet neither do we understand the full requirements of what const should be trying to do nor do we have an easily-understandable way to implement it. I don't think that this is a problem with the current design; it is a problem with our theoretical grasp of the space. Walter, I'm not attacking you, truly. I hold you in the highest regard, and you have worked very hard for a very long time on const, and on D in general. But const isn't working. My guess is that we need the PhD's to write more papers on the theory of const before us mere mortals will be able to use it in our practical languages. A formal, mathematical model for const, as it applies to imperative languages, with an exhaustive examination of the various use cases (assignment, reference, duplication, etc.) would be nice. Maybe it's time to stop spinning our wheels here and start making progress on other things.
Jan 02 2008
On 1/2/08, Russell Lewis <webmaster villagersonline.com> wrote:Now we've gone through additional iterations (how many so far?) and we still don't have it working quite right.We don't? I'm happy enough with what's been promised for D2.009. There are just a few outstanding issues (to preserve or not to preserve head constancy when determining template type, const-at-the-start versus const-at-the-end versus other alternatives for member functions, etc.), but for the most part, I think Walter has it cracked.
Jan 02 2008
Janice Caron wrote:On 1/2/08, Russell Lewis <webmaster villagersonline.com> wrote:! Those seem to me to be the most tricky issues. If we don't have them solved, then we don't really understand the space, IMHO. If const was atomic theory, then our current understanding of it is akin to the theory that "electrons move in circular orbits around a nucleus." It's a useful approximation, but we still need to discover quantum mechanics. And yes, even quantum mechanics has problems...but I hope you get the point. :)Now we've gone through additional iterations (how many so far?) and we still don't have it working quite right.We don't? I'm happy enough with what's been promised for D2.009. There are just a few outstanding issues (to preserve or not to preserve head constancy when determining template type, const-at-the-start versus const-at-the-end versus other alternatives for member functions, etc.), but for the most part, I think Walter has it cracked.
Jan 02 2008
"Russell Lewis" <webmaster villagersonline.com> wrote in message news:flgm71$30h3$1 digitalmars.com...Maybe it's time to stop spinning our wheels here and start making progress on other things.Hear hear. I've had about a bellyfull of discussions on a feature whose utility I just don't see (Janice, don't reply to me telling me why I need it, all you consties have made your point. repeatedly.). I'd much rather we spent our time making metaprogramming more powerful.
Jan 02 2008
Jarrett Billingsley escribió:"Russell Lewis" <webmaster villagersonline.com> wrote in message news:flgm71$30h3$1 digitalmars.com...Same here.Maybe it's time to stop spinning our wheels here and start making progress on other things.Hear hear. I've had about a bellyfull of discussions on a feature whose utility I just don't see (Janice, don't reply to me telling me why I need it, all you consties have made your point. repeatedly.).I'd much rather we spent our time making metaprogramming more powerful.True. Having found (not long ago) how much can be done with metaprogramming, I keep wanting more. I wonder if we could have something like D 1.5 where some 2.0 features could be backported, including macros, whenever they come, but definitely not const. -- Carlos Santander Bernal
Jan 02 2008
Carlos Santander wrote:I wonder if we could have something like D 1.5 where some 2.0 features could be backported, including macros, whenever they come, but definitely not const.Well, there is at least the admirable std2 effort of bb, who has backported D2 Phobos to D1. About the language itself, I suspect that at some point of time GDC will start to grow D2 features. Then unloved features (like the const you mention) could be hacked away from it. =) regards, frank
Jan 03 2008
0ffh wrote:Carlos Santander wrote:Thanks, frank. I'd love to see the D2.0 features that don't break existing code added to D1.0, like the new string literals and __traits, and foreach(i; 0..10). --bbI wonder if we could have something like D 1.5 where some 2.0 features could be backported, including macros, whenever they come, but definitely not const.Well, there is at least the admirable std2 effort of bb, who has backported D2 Phobos to D1. About the language itself, I suspect that at some point of time GDC will start to grow D2 features. Then unloved features (like the const you mention) could be hacked away from it. =) regards, frank
Jan 03 2008
Russell Lewis wrote:Originally, Walter argued that we didn't need const in D because it was confusing and didn't solve the optimization problems that it was intended to solve. But then people made very good arguments about why we need const. So Walter brought const into the language, but with better semantics (than C++). Problem was, it was confusing to many people, and it didn't solve all the problems that it was intended to solve. Sound familiar? Now we've gone through additional iterations (how many so far?) and we still don't have it working quite right. IMHO, this is the time to recognize the *empirical* fact that as yet neither do we understand the full requirements of what const should be trying to do nor do we have an easily-understandable way to implement it. I don't think that this is a problem with the current design; it is a problem with our theoretical grasp of the space.It's actually a problem of molding an idea to fit a language that has already been mostly specified.Walter, I'm not attacking you, truly. I hold you in the highest regard, and you have worked very hard for a very long time on const, and on D in general. But const isn't working. My guess is that we need the PhD's to write more papers on the theory of const before us mere mortals will be able to use it in our practical languages. A formal, mathematical model for const, as it applies to imperative languages, with an exhaustive examination of the various use cases (assignment, reference, duplication, etc.) would be nice.I don't know about the need of a PhD, but a model of immutability is likely going to be closely tied with whole language design. The difficulty remains in integrating const as an afterwords in D. Other new languages may more accurately turn this very issue into a mathematical model by developing the whole language with const (or some other mode) as a basic premise. For example, erlang did this with concurrency, Smalltalk with Objects, Common Lisp with lists, etc. D doesn't have that advantage; and, thus, the difficulty of fixing this perfectly will likely remain mostly elusive. Plugging const into D is like tacking graphs together with multiple disconinuities amongst each. Like it or not, D is somewhat stuck with the "kludge" model because of it's design decision to be flexible, as well a it's carryover from C/C++ ideology. The hope remains that most of these kludges can remain pseudo-consistent, simple, and attractive. (Not all of D is a kludge. I'm just saying that some areas have had to be reworked to accommodate ideas that were not originally predicted, which is completely understandable for any invention).Maybe it's time to stop spinning our wheels here and start making progress on other things.I really don't know... I wouldn't say that wheels have been exactly spinning. I'd like to remain somewhat optimistic and think that there have been two steps forward and one step back. It's yet unclear, though. At any rate, I doubt people will stop just because it's been suggested to stop. That's been tried before and tends to fail miserably. :D -JJR
Jan 02 2008
John Reimer wrote:Heh. I agree on both points. I made a passing reference to this in my original post, but I wanted to amplify it: D's const is a *huge* step forward from C++'s. In particular, my whole view of const changed significantly when I finally grok'ed the difference between "const" and "invariant". I was simply observing that we continue to struggle to reach the "perfect", "correct", and "understandable" const. You may be right, that it will be impossible to do so in D, but I continue to hope that some very smart person will put it all together, someday. :) As for the practical statement that const isn't going away, you're probably right. That's why I keep contributing to the discussions about it. :)Maybe it's time to stop spinning our wheels here and start making progress on other things.I really don't know... I wouldn't say that wheels have been exactly spinning. I'd like to remain somewhat optimistic and think that there have been two steps forward and one step back. It's yet unclear, though. At any rate, I doubt people will stop just because it's been suggested to stop. That's been tried before and tends to fail miserably. :D
Jan 02 2008
Russell Lewis wrote:I made a passing reference to this in my original post, but I wanted to amplify it: D's const is a *huge* step forward from C++'s.I agree. And I've learned a hell of a lot in the process of working on this design. It may even become a killer feature!
Jan 02 2008
Walter Bright wrote:Russell Lewis wrote:Any plans for papers on it?I made a passing reference to this in my original post, but I wanted to amplify it: D's const is a *huge* step forward from C++'s.I agree. And I've learned a hell of a lot in the process of working on this design. It may even become a killer feature!
Jan 03 2008
Don Clugston wrote:Walter Bright wrote:The popular topics for papers are systems, algorithms, and experimental stuff like AI. Under systems, it's networking, compilers, filesystems, some other OS stuff like that. A paper about ensuring const-correctness efficiently in a language that allows pointers might make it through. A paper about a good design for const? I doubt it, unless you're familiar with journals that I'm not.Russell Lewis wrote:Any plans for papers on it?I made a passing reference to this in my original post, but I wanted to amplify it: D's const is a *huge* step forward from C++'s.I agree. And I've learned a hell of a lot in the process of working on this design. It may even become a killer feature!
Jan 03 2008
On Thu, 03 Jan 2008 13:28:21 -0000, Christopher Wright <dhasenan gmail.com> wrote:Don Clugston wrote:You'd be surprised. I remember reading an interesting paper about the properties of pointers which contained a proof that labelling pointers as owned and unowned made it possible to automate detection and absence of memory leaks. Papers on constancy fill a similar niche.Walter Bright wrote:The popular topics for papers are systems, algorithms, and experimental stuff like AI. Under systems, it's networking, compilers, filesystems, some other OS stuff like that. A paper about ensuring const-correctness efficiently in a language that allows pointers might make it through. A paper about a good design for const? I doubt it, unless you're familiar with journals that I'm not.Russell Lewis wrote:Any plans for papers on it?I made a passing reference to this in my original post, but I wanted to amplify it: D's const is a *huge* step forward from C++'s.I agree. And I've learned a hell of a lot in the process of working on this design. It may even become a killer feature!
Jan 03 2008
Don Clugston wrote:Walter Bright wrote:Andrei thinks we've broken new ground with it, and a paper is in order.Russell Lewis wrote:Any plans for papers on it?I made a passing reference to this in my original post, but I wanted to amplify it: D's const is a *huge* step forward from C++'s.I agree. And I've learned a hell of a lot in the process of working on this design. It may even become a killer feature!
Jan 05 2008
John Reimer escribió:Russell Lewis wrote:This one...Originally, Walter argued that we didn't need const in D because it was confusing and didn't solve the optimization problems that it was intended to solve. But then people made very good arguments about why we need const. So Walter brought const into the language, but with better semantics (than C++). Problem was, it was confusing to many people, and it didn't solve all the problems that it was intended to solve. Sound familiar? Now we've gone through additional iterations (how many so far?) and we still don't have it working quite right. IMHO, this is the time to recognize the *empirical* fact that as yet neither do we understand the full requirements of what const should be trying to do nor do we have an easily-understandable way to implement it. I don't think that this is a problem with the current design; it is a problem with our theoretical grasp of the space.It's actually a problem of molding an idea to fit a language that has already been mostly specified.... and this one are very good points, IMHO.Walter, I'm not attacking you, truly. I hold you in the highest regard, and you have worked very hard for a very long time on const, and on D in general. But const isn't working. My guess is that we need the PhD's to write more papers on the theory of const before us mere mortals will be able to use it in our practical languages. A formal, mathematical model for const, as it applies to imperative languages, with an exhaustive examination of the various use cases (assignment, reference, duplication, etc.) would be nice.I don't know about the need of a PhD, but a model of immutability is likely going to be closely tied with whole language design. The difficulty remains in integrating const as an afterwords in D. Other new languages may more accurately turn this very issue into a mathematical model by developing the whole language with const (or some other mode) as a basic premise. For example, erlang did this with concurrency, Smalltalk with Objects, Common Lisp with lists, etc. D doesn't have that advantage; and, thus, the difficulty of fixing this perfectly will likely remain mostly elusive. Plugging const into D is like tacking graphs together with multiple disconinuities amongst each. Like it or not, D is somewhat stuck with the "kludge" model because of it's design decision to be flexible, as well a it's carryover from C/C++ ideology. The hope remains that most of these kludges can remain pseudo-consistent, simple, and attractive. (Not all of D is a kludge. I'm just saying that some areas have had to be reworked to accommodate ideas that were not originally predicted, which is completely understandable for any invention).-- Carlos Santander BernalMaybe it's time to stop spinning our wheels here and start making progress on other things.I really don't know... I wouldn't say that wheels have been exactly spinning. I'd like to remain somewhat optimistic and think that there have been two steps forward and one step back. It's yet unclear, though. At any rate, I doubt people will stop just because it's been suggested to stop. That's been tried before and tends to fail miserably. :D -JJR
Jan 02 2008
Russell Lewis wrote:[...] Maybe it's time to stop spinning our wheels here and start making progress on other things.Well I just hope the const fans are more or less satisfied (I'm sure full satisfaction all round is impossible) with Walters new const concept. There would be no call of deferring it then, and also no need for further lengthy discussions about the details... I'd like to see the const topic migrate from D to D.learn =) regards, frank
Jan 02 2008
Russell Lewis wrote:Maybe it's time to stop spinning our wheels here and start making progress on other things.Personally, I think the current design feels pretty good. It doesn't have rays of divine light shining from it like I hoped, but it's far better than C++ const in terms of understandability and utility. I think it says something that my complaints about it have been reduced to the use of 'invariant' as a keyword rather than anything substantial. Also, I do agree with Walter that if const is added it D it must be done sooner rather than later. Despite the comments to the effect that if you don't like const you don't have to use it, it really does break a lot of code, and the longer D is around the more difficult it will be to justify a significant breaking change. Sean
Jan 03 2008
Sean Kelly wrote:Russell Lewis wrote:I agree, but the thing that concerns me is that I suspect that the reverse is also true: const, once in the language in some form, will be *very* hard to change. I'm concerned that we will permanently enshrine some sort of const into the language because it's the best one we have so far, and then a few years later we will bemoan the fact that the newer, better, "right" const just can't be retrofitted into the language. But, of course, that is all speculation. You can't hold off forever...Maybe it's time to stop spinning our wheels here and start making progress on other things.Personally, I think the current design feels pretty good. It doesn't have rays of divine light shining from it like I hoped, but it's far better than C++ const in terms of understandability and utility. I think it says something that my complaints about it have been reduced to the use of 'invariant' as a keyword rather than anything substantial. Also, I do agree with Walter that if const is added it D it must be done sooner rather than later. Despite the comments to the effect that if you don't like const you don't have to use it, it really does break a lot of code, and the longer D is around the more difficult it will be to justify a significant breaking change.
Jan 03 2008
On Thu, 03 Jan 2008 17:08:26 -0000, Russell Lewis <webmaster villagersonline.com> wrote:Sean Kelly wrote:It depends on the language (designer) and the community. Larry Wall seems unafraid and perhaps even keen on breaking changes (Perl apocolypses - http://dev.perl.org/perl6/doc/apocalypse.html).Russell Lewis wrote:I agree, but the thing that concerns me is that I suspect that the reverse is also true: const, once in the language in some form, will be *very* hard to change. I'm concerned that we will permanently enshrine some sort of const into the language because it's the best one we have so far, and then a few years later we will bemoan the fact that the newer, better, "right" const just can't be retrofitted into the language. But, of course, that is all speculation. You can't hold off forever...Maybe it's time to stop spinning our wheels here and start making progress on other things.Personally, I think the current design feels pretty good. It doesn't have rays of divine light shining from it like I hoped, but it's far better than C++ const in terms of understandability and utility. I think it says something that my complaints about it have been reduced to the use of 'invariant' as a keyword rather than anything substantial. Also, I do agree with Walter that if const is added it D it must be done sooner rather than later. Despite the comments to the effect that if you don't like const you don't have to use it, it really does break a lot of code, and the longer D is around the more difficult it will be to justify a significant breaking change.
Jan 03 2008
Bruce Adams:Larry Wall seems unafraid and perhaps even keen on breaking changesThat's just one of the many things that makes me (happily) use Python instead... ;o) Bye, bearophile
Jan 03 2008
On Fri, 04 Jan 2008 01:30:41 -0000, bearophile <bearophileHUGS lycos.com> wrote:Bruce Adams:Disclaimer: I am not a serious Perl user. Its just a language built on top of sed and awk thats not a good basis. C++ is a much better one (for D). Still python has its own pitfuls. How many versions of popen do you need to get it right? There are currently popen popen2 popen3 & popen4 and none of these includes code to workaround Windows not being Posix. When something is broken a breaking change is sometimes required. I detest having to support old broken ways of doing things but accept that its an occasional necessity.Larry Wall seems unafraid and perhaps even keen on breaking changesThat's just one of the many things that makes me (happily) use Python instead... ;o) Bye, bearophile
Jan 04 2008
Bruce Adams:Still python has its own pitfuls.Python has its warts, but they are small/tiny compared to C/C++/D/Java/Perl ones, and with Python 3.0 lot (but not all) of them will be removed.How many versions of popen do you need to get it right?From Python 2.4 we have the subprocess module in the std lib: http://docs.python.org/lib/module-subprocess.htmlWhen something is broken a breaking change is sometimes required. I detest having to support old broken ways of doing things but accept that its an occasional necessity.Take a look at Python 3.0a2: http://www.python.org/download/releases/3.0/ Bye, bearophile
Jan 04 2008
On Fri, 04 Jan 2008 12:01:45 -0000, bearophile <bearophileHUGS lycos.com==wrote:Bruce Adams:Still python has its own pitfuls.Python has its warts, but they are small/tiny compared to =C/C++/D/Java/Perl ones, and with Python 3.0 lot (but not all) of them ==will be removed.Its all swings and roundabouts.I've had deadlock problems with this on windows. Perhaps you can help me out ;) http://python-forum.org/pythonforum/viewtopic.php?f=3D15&t=3D6818&start=3D= 0&st=3D0&sk=3Dt&sd=3Da&sid=3D774583b62dc861dd3fb90b3d1544d288 The old versions are still there (for now) and the way the documentation= = is organised is confusing. I have to do a separate search to get API once I find = something in the manual.How many versions of popen do you need to get it right?From Python 2.4 we have the subprocess module in the std lib: http://docs.python.org/lib/module-subprocess.htmlWhen something is broken a breaking change is sometimes required. I detest having to support old broken ways of doing things but accept=That a nice bundle of changes. I'm looking forward to it. I can't help being reminded of TCL. It went through a similar phase with= = strings going unicode and byte arrays for binary data.that its an occasional necessity.Take a look at Python 3.0a2: http://www.python.org/download/releases/3.0/
Jan 04 2008