www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Perhaps we need to defer const for a while (3.0?)

reply Russell Lewis <webmaster villagersonline.com> writes:
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
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
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
parent Russell Lewis <webmaster villagersonline.com> writes:
Janice Caron wrote:
 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.

! 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. :)
Jan 02 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
parent reply Carlos Santander <csantander619 gmail.com> writes:
Jarrett Billingsley escribió:
 "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.).

Same here.
 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
parent reply 0ffh <frank youknow.what.todo.interNETz> writes:
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
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
0ffh wrote:
 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

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). --bb
Jan 03 2008
prev sibling next sibling parent reply John Reimer <terminal.node gmail.com> writes:
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
next sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
John Reimer wrote:
 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

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. :)
Jan 02 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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
parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 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!

Any plans for papers on it?
Jan 03 2008
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Don Clugston wrote:
 Walter Bright wrote:
 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!

Any plans for papers on it?

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.
Jan 03 2008
parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Thu, 03 Jan 2008 13:28:21 -0000, Christopher Wright  
<dhasenan gmail.com> wrote:

 Don Clugston wrote:
 Walter Bright wrote:
 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!


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.

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.
Jan 03 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don Clugston wrote:
 Walter Bright wrote:
 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!

Any plans for papers on it?

Andrei thinks we've broken new ground with it, and a paper is in order.
Jan 05 2008
prev sibling parent Carlos Santander <csantander619 gmail.com> writes:
John Reimer escribió:
 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.

This one...
 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).

... and this one are very good points, IMHO.
 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

-- Carlos Santander Bernal
Jan 02 2008
prev sibling next sibling parent 0ffh <frank youknow.what.todo.interNETz> writes:
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
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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
parent reply Russell Lewis <webmaster villagersonline.com> writes:
Sean Kelly wrote:
 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.

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...
Jan 03 2008
parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Thu, 03 Jan 2008 17:08:26 -0000, Russell Lewis  
<webmaster villagersonline.com> wrote:

 Sean Kelly wrote:
 Russell Lewis wrote:
 Maybe it's time to stop spinning our wheels here and start making  
 progress on other things.

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.

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...

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).
Jan 03 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bruce Adams:
 Larry Wall seems unafraid and perhaps even keen on breaking changes

That's just one of the many things that makes me (happily) use Python instead... ;o) Bye, bearophile
Jan 03 2008
parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Fri, 04 Jan 2008 01:30:41 -0000, bearophile <bearophileHUGS lycos.com>  
wrote:

 Bruce Adams:
 Larry Wall seems unafraid and perhaps even keen on breaking changes

That's just one of the many things that makes me (happily) use Python instead... ;o) Bye, bearophile

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.
Jan 04 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
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.html
 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.

Take a look at Python 3.0a2: http://www.python.org/download/releases/3.0/ Bye, bearophile
Jan 04 2008
parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
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.

 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.html

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.
 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.

Take a look at Python 3.0a2: http://www.python.org/download/releases/3.0/

I can't help being reminded of TCL. It went through a similar phase with= = strings going unicode and byte arrays for binary data.
Jan 04 2008