Wish: Variable Not Used Warning

[Nick Sabalausky]

"Manfred_Nowak" <svv1999 at hotmail.com> wrote in message 
news:g51vnt$1o9n$1 at digitalmars.com...
> Nick Sabalausky wrote:
>
>> turned out to be variables I had intended to use but forgot to
>
> I am trying to tackle such time wastings with "protocols" in drokue. If
> one would be able to formally attach ones intentions to variables then
> such bugs could possibly be prevented.
>
> In your case the intention might have been to write and read the
> variable several times, of course starting with a write followed by
> some read. This intention can be expressed by a regular expression
> like:
>
>   write+ read ( write | read )*
>
> For evaluating this at runtime (!) one may attach a DFA to the
> variable---a DFA that interpretes the operations on the variable as
> input. Of course the DFA has to be initiated somewhere before the first
> operation on the variable. At program termination the DFA can than be
> checked, whether it is in a final state.
>
> If at program termination the DFA is not in a final state then an
> "intention violation"-error can be reported. This way your time
> wouldn't have been wasted.
>

I've been seeing alot in these last few years about such...I'm going to call 
it "intent oriented programming".

There's a lot of good stuff that works that way (unit testing and D's 
function contracts, for instance. I've seen some other new things from the 
Java world as well), and your idea is certainly interesting.

But I worry that eventually we'll get to some point where all code either is 
or can be generated straight from "intents" syntax. Now that certainly 
sounds great, but at that point all we really would have done is reinvent 
"programming language" and we'd be left with the same problem we have today: 
how can we be sure that the "code"/"intents" that we wrote are really what 
we intended to write? The solution would have just recreated the problem.

Regarding your specific idea, my concern with that is that the whole "write 
and read the variable several times, starting with a write followed by some 
read" is tied too closely to the actual implementation. Change your 
algorithm/approach, and you gotta go update your intents. I'd feel like I'd 
gone right back to header files.

> Please note, that such cannot be done by a lint tool.

True, since lint tools only do front-end work. But the compiler would be 
able to do it by injecting appropriate code into its output. An external 
lint tool *could* be made to do it by using ultra-fancy CTFE, but then the 
ultra-fancy-CTFE engine would effectively be a VM (or, heck, even real 
native code), which would mean adding a backend to the lint tool which would 
basically turn it into a compiler. Thus, in a manner of speaking, there 
would be correctness-analysis that a compiler could do that a lint tool (by 
a definition of "lint tool" that would have admittedly become rather 
debatable by that point) couldn't. ;)