All variable names will be up to 32 characters long including all letter characters and underscores. Most often, our language will use single character names for variables, since this is the way that most math is done. Our names are case sensitive in order to avoid confusion. (This will allow mathematicians to input their formulas without any major changes; as in Ax^2 + Bx + C.) The long filenames will make this language easily be able to accept input (in numeric form) from other languages as discussed in Section 1:Background. We have a few special terms when referring to the ACE programming language, such as "card"( a card is a variable) and "suit"( a suit is a data type). We will discuss these terms in more detail later.
There will be special, or reserved, words in the ACE programming language. These words will be for definitions of the suit of a card and the operations performed on the cards.
Some examples of reserved words in our language include:
| INT | Creates a card of suit integer |
| REAL | Creates a card of suit real |
| FRAC | Creates a card of suit fraction; to output in fraction form instead of real: 0.66667 -> output 2/3 |
| UNDEF | An implicitly declared card, to be defined at a later point in the program depending on what type the data to be stored in this variable needs. (We will discuss this more at a later point). |
| IF, THEN, ELSE | If statement in form of: if(<conditional>) then <statements> else <statements> |
| BEGIN, END | Statement beginning a set of instructions until the end is reached. |
| FOR | Loop statement in the form of: for(<beginning>, <conditional>, <continuation of loop>) |
| CONST | Creates a constant card, one which cannot be changed by operation or by assignment. |
Certain library functions will also have predefined words that act as reserved words:
| Abs( ) | Absolute value function |
| Frac( ) | Change a variable type to a fraction ( in this case, if possible within a certain accuracy) |
| Int( ) | Change a variable type to an integer. |
| Real( ) | Change a varaible type to a real number |
| Ln( ) | Perform the Log natural function on a number |
| Log( ) | Perform the Log function on a number |
| Cos( ) | Perform the Cosine function on a number |
| Sin( ) | Perform the Sine function on a number |
| Shuffle() | Randomize a list of elements |
| Evaluate( ) | Evaluate an equation |
** More functions and variable names are likely to come about as this language develops.
Names in the ACE programming language will be up to 32 characters. These variable names can include underscores, numbers, and capital letters. All variable names must begin with a letter character. Since capitals will be included, names of variables will be case sensitive. Instead of referring to an unknown as a variable, we will use the term "card". The term "suit" refers to the data type of a variable. So an integer called x, when talking about the ACE programming language, is called "card x, of suit integer".
Cards in the ACE programming can be associated with more than one memory location. For instance, a program with two subroutines, SUB1 and SUB2, may each refer to a card X. But that card may have a different value or meaning in each of the subroutines. So card X can have two seperate memory cells associated with the name X, with different values.
2.2.3 Aliases
The ACE programming language will never have multiple references to the same memory address. In other words, this language will have no aliases or pointers. The nature of the problems ACE deals with (no pun intended) shouldn't require the use of pointers or aliases. This avoids a lot of confusion for the programmer and excludes the possibility of a card's value being changed accidentally through the change of cards with different names but the same memory address.
Please remember that in the ACE programming language, the data type of a variable (card) is referred to as its suit. The basic suits include INT (an integer), REAL (a real number), LONG INT (a larger integer, of 64 bits opposed to the normal integer of 32 bits), FRAC (a symbolic number representation to simulate fractions), UNDEF (a special term that we will explain later; it lets us manipulate an undefined card), CONST (a term that tells the compiler that this card's type will not change), etc. These types will all be developed to support basic mathematic operations, as well as special ACE functions.
Cards in the ACE programming language must be explicitly declared, along with the suit of a card. That way the suit and card are bound at compile time.
EXAMPLES: INT X, REAL NUM, BIG INT NUM2, etc.
There is one exception: the UNDEF suit. If possible, we would like to make cards of suit UNDEFimplicitly declared, so a card of suit undef can be redefined as another type at runtime. For example, take the mathematical equation "x^2 + 3x + 2 = 0" or some similar quadratic equation. The roots (i.e. solutions) of this kind of equation could be integers, real numbers, or even complex numbers. We won't know until we evaluate it. The card x refers to the solution, and lets the computer manipulate x even though it doesn't have a set value type/suit. When a solution is obtained, then card x's suit is "instantiated", sort of like Prolog. In this case, somewhere in the body of the program before the equation, we write "UNDEF x". An example of this being of value would be in polynomial equations. The suit of the card will be unknown until the equation is solved. Once solved, the suit of the card will be known; either int, real, or a long int.
The lifetime of our cards begin when they are bound to a specific suit. When bound, memory space is allocated. Throughout the entire ACE program, the binding stays the same (i.e. suits don't change, with the possible exception of the UNDEF suit). When the program ends, the memory cells are de-allocated, and cards and suits are unbound.
Most type checking can be done statically. In other words, type checking is done prior to run time. If a particular suit can't be used with a particular operation, then the compiler will signal an error. For example, if you try to say, "INT x = 3.14", the compiler will burp and say that this is a incompatible type error. Because of the suit UNDEF, this language is not strongly typed. You can't really type check operations involving the UNDEF suit. Checking with the UNDEF suit is dynamic; therefore an UNDEF card has its type checked at run time.
As with most programming languages, different variable types are not compatible. To change a card's suit, a type casting operation would have to be performed, such as Real( ), to return the card's value as an integer.
Depending on how they are declared, cards will be able to be used either globally or locally. Changes on local cards in a subroutine have absolutely no effect on cards of the same name in other subroutines. A change to a local card that has the same name as a global card will only affect the local card.
Scoping is static, meaning the scope of a card is determined prior to runtime. The scope of a card is determined by where the card is initially declared. We might decide to specifically define/label global variables for ease of readibility and understanding. All cards are local by default. To change them over to global, we might do something like this: global (<suit> <card>). This isn't really a function, more like a label for the compiler to know that this card is global to a particular program unit.
A card's lifetime begins when a card is bound to a suit and memory location, and the scope is the time period when the card is visible in the program. Since memory in ACE is deallocated after execution, the lifetime of a card could very well exceed its scope.
ACE supports named constants through the CONST reserved word. This allows for increased readability and program reliability, by preventing accidental variable change.
Binding of a specific value to a specific card in the ACE programming language is called initialization. Since cards are statically bound to storage, binding and initialization occur prior to runtime. In other words, a card must be initialized to some value before runtime (with the possible exception of UNDEF...see the above discussion for information on UNDEF). Initialization can occur at the same time that a card is declared. For example, "INT x = 10" is a valid declaration in ACE.