In the ACE programming language, we use infix notation, because that is the most common method used in the world of mathematics. Infix notation is when we have operators between variables; A + B * C is an example. As a side note, we should mention that ACE will also support unary operators (operators that work on only one variable). This includes increments (as in C++) and the negation operator. We will use the order of operation we all learned in grammar school: PEMDAS. Anything in Parenthesis get evaluated first, then anything with an Exponent gets evaluated. Next, and Multiplications and Divisions are evaluated; and finally, Additions and Subtractions are performed. We should also note that unary operators take precedence over everything. The order of operation as described above is our operator precedence.
In the case of an expression with several operations of equal precedence, ACE will evaluate the program from left to right. That makes the ACE programming language left associative. We will have elements of ACE that will be right associative, such as the unary operator ++ (although currently, this is the only operation treated in a right associative manner).
In mathematics there will be a specific reasoning for the use of conditionals: checking values of expressions. As in most languages, we will have the basic IF statement. This is declared in the following fashion:
IF( <conditional>)
If <conditional> is true, then <card> is set to <expression1>. If <conditional> is false, then <card> is set to <expression2>.
Anything within parenthesis will be evaluated first, and after evaluation will then be treated as an operand. After parenthesis are evaluated, all operands will be evaluated from left to right. We do this to be consistent (considering that ACE is left associative); also, perhaps side effects will be prevented or reduced if the programmer is aware that operands are evaluated from left to right.
The ACE programming language will not allow for user overload of operators. Overloaded operators will only be used by the compiler itself. Usage of operators will depend on the context of the expression and the suits used in the expression. For a language based on mathematics, there is no viable reason for the user to overload an operator. For each occurence where an operator could be overloaded, the programmer can just write a new function to perform the task.
Some predefined overloaded operators include addition and multiplication for arrays (for use in polynomial evaluation). Others will be defined later.
We have decided that the ACE programming language will allow mixed-node expressions. This means that ACE will allow expressions that have an operator that has operands of different suits. We have to define some conventions for implicit operand suit conversions (i.e. coercions). Some of those conventions include the following:
| INT * REAL = REAL | INT / REAL = REAL | FRAC * INT = FRAC | FRAC / INT = FRAC |
| FRAC * REAL = REAL | REAL / INT = REAL | INT + REAL = REAL | INT - REAL = REAL |
| FRAC + REAL = REAL | FRAC / REAL = REAL | FRAC + INT = FRAC | etceteras |
At runtime, if there is a need for a type conversion in an expression, this will be done automatically. The programmer will not necessarily know the exent of the values that users will input. This is not only for the user's sake, but also for ease of programming. When writing equations, the programmer will not have to worry about the results of all calculations. (You may not know ahead of time what size or suit the resulting card will be.) An example of this is a result that is 42 bits long, trying to be stored into an integer which can only store 32 bits. This card would have to be converted to a long integer (max of 64 bits) to store the 42 bit long result.
In other words, the ACE programming language won't have any explicit type conversions. It does, however have functions that return the value of a variable of one type in the form of another type. Example: the Real( ) function takes in a parameter of any other type and returns the value of the parameter in the form of a real number.
Our relational expressions will be composed of two operands and a operator. The operators used on the expressions will the basic comparisions : equal to, not equal to, greater than (or equal to), and less than (or equal to). The symbols for these will be the same as used in mathematics: == (to distinguish from assinging a value), ~= (not equals), <, > , <=, and >=.
Our mathematical language will utilize various boolean expressions. Along with the basic AND, NOT, and OR expressions; ACE will comprise of XOR, XAND, and XNOR. These will be reserved words (user will not be able to create a card with that name) represented as shown above in bold. Since all these boolean expressions have the same recedence, parentheses will have to be used.
Being a math orientated language, ACE will utilize short-circuit evaluations. We will save computational time by avoiding unnecessary evaluations. In the case of the boolean AND, if the first half is false, then there is no need to check the second half of the expression.
Basic assignments are defined in the following manner:
Multiple targets are allowed, separated by equal signs: x = y = z;
Coercion can be used in cases of type mismatch, in a similar fashion to the way we used coercion with the expressions as discussed above. In other words, the ACE language will allow for assignment coercion in some cases. For instance, INT values can be assigned to a REAL, but not vice versa. Coercion always occurs on the right side of an expression.