Sneaky Internal State

I've boiled what I want out of a programming language down to a single example.  Problems like this bite me in the ass often and I haven't used a language, yet, that helps.

Suppose I'm writing a library for working with vectors.  For simplicity, it's not fancy n-dimensional vectors, etc., let's say just three floats.  So I write some code to perform operations on vectors, like add, subtract, dot product, cross product, rotate, scale... and then I come to "normalize."

Here, I come up with this optimization that vectors could also store a flag indicating whether or not they are normal.  If that flag is set, then normalize has no work to do.  The catch is that I have to decide which operations clear the flag, which operations set it, and which operations leave it unchanged.  So I do the work and end up with a nice, efficient vector library.

I use my library for a long time -- long enough that I stop caring how that optimization worked.  Eventually, months later, I decide to add some new functions to my vector library.  Of course, I've forgotten all about the "normal" flag, and I forget to set/clear it in the new functions.  Of course, there's no compile error or even a run-time error.  I just observe strange behavior when the application runs and I have to spend hours stepping through floating-point math to figure out what's wrong.

How does your language of choice improve this situation?

>>25
It's not really that difficult. It is just a matter of having a formal system of preconditions and post conditions that the compiler can be aware of. Tools for static code analysis do this to help identify bugs. There's no reason why it couldn't also be used for optimizations. OP wants to be able to do vector math and get the benefit of not having to redundantly normalize vectors, without having to be smart enough to just fucking know when a vector is normalized, and call the fucking appropriate functions that take parameters that are assumed to already be normalized. So I suggested what would be needed for a compiler to make these optimizations for the programmer. If the programmer isn't smart enough to avoid redundant calls to the normalize method, then maybe the compiler can be.

>>24
What I'm saying is that intelligently written code doesn't need to check if it is normalized or not. It can be proven to be normalized, and then handled as such. The compiler can generate code that correctly handles inputs that are assumed to be normalized. Yes, the compiler can be deleted. That doesn't matter. It generated code which then runs at run time, and processes the vectors as efficiently as possible.

>>27
If you are writing code that consistently normalizes the same vector a few dozen times, you are a fucking moron that has no business with programming. If you are writing code that consistently checks to see if a vector is normalized a few dozen times, you are still a fucking moron that has no business with programming. If you normalize the vector once, and then use that normalized vector in a context that makes sense for normalized vectors, a few, dozen times, then you are doing only what is necessary.