Data are the passive values manipulated by a program. In Lunar every datum, without exception, is an instance of a class that defines its structure. There are no magic "primitive" data values that work differently from everything else. Of course an implementation can invisibly use a special representation for some types, so long as the semantics are unchanged.
Memory management is dynamic and safe. Only the garbage collector can deallocate memory. Memory addresses are not exposed, so efficient compacting garbage collection can be used.
All array bounds are checked at run time except when references can be proven at compile time to be in-bounds. It is impossible to make a "wild" memory reference at run time. (There are special intrinsics defined in a special module which allow writing unsafe code, used only to write some of the runtime.)
Typing is dynamic. That is, objects have types. The type of an object is simply its class. An object is a member of its class and also is a member of each class from which its class inherits.
Definitions, slots, and method results have types too, but these are just a restriction on what objects can be the value of a definition, the value of a slot, or the result of a method. These declared types are more general than object types: they can be any type of type: a class, an integer range, an arbitrary set of objects, or a union or intersection of types.
An object can be a member of a non-class type, according to the definition of that type.
There is no "null pointer". However, "instance of class C or false" (written C | false) is a frequently used type that allows false to be used like the traditional null as an indication that no instance of class C is present. This is simply a type union of C and the false type. Note that false is different from the empty list, different from the null string, and different from zero.
There are no "uninitialized values." Every slot and every variable is initialized before it becomes visible.
The structure of a datum is a series of slots. Each slot can hold a value, a datum of some type. Each slot has a declared type; the value of the slot must be a member of that type.
Every direct instance of a class has the same number of slots. Each instance has its own copy of those slots with their own values.
A slot can be either constant or variable; if variable, the value can be changed to a different datum; if constant, the value never changes.
Every slot has a slot reader method which returns the value of the slot. Unless otherwise specified, the reader is a method for the . operator whose left-hand parameter is an instance of the class and whose right-hand parameter is the name of the slot.
Every variable slot has a slot writer method which changes the value of the slot. Unless otherwise specified, the writer is a method for the .:= function whose three parameters are an instance of the class, the name of the slot, and the new value. The method returns its third parameter.
Slot reader and writer methods are always sealed, so there cannot be any duplication of the slot name of an inherited slot.
The last slot in a datum can be a multi-slot whose value is a special kind of succession that is embedded in the datum rather than being a separate datum. This enables variable-length classes. The value of each member of a multi-slot must be a member of the slot's declared type.
A class can have zero or more superclasses. A class is said to be a subclass of each of its superclasses.
In addition to the slots it defines directly, a class inherits slots from its superclasses.
In addition to the superclasses it defines directly, a class inherits superclasses from those superclasses. The superclasses of a class are the set of all direct and inherited superclasses, in no particular order but with duplicates removed.
If a class does not directly define any superclasses, it automatically has the "top" class everything as its superclass.
A sealed class cannot have any subclasses unless they are defined in the same source file.
As explained in the next chapter ( see Behavior ) a datum's class also helps select the behavior of programs operating on that datum. Thus a class inherits behavior as well as slots from its superclasses.
Consistent Slot Order Rule
A class's ordered list of slots is constructed by visiting the class and all its superclasses in any order consistent with visiting a superclass before a subclass and visiting each class exactly once. When a class is visited, the slots it defines directly are appended to the list.
The Consistent Slot Order Rule states that the list of slots must be independent of the order of visiting superclasses. This imposes certain limitations on multiple inheritance. The simplest way to obey the rule is for only one direct superclass of a class to have any slots, but other class structures can satisfy the rule.
This rule implies that any instance of a subclass C2 of a class C1 begins with the slots of C1; additional slots may follow. Thus slot reader and writer methods can rely on the position of the slot being the same in any datum.
The Consistent Slot Order Rule also requires that only the last slot in the list can be a multi-slot. Thus no class that contains a multi-slot can have a subclass that adds more slots.
Unless it is declared abstract, a class has a constructor method that creates a new direct instance of the class and uses its parameters to initialize the slots. This initialization is inherited from superclasses as specified in the class definition.
By default the constructor is a method for the function with the same name as the class, but another name can be specified in the class definition.
If a class requires additional initialization besides setting the slot values, the constructor should be given a "private" name and the apparent constructor should be a user-defined method that calls the private constructor and then does the initialization.
There are no "destructors" nor "finalizers." Memory management is completely automatic and invisible.
Previous page Table of Contents Next page