D const design rationale

[Don Clugston]

Walter Bright wrote:
> Sean Kelly wrote:
>> However, my point was that to a programmer, optimization should be 
>> invisible.
> 
> I can't agree with that. The compiler and the programmer need to 
> cooperate with each other in order to produce fast programms. If a 
> programmer just throws the completed program "over the wall" to the 
> optimizer and expects good results, he'll be sadly disappointed.
> 
> 
>> I can appreciate that 'invariant' may be of tremendous use to the 
>> compiler, but I balk at the notion of adding language features that 
>> seem largely intended as compiler "hints."
> 
> It's a lot more than that. First, there's the self-documenting aspect of 
> it. Second, it opens the way for functional programming, which can be of 
> huge importance.
> 
> 
>> Rather, it would be preferable if the language were structured in such 
>> a way as to make such hints unnecessary.
> 
> That would be preferable, but experience with such languages is that 
> they are complete failures at producing fast code. Fast code comes from 
> a language that enables the programmer to work with the optimizer to 
> produce better code.
> 
> Lots of people think that just 'cuz they write in C++, which has good 
> optimizers available, they'll get fast code. That's not even close to 
> being true.
> 
> 
>> To that end, and speaking as someone who isn't primarily involved in 
>> numerics programming, my impression of FORTRAN is that the language is 
>> syntactically suited to numerics programming, while C++ is not.  Even 
>> if C++ performed on par with FORTRAN for similar work (and Bjarne 
>> suggested last year that it could), I would likely still choose 
>> FORTRAN over C++ because the syntax seems so much more appealing for 
>> that kind of work.
> 
> I programmed for years in FORTRAN. The syntax is not appealing, in fact, 
> it sucks. The reason it is suited for numerics programming is because 
> FORTRAN arrays, by definition, cannot be aliased. This means that 
> optimizers can go to town parallelizing array operations, which is a 
> big, big deal for speed.
> 
> You can't do that with C/C++ because arrays can be aliased. I have a 
> stack of papers 6" deep in the basement on trying to make C more 
> suitable for numerics, and it's mostly about, you guessed it, fixing the 
> alias problem. They failed.

How much of this will actually be solved by invariant?
It seems to me that typically, arrays are built up element-by-element, even if 
they never change again. I guess in D2.0, such code would initialize a temporary 
array, and finally idup it?

The aliasing problem will be far from gone, though. Consider an in-place 
operation on a matrix. Frequently you modify one only row at a time, based on 
the remaining rows. I think you'd have to cast(invariant) those other rows, to 
avoid aliasing.

> There are some template libraries for C++ which parallelize array 
> operations and can finally approach FORTRAN. But they are horrifically 
> kludgy and complicated. No thanks. But the effort that has gone into 
> them is astonishing, and is indicative of how severe the problem is.

Actually in C++ I think there's a problem with operator overloading, not just a 
problem with const. Op overloads destroy far too much valuable information. I'll 
discuss that a bit in my conference presentation.

Interesting thing is, with poor-man's-macros (mixin + ctfe), you can detect a 
great many cases of aliasing (since two static arrays are guaranteed not to 
alias each other). And you can also assert that there's no overlap between 
arrays, then generate code assuming no aliasing. Invariant would move that to a 
compile-time check, but if you had array operations built-in, I'm not sure how 
much extra benefit it would give (D can do a *much* better job than C++ already).