More keywords? Or fewer?

[Davidson Corry]

>> Davidson Corry wrote:
>>
>> If the kind of whole-system inference I am suggesting is possible
>> (and I don't know whether or not it is), then a programmer /wouldn't
>> have to/ use keywords to declare explicit contracts for constness,
>> exception safety, multiprogramming etc. The compiler would just
>> figure out what was needed and optimize for it.
>> 

> Me Here wrote:
> 
> Haskell attempts this. And does a pretty good job of it too. But at
> what cost?
> 
> [ ... discussions of Haskell inefficiencies deleted ... ]
> 
> Before you get caught up in the hype of purity and the promises of
> lock-free, transparent multi-processing, ask to see a real world
> example of processing large amounts of data. It either doesn't exist;
> runs very slowly; or reverts to procedural techniques and
> non-referentially transparent data storage to achieve efficiency. And
> in the process forces the use of clumsy and inelegant syntax to do it.
> 
> There is a lesson to be learnt here. And it goes right back to the
> original mission statement for D's design philosophy. In a word:
> pragmatism.

> Walter Bright wrote:
>
> ...The idea in D is that when your program needs to switch gears, it can
> do so while remaining in the same language, and without horrible
> kludges. This means that D will support functional, procedural, safe,
> unsafe, OOP, imperative, metaprogramming, etc., styles fairly
> seamlessly under one umbrella....
> I don't know of a language that merges functional with procedural. 
> D is certainly going to give it a try.

Well, and you make me think. 

What I had suggested was that the compiler might do whole-system analysis 
of the code, infer from that a contract for constness, synchronization etc., 
and then double-check that behavior against the other contract explicitly 
declared by the programmer. Perhaps we can turn that on its head: have an 
analysis system, maybe running in a background thread of a smart editor while 
you are actually keying in the program, analyze your code and suggest "this 
looks like it's const, and that function appears to be nothrow, and if you're 
targeting a multi-threaded platform you will probably want to synchronize 
this section of code here -- would you like me to add those annotations? 
Oh, and by the way, this new interface you're creating today has become conflicted 
with the contract of that other module you linked to it yesterday." It doesn't 
have to be part of the compiler.

I am no fan of ivory-tower abstractions, particularly not at the cost of 
performance. I will happily mix paradigms to get the job done. (Heck, I love 
Perl. Q.E.D.)

I just want the computer to do the grunt work for me.

-- Dai