This is an informal specification of the Opal programming language. Since it is a specification it attempts to be thorough, all features of the language will be covered including restrictions on the behavior and timing of certain constructs, as well as implementation dependent features. If one fully understands this document it should be possible to write a correct
compiler for Opal. However, this specification is informal. That means that it does not define everything in the most rigorous terms and may leave doubt about the interaction of certain language constructs which would have to be resolved by considering the spirit and philosophy of the Opal language.
This informal specification assumes some background knowledge in programming and object-oriented programming. It does try to provide definitions and explanations of all concepts for clarity and in case they differ from other languages or one's preconceived notions. Knowledge of Java, GJ, C#, C++, Simula and Small Talk would be helpful to anyone trying to read this specification.
Opal is a new object-oriented (OO) programming language. I have designed it in accordance with the design precepts paper which I wrote previously. It attempts to achieve the following goals:
Opal is not the end all be all of programming languages. It is not perfect. Neither is it an academic or toy language. Opal is designed for solving real-world, large to small scale programming challenges.
Important/official terms are italicized when first formally presented and defined within the next few sentences. Code written in a paragraph is enclosed by 'single quotes'. When names and keywords from code are used in a paragraph they are not given any special treatment except when set off in quotes as an example or to clarify. Code snippets may also be set off from paragraphs as:
(code here)Whenever code appears it is written in a monospace font. All code snippets are legal Opal code unless otherwise specified. In all cases code is syntax highlighted
by putting keywords in blue, primitive types in teal, string literals in grey and comments in dark red. When a name appears in code that is meant to signify some generic entity of a particular type it is written in italic and the name indicates what type of entity belongs there. Code meant to represent the complete contents of a file is set off in a block like so:
|
(code here) |
Historically all classes had to have names (Simula may have been an exception to this). Java changed this by the introduction of what it called anonymous inner classes. Opal takes this idea one step further and considers whether objects have names or not to. In Opal, types may be named or unnamed. In addition objects may be named or unnamed. Keep this in mind as you read about the different features of Opal.
Another important distinction is spatial ordering verses temporal ordering. All programming constructs can be seen to operate in one of these two ways, some operate in both ways. Commonly objects have provided spatial ordering while methods provided temporal ordering. In Opal the object is the unit of both spatial and temporal ordering. When an object is created it provides temporal ordering through its creation code (see 2.1.2 Creation Code). Later an object provides spatial ordering as it stores the properties created and initialized by the creation code.
The Opal language makes a distinction between fundamental and non-fundamental features. Fundamental features are considered core to the language. If they did not exist then their would be limits on what could be expressed or on the freedom of use of a language feature. Non-fundamental features on the other hand add nothing new and can in general be expressed in the fundamental language. Often they provide syntactic sugar for an already existent feature. Whether a given feature is fundamental or not may be debatable in some cases. In general, sections one through ten introduce fundamental features while sections after that introduce non-fundamental features. This is the case unless otherwise noted.
One important difference between Opal and other languages is what is known as ASAP Garbage Collection (see 15.1 ASAP Garbage Collection). Many object oriented languages use garbage collection (GC) to recover memory which was allocated but no longer in use. However, most languages make no guarantee as to the time of GC for any object. Opal guarantees that whenever possible objects will be deleted as soon as they are no longer in use and that when such optimizations are not possible, garbage collection will occur on a timely continuous level. ASAP GC is achieved by performing advanced analysis of the object structure to determine when traditional memory management techniques will be sufficient and to rewrite the program to use them. Conversions which are common include: Conversion to a local variable especially in methods. Conversion to a manually allocated and deallocated pointer especially in classes with unshared properties. Conversion to a reference counted variable when the object graph doesn't include cycles (this is made efficient by compiler support so that the count doesn't have to be updated as often). Variables that are not applicable to these optimizations may be the target of other optimizations or of an incremental garbage collector. Compilers should have features allowing the control of these features (for example force no GC
mode for real-time application compiles).
Opal's syntax has been designed to provide great uniformity in use. It is helpful at this point to give a general definition of important syntax.
| { } | Curly braces are used to create blocks which organize things temporally and spatially. Blocks are used to describe objects and patterns. |
| : | Means "is a", "extends", "implements", or "replaces". The essential characteristic here is that the entity before the colon can be used as or somehow takes the place of the entity after the colon. |
| < > | The greater than and less than symbols are used to indicate parametric polymorphism. In the context of OO programming it can be reasonably understood to mean generic over (as in GJ). In the procedural style the name templates used by C++ may be more appropriate. |
| , | The comma is used to mean building a list or tuple so that (3, 4) would create a list out of the items 3 and 4. Lists also appear in function calls. |
| ( ) | Parentheses are used as grouping in mathematical expressions and around lists and tuples to indicate that they are lists. Function calls are the juxtaposition of a function name and a tuple grouped using parentheses of the parameters to call it will. |
| . | The period is used between names to mean member selection a.b means select b out of a. |