The rotation command seems like overkill. In the first place, with several operators (single-arguement operators, multiplication, and addition) it is meaningless. In the second place, I really don't expect people to use it much with with functions or arrays. The only two places where it will be used will be subtraction and division. This suggests that rotation is a rare event.
I am more concerned with the overall clumsiness of the system. If you're looking at an equation, and it needs editing, what's the fastest way to get to what you want? What's the clearest way? Am I running into a fundamental cost of using a point-and-click editor?
If the editor is too tree-like in operation, then you could waste a lot of time walking down a tree, realizing that it's incorrect, then backtracking and rummaging around for the right path. That's stupid.
Here's a bold thought: what if we require the user to think in RPN? What if a program is entered in straight RPN? It seems that all of our problems have arisen from trying to bring infix notation into conformance with RPN. But what if we just dictate RPN? Is it really that hard to learn? Wouldn't it be so much easier to use in the long run? Is RPN difficult to evaluate by examination? Could we make it easier to digest with a display system that shows the hierarchy of operations?
Example:
(Affection + Dominance)/(Empathy - Volatility)
This translates to
PushAffection, PushDominace, Add, PushEmpathy, PushVolatility, Subtract, Divide.
Now if we write this as:
((PushAffection, PushDominace, Add), (PushEmpathy, PushVolatility, Subtract), Divide)
is it as easy to read? It would certainly be easier to edit, wouldn't it?
OK, so we've boiled it down to two choices: infix with rotation, and RPN with parentheses. Let's take one more stab at refining each of these two schemes and see which one emerges as the winner.
The Infix Scheme
This system is essentially the same as what we have now, with the following changes:
1. If the user holds down the Shift key, the cursor changes into a pair of brackets to indicate that he is in "Insidify" mode rather than the conventional replacement mode. If he then selects an operator, the operator will be placed outside of the selected operator, enclosing the selected operator within it in the position of first arguement. Any other arguements to the selected operator will be filled in with Unspecified values. The newly selected operator becomes the current selection.
2. If this newly selected operator is subtraction, division, or an array or function with more than one arguement, then the "Rotate" button will be enabled.
3. If the Rotate button is pressed, then the order of arguements for the selected operator is rotated.
4. Whenever a new selection is made, the Rotate button is enabled or disabled based on the nature of the selected operator.
5. If the user presses the "Delete" onscreen button, the selected operator and all its arguements are deleted.
6. The Delete button is enabled for all specified operators, but disabled for Unspecified operators.
RPN Editing
This option requires redesign of the existing system. The screen display would be an organized version of the S-code string. We would pretty-print the S-codes with indentation to indicate subordination. This has one advantage over the conventional display: if the conventional equation is too long and the line wraps, the line break can come at a confusing point. With a vertical column of S-codes, there is never an issue with line breaks. I suppose that we could get into some problems with excessive indentation, but that strikes me as a remote possibility.
Editing in this arrangement would be simple. The user selects a line item, and deletes it directly (along with all its arguements) or inserts something below it. All insertions are always below line items, because you can't insert something inside an arguement list. Remember, whenever we insert an operator, we automatically insert its arguements as Unspecified, so that the arguement count is always preserved.
But what does it mean to insert a line item? How can we prevent the user from screwing up the stack? Anything the user inserts must be stack-neutral. That is, it must not alter the stack depth of the subsequent S-codes. For example, suppose that the user is looking at a term and has decided that this term should be divided by two. The desired change in the S-code string will be to insert "Push #2" and "Divide" immediately after the term in question. But the actual editing sequence would be to insert the "Divide" operator, which would then automatically insert an Unspecified code, and then replace the Unspecified code with a #2. This would be particularly clumsy if the user had to rotate the result.
Let's do a comparitive example. Each of the following two cases uses the same formula. We desire to amend the formula by dividing Volatility by 2.
Infix Editing:
(Affection[ThisSubject, ThisDirObject] + 27) / (Volatility - Empathy)
To edit this expression, we select the Volatility term, hold down the Shift key, and select "divide". This replaces Volatility with (Volatility / Unspecified). We then select the Unspecified term and replace it with #2. The result looks like this:
(Affection[ThisSubject, ThisDirObject] + 27) / ((Volatility / 2) - Empathy)
RPN Editing:
Push #27
Push ThisDirObject
Push ThisSubject
Push Affection
+
Push Volatility
Push Empathy
-
/
To edit this expression, we select the Push Volatility term and then select "divide" (no Shift key). This inserts Push Unspecified and / immediately after PushVolatility, and indents Push Volatility and Push #2. Then we select Push Unspecified and replace it with #2. The result looks like this:
Push #27
Push ThisDirObject
Push ThisSubject
Push Affection
+
Push Volatility
Push #2
/
Push Empathy
-
/
Hmm, I wonder if it would be more readable this way:
Push #27
Push ThisDirObject
Push ThisSubject
Push Affection
Add
Push Volatility
Push #2
Divide
Push Empathy
Subtract
Divide