The ACE programming language will allow compound statements via blocks, in the following form:
BEGIN:
These statement blocks let us create little subsections of a program where new variables can be created and used. These new variables have scope only within the block. A block can contain statements or more blocks. Blocks are entered in the order they are written, and you can't just jump into the middle of one. Being able to do so would go against mathematical and logical instinct, and could create undesired side effects.
A two-way selector in the ACE programming language that just about everyone is familiar with is the "if...then...else" clause. Its form is very similar in nature to the forms defined by other programming languages.
IF (boolean expression) <statement or block> ELSE < different statement or block>
If the boolean expression is evaluated and equal to TRUE, the first statement or block is executed. Otherwise, the second statement or block is executed. Several statements can be selected in this manner, simply by putting them into a block. Under no circumstances are both statements/blocks executed.
We designed ACE to handle the "dangling else" issue by allowing blocks to be selected by the two-way selector. This way, when we specified that only a statement or a block can be selected, we disallowed the possibility of nested "if...then...else" clauses. The only way an "if...then...else" clause can be inside another "if...then...else" clause is if the second "if...then...else" clause is located within a block that the first "if...then...else" can select and execute.
In other words, an "if" statement can be followed by a single statement or the "BEGIN:" reserved word (which signifies the beginning of a block), but never another "if". If you want to use another "if" statement, you need to place it in a block. That way, each program segment or block will only have one "else" and the dangling "else" problem is solved. The upshot of all this is that "if" statements can not be nested, per se.
We do have a mathematical need for a multiple selection construct. Take, for example, this common Fibonacci algorithm:
if x = 1, then fib(x) = 1
if x = 2, then fib(x) = 1
if x > 2, then fib(x) = fib(x - 1) + fib(x - 2)
There are three separate cases here. We need a selection construct that can handle all of them. We've developed a "match card" statement that does this for us, with the following form:
MATCH CARD (X):
BEGIN:
"MATCH CARD (X)" takes in a card (variable) X. It does boolean comparisons, using the value of X, and performs more actions accordingly. All comparisons are made, but execution of statements or blocks only follow if the boolean expression immediately prior to has been evaluated as TRUE. For example, our "fib" function would have this form:
MATCH CARD (x):
BEGIN:
So if x was 1, x would be passed into the "match" statement. One would be compared to one in the first boolean expression. The value of that expression would be true, so the statement following would be executed. So fib(x) would be set to 1. When the program hits the period, it bounces to the next boolean expression and evaluates that. In our case, since 1 doesn't satisfy the other boolean expressions, no other statements or blocks are executed within this "match". It is entirely possible, however, that in some "match" statements that receive a certain value, more than one or even all the evaluations are true, and multiple statements or blocks are executed.
In the event that the value passed into the "match" statement satisfies no boolean expression within, nothing within the "match" is executed.
The ACE programming language will have counter-controlled loops, but the only counter variable suit we will use will be integers. Integers are sequential and easy to use. They are used as counters in math frequently (like in summations). Loop variables are just like normal variables...their scope lasts as long as that particular program segment is active. The programmer has to be careful, however, because this means that like any other variable, the counter could be modified. If this happens within the loop as a side effect, the number of times a loop is executed will be off. Also, this means that a variable will have some sort of value after loop termination. The actual value will depend on where and how the loop counter is incremented. The loop parameters will be evaluated once for every evaluation, since it is possible that the loop counter could be changed within the body of the loop (although it isn't a very wise maneuver).
The format for our counter controlled loop will be in the basic form of a "for" loop, a common loop found in many other languages:
FOR (INT <x> = <starting value>; <conditional>; <increment>):
Logically controlled loop structures are also allowed in the ACE programming language. The controlling condition is tested prior to each iteration, so our logically controlled loop takes the form of a "while" loop. A post-test loop can still be simulated by a "while" loop, if necessary. The logically controlled loop can also be used to simulate a counter controlled loop, if so desired.
A logically controlled loop executes until a certain boolean expression is evaluated as true. The form of our "while" loop is as follows:
WHILE (boolean expression):
There has to be a statement block within our loop because not only does the block execute some statement, but it must also contain some statement that changes the value of our boolean expression so that the loop will eventually end.
The only user-located loop control mechanism is the "BREAK" command, which enables the user to exit a loop at any time. This is frowned upon by the developers of ACE, however, since in our counter-controlled loops, our counters hold a value after loop execution. Breaking out of a loop early may invalidate the usefulness of that counter value, unless it is used for the position of the break.
The ACE programming language will not perform any iteration based on data structures. We see no need to. The data structure of greatest importance to ACE is the array, and should we ever need to do iterations based on the number of cells in the array, we can just use a counter controlled loop based on the length of the list.
Unconditional branching consists of a series of goto statements and labels that correspond to the goto statements. Our language will not include of goto statements, since we are focusing on readability. A program with goto's would appear tangled and unstructured, unlike ACE.
Goto statements are not used explicitly; they are only utilized in the creation of loops by the compiler. They are not accessible to the user.
Guarded commands are used where there are two or more different ways of proving something true. When true, the system will pick out one of these statements to execute. Implementation would be a massive if statement that had many different conditionals to check; the system chooses one of the true ones to execute in a nondeterministic fashion.
In a mathematical based language, there is no reason to have a guarded command. There is not a random answer for an equation, just one true answer. ACE will not comprise of guarded commands for this reason. Whenever, in ACE, a conditional is present, only one set of statements should be applicable. In a guarded command, the multiple conditionals would allow for a different answer each time (if more than one was true).