Factor Constancy

One person's constant is another person's variable., attributed to Susan Gerhart in 'More Programming Pearls' Jon Bentley ISBN 0-201-11889-0 .

Where a program has a large table of constant values, consider whether any design decisions prevent the table being updated at run time - and consider reversing these decisions.

Advantages

Greater program flexibility. Possible shorter turn around time in testing changes to the constants, making getting the constants right easier.

But ... if what were constants are now mutable at run-time, how can you ever test changes to them? unless you add some user interface or a way to load the 'constants' from a file? you still can't test all the possible values

The user might change them to something disastrous! Some constants really are constants - PI for instance. But some only appear to be constants, e.g. the color of light (white?) used to illuminate an object in a 3D program, a table of costs of materials.... Yes, *some*. The summary above originally implied *all* constants should be made non-const

And much code might implicitly assume a constant value - working code can break when a constant is changed. This is probably a bug, but is a bug that can never occur a bug? When you allow constants to vary, the bug can rear its head. Non-constant constants feels like "CreepingFeaturitis" to me.

Things to consider

May be able to steal/adapt code from elsewhere for loading/saving the 'constants'.

The future

For JIT compilers, constancy could be an attribute of a variable i.e. it could vary. This would permit smarter optmizations.

Q: How does this permit smarter optimizations?

A: MyAge is input by the user from a dialog. You now execute:

  if( MyAge <= Threshold )
     DoSomething()

Inside a loop. If MyAge is > Threshold, and both are known to be constant, this code and the test will be completely optimized away. A normal optimizing compiler does quite a bit of analysis to deduce this optimization, and fails to do it in more complex situations. If it KNEW that these were constants, it could do the optimization easily. OK, you could tell it they were constants by using the 'const' modifiers in a function prototype, BUT you are then limited to one choice of what is const by the function declaration.

Q: Marking variables const/non-const on-the-fly seems excessive. The ramifications of this are appalling - all the code which references that variable must be recompiled. In a JIT environment this can be justified, but what if I don't want to spend X% of my CPU maintaining the JIT compiler?

A: Switching constancy on or off is a way to inform the JIT compiler of optimizations it can or can't do. Outside a JIT environment the normal way to deal with a regular expression input at run time is to run a custom compiler on it at run time. This is an alternative to telling a JIT compiler/interpreter that the reg expression string is now to be treated as a constant and then calling 'match()'. If you don't want the overhead of compiling, you wont be able to run the query efficiently! The custom compiler approach is an OK solution but it's a special case solution. Similar compiling-at-run-time is done in some games programs for bltblatting bitmaps; again a custom compiler generates specific code (on the stack) to cope with the specific format / bltblat mode being used.

R: Sure, you can optimize given things are const, but FactorConstancy says the opposite - it says "make all consts non-const". i.e. FactorConstancy removes optimizations. [Do I have the right end of the stick here?]

Shouldn't FactorConstancy instead say something like 'try and factor out your constancy decisions so that you can change your mind about whether something is a constant easily'? Doing so at run time is then an extreme case... --JamesCrook

What you seem to want is to be able to load constants at run time, and have them dealt with from that point on as efficiently as if they had been compiled in. Is that right?

FactorFinding TopicRefactoring?