Perhaps we need to defer const for a while (3.0?)

Carlos Santander csantander619 at gmail.com
Wed Jan 2 19:43:16 PST 2008


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



More information about the Digitalmars-d mailing list