More keywords? Or fewer?

[Jesse Phillips]

On Thu, 01 May 2008 13:13:11 -0700, Davidson Corry wrote:

> Bruce Adams wrote:
>> I agree with pretty much everything you've said. However, I'm not clear
>> what point you're trying to make.
> 
> I often feel that way myself. <grin>
> 
> My point was that the language system ought to manage constness,
> invariance, synchronization on objects shared by multiple threads or
> processes, and so on, AUTOMATICALLY without requiring the programmer to
> manage those things explicitly (via keywords or whatever else), just as
> GC-enabled language systems now automatically manage memory allocation
> without requiring the programmer to use keywords etc. to do memory
> allocation explicitly.
> 
> And my counterpoint was to suggest that, if the language system DOES
> provide keywords/properties/libraries by which const etc. CAN be managed
> explicitly if desired (but not required), then those tools should be an
> orthogonal doublecheck on the language's automatic inference of how
> const etc. is to be managed, just as design by contract is a doublecheck
> on the "contract" implied by a program's actual behavior.
> 
> -- Dai

If I understand your request correctly, the reasons for const... is to 
allow the programmer to define the rules for his variables, not because 
the compiler can't see when a variable doesn't change.

The short, the compiler gets to enforce const and invariant on the 
programmer.

That is to say the compiler could take written code and identify what is 
invariant and const, but if someone else extends this those won't be 
marked in that way because they have changed it. How is the compiler 
going to say, "don't change that." If it has to guess from usage?