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