const

[Benji Smith]

Walter Bright wrote:
> Benji Smith wrote:
>> There's nothing special about a value not changing (at least, not for 
>> function arguments), so programmers should't be burdened with 
>> annotating the mundane case. Mutability of function arguments is much 
>> more interesting.
>>
>> Labeling function arguments as mutable would, in my opinion, provide a 
>> *stronger* const regime, while simultaneously producing less pointless 
>> code clutter.
> 
> As this has come up before, I added it to const(FAQ):
> 
> http://www.digitalmars.com/d/2.0/const-faq.html#const-parameters

Cool. Thanks!

In the FAQ, you said "This kind of inconsistency leads to all sorts of 
mistakes."

I'd like to point out that we don't really know if it causes mistakes, 
because no one has ever tried it.

At least they'd be the kind of mistakes that the compiler could catch.

"Error: can't modify the value of a non-mutable argument, on line 235"

With the current implementation, if a programmer forgets to annotate an 
argument as const, the compiler can't correct the error.

The FAQ also says "It would be a huge break from past D practice, and 
practice in C, C++, Jave, C#, etc."

But isn't the same thing true of transitive const? You yourself said 
that no other language has ever implemented transitive const. So it's a 
huge break from the past for all of us. It takes some brain-readjustment 
to understand the mechanics of it, let alone the implications for 
designing an API.

(BTW, none of my comments so far have been about const transitivity, 
because I don't understand it well enough to form an opinion.)

...hmmmmmm... browsing through the rest of the FAQ...

I'm particularly interested in your "logical const" example, because it 
demonstrates a memoization idiom that I use all over the place in my 
everyday coding.

For example, I do a lot of work with vector-space representations of 
data, and I have a bunch of classes for modeling vector spaces and 
vectors within those spaces.

Each vector usually represents some sort of document, and the magnitude 
in each dimension usually represents the term frequency (or, more 
generically, a weight for whatever feature is modeled by the given 
dimension). It's not uncommon for an individual vector to have hundreds 
or thousands of dimensions.

In one of my projects, the full vector space had more than half a 
million distinct dimensions, and the biggest vectors each projected into 
ten or fifteen thousand of those dimensions.

With such a model, you can calculate the "information weight" of a 
vector by taking its magnitude. Or you can calculate similarities 
between two documents by taking the cosine of their vectors.

Vector cosine is calculated by dividing the vectors' dot products by the 
  product of the vector magnitudes. And, since I often need to calculate 
thousands of these vector cosines (to find a pair of documents with high 
similarity), each vector object lazily calculates (and then memoizes) 
its magnitude.

I can't remember the exact results, but when I implemented magnitude 
memoization, my algorithms sped up by at least an order of magnitude.

On the one hand, the vector itself (once constructed) is const, becuase 
I never add, remove, or alter the value of any dimension. But if a 
vector's magnitude is never requested (either directly or through a 
cosine calculation), then the magnitude is never calculated.

I'd be sunk without the availability of that kind of functionality. I 
use it all over the place. (Especially for calculating object hash codes 
(the majority of my code is in Java and C#)).

I suppose in D, I'd have to avoid declaring vectors as const. Which 
would be a shame, because the basic data in the structure is never 
modified after construction. The only thing that *ever* changes is those 
values that are lazily evaluated and then memoized.

Hope that info is helpful. (Or at least mildly entertaining!)

--benji smith