Maximal and minimal types, identity testing, and printing

concrete object void;

void is the type of methods that do not return a result. void is a supertype of all other types. The void object can be returned explicitly from a method, if necessary.

abstract object any;

any is the supertype of all other non-void types, implicitly.

type none;

The none type is the result type of functions that never return to their callers, and the type of closure arguments that are never invoked. none is the subtype of all other types; there is no object of this type.

type dynamic;

The dynamic type disables static type checking. It's used to explicitly declare the type of a variable that cannot be statically checked. An omitted type declaration defaults to dynamic.

In general.cecil:

method ==(l:any, r:any):bool;  - object identity test; very low-level, but fast
method !==(l:any, r:any):bool;  - not ==

All objects can be compared for identity, using a low-level implementation-dependent test. Two things that print out the same may not be ==, e.g. "abc" == "abc" may return false. By default, operations on collections that compare elements, such as finding an element in a list or adding an element to a set, use = (implemented by comparable objects) rather than ==, unless the collection's name includes identity_.

method print_string(x:any):string;  - return a string print version
method print(x:any):void;  - print the print_string
method print_line(x:any):void;  - print the print_string and a newline
method print_line():void;  - just print a newline

Any object can be converted to a string, although the default version can be low-level and ugly. Most commonly-used objects override print_string to return something prettier. (A two-element version of print permits strings to be printed to unix_files.)

method error(msg:ordered_collection[`T]):none;  - quits with an error message; does not return

The error method is the standard way to prematurely quit execution of a Cecil program.

concrete object not_defined;

The not_defined object can be used as a dummy object if there isn't a real one to use, e.g., if you have to have an uninitialized variable or field or want to reflect whether or not some value is present. not_defined is therefore used in places where a NULL pointer might be used in other languages. In general, it is poor style to use not_defined. It is better to define an application-specific ``absent'' object, integrated into a little class hierarchy of present or absent data, with appropriate application- specific behavior attached to the ``absent'' object.