I have been thinking some more about how to improve ucf. One of the things that struck me was that there are only five actions that ucf can take, and the decision about the actions depends on the state it finds the configuration file in on the target machine, and there are only eight of those. Now, thinking back to my days as a VLSI designer back in the halcyon days of electrical engineering, This is a pretty simple state machine. It is not as neat as it could be (where just three variables would be needed to keep track of things, but still, it bears investigation. This would be a way for converting the current procedural ucf into a functional programming model.
So. Here are the boolean variables that I check to see what state the configuration file is in:
We also use an optimization, in the case where the destination file is already the same as the new file – but this is only an optimization, and probably not worth the cost of determining whether or not the file is the same. But, in case we care:
Now, there are some flags that affect the behavior – and the values can be one of three flags set, or none. That means there are four possible cases, and these can be represented by just two booleans:
Now this becomes an exercise in logic minimization.
The cases that I talked about in the previous blog posting can be expressed in terms of these variables:
So, looking at the table at the bottom of the posting, we can see that the four actions can be expressed as:
If we ignore the optimization of looking to see if the destination is the same as the new file when we are replacing the configuration file, we can get:
This should not be hard to code – assuming, of course,I have not made a mistake above.
Date: <2009-03-01 Sun>
HTML generated by org-mode 6.21b in emacs 23