+Limbo is a programming language intended for applications +running distributed systems on small computers. +It supports modular programming, +strong type checking at compile- and run-time, +interprocess communication over typed channels, +automatic garbage collection, +and simple abstract data types. +It is designed for safe execution even on +small machines without hardware memory protection. +
++In its initial implementation for the Inferno operating system, +object programs generated by the Limbo compiler run +using an interpreter for a fixed virtual machine. +Inferno and its accompanying virtual machine run either stand-alone +on bare hardware +or as an application under conventional operating systems like +Unix, Windows 95, Windows NT, and Plan 9. +For several architectures, including +Intel x86 and MIPS, Limbo object programs +are transformed on-the-fly into instructions for the underlying hardware. +
++A Limbo application consists of one or more +modules, +each of which supplies an interface declaration and +an implementation part. +A module that uses another module +includes its declaration part. +During +execution, a module dynamically attaches another module by +stating the other module's type identifier and a place from which to load +the object code for its implementation. +
++A module declaration specifies the functions and data it will make visible, +its data types, and constants. +Its implementation part defines the functions and data visible at its interface and +any functions associated with its data types; +it may also contain definitions for functions used only internally and +for data local to the module. +
++Here is a simple module to illustrate the flavour of the language. +
1 implement Command;
+
+2 include "sys.m";
+3 include "draw.m";
+
+4 sys: Sys;
+
+5 Command: module
+ {
+6 init: fn (ctxt: ref Draw->Context, argv: list of string);
+7 };
+8 # The canonical "Hello world" program, enhanced
+9 init(ctxt: ref Draw->Context, argv: list of string)
+10 {
+11 sys = load Sys Sys->PATH;
+12 sys->print("hello world\n");
+13 for (; argv!=nil; argv = tl argv)
+14 sys->print("%s ", hd argv);
+15 sys->print("\n");
+16 }
++Let's look at the program line-by-line. +It begins (line 1) by saying that this is the implementation of module +Command. +Line 2 includes a file (found in a way analogous to C's +#include +mechanism) named +sys.m. +This file defines the interface to module +Sys; +it says, in part, +
Sys: module {
+ PATH: con "$Sys";
+ . . .
+ print: fn (s: string, *): int;
+ . . .
+};
++Line 3 includes +draw.m; +only one piece of information, mentioned below, +is used from it. +Line 4 declares the variable +sys +to be of type +Sys; +its name will be visible throughout the remainder of the file +describing this module. +It will be used later to refer to an instance of the +Sys +module. +This declaration initializes it to +nil; +it still needs to be set to a useful value. +
++Lines 4-7 constitute the declaration of +Command, +the module being implemented. +It contains only a function named +init, +with two arguments, a +ref +Draw->Context +and a list of strings, +and it doesn't +return any value. +The +ref +Draw->Context +argument would be used if the program did any +graphics; it is a data type defined in +draw.m +and refers to the display. +Since the program just writes text, it won't be used. +The +init +function isn't special to the Limbo language, +but it is conventional in the environment, +like +main +in C. +
++In a module designed to be useful +to other modules in an application, it would be wise to +take the module declaration for +Command +out, put it in a separate file called +command.m +and use +include +command.m +to allow this module and others to refer to it. +It is called, for example, by the program loader in the Inferno +system to start the execution of applications. +
++Line 8 is a comment; everything from the +# +to the end of line is ignored. +
++Line 9 begins the definition for the +init +function that was promised in the module's declaration +(line 6). +The argument that is a list of strings is named +argv. +
++Line 11 connects the program +being written to the +Sys +module. +The first token after +load +is the target module's name as defined by its interface +(here found in the +include +on line 2) +The next token is the place +where the code for the module can be found; it is a string +that usually names a file. +Conventionally, in the Inferno system, +each module contains a constant declaration for the name +PATH +as a string that names the file where +the object module can be found. +Loading the file is performed dynamically during +execution except for a few modules built +into the execution environment. +(These include +Sys; +this accounts for the peculiar file name +$Sys +as +the value of +PATH.) +
++The value of +load +is a reference to the +named module; line 11 assigns it +to the variable +sys +for later use. +The +load +operator dynamically loads the code for the named +module if it is not already present and instantiates +a new instance of it. +
++Line 12 starts the work by printing a familiar message, +using the facilities provided by module +Sys +through its handle +sys; +the notation +sys->print(...) +means to call the +print +function of the module referred to by +sys. +The interface of +Sys +resembles a binding to some of +the mechanisms of Unix and the ISO/ANSI C library. +
++The loop at lines 13-14 takes the +list +of +string +argument to +init +and iterates over it using the +hd +(head) and +tl +(tail) operators. +When executed, this module combines the +traditional `Hello world' and +echo. +
++There are several kinds of tokens: +keywords, identifiers, constants, strings, expression operators, +and other separators. +White space (blanks, tabs, new-lines) is ignored except that +it serves to separate tokens; sometimes it is required +to separate tokens. +If the input has been parsed into tokens up to a particular +character, the next token is taken to include the longest +string of characters that could constitute a token. +
++The native character set of Limbo is Unicode, +which is identical with the first 16-bit plane of the ISO 10646 standard. +Any Unicode character may be used in comments, or in strings +and character constants. +The implementation assumes that source files use the UTF-8 representation, +in which 16-bit Unicode characters are represented as sequences +of one, two, or three bytes. +
++Comments begin with the +# +character and extend to the end of the line. +Comments are ignored. +
++An identifier is a sequence of letters and digits +of which the first is a letter. +Letters are the Unicode characters +a +through +z +and +A +through +Z, +together with the underscore character, and +all Unicode characters with encoded values greater than 160 +(A0 hexadecimal, the beginning of the range corresponding to Latin-1). +
++Only the first 256 characters in an identifier +are significant. +
++The following identifiers are reserved for use as keywords, +and may not be used otherwise: +
adt alt array big + break byte case chan + con continue cyclic do + else exit fn for + hd if implement import + include int len list + load module nil of + or pick real ref + return self spawn string + tagof tl to type + while +
+There are several kinds of constants for denoting values of the +basic types. +
++
++Integer constants have type +int +or +big. +They can be represented in several ways. +
++Decimal integer constants consist of a sequence of decimal +digits. +A constant with an explicit radix +consists of a decimal radix followed by +R +or +r +followed by the digits of the number. +The radix is between 2 and 36 inclusive; +digits above 10 in the number +are expressed using letters +A +to +Z +or +a +to +z. +For example, +16r20 +has value 32. +
++The type of a decimal or explicit-radix number is +big +if its value exceeds +231-1, +otherwise it is +int. +
++Character constants consist of a single Unicode +character enclosed within single-quote characters +'. +Inside the quotes the following escape sequences represent +special characters: +
\' single quote +\" double quote +\\ backslash +\t tab +\n newline +\r carriage return +\b backspace +\a alert character (bell) +\v vertical tab +\udddd Unicode character named by 4 hexadecimal digits +\0 NUL +
+Real constants consist of a sequence of decimal digits +containing one period +. +and optionally followed by +e +or +E +and then by a possibly signed integer. +If there is an explicit exponent, the period is +not required. +Real constants have type +real. +
++String constants are sequences of Unicode characters contained in double +quotes. +They cannot extend across source lines. +The same escape sequences listed above for character +constants are usable within string constants. +Strings have type +string. +
++The constant +nil +denotes a reference to nothing. +It may be used where an object of a reference +type is expected; +otherwise uninitialized values of reference type +start off with this value, it can be assigned to +reference objects, and reference types can be +tested for equality with it. +(The keyword has other uses as well.) +
++The operators are +
+ - * / % & | ^ + == < > <= >= != << >> + && || <- :: + = += -= *= /= %= &= |= ^= <<= >>= + := + ~ ++ -- ! +
: ; ( ) { } [ ]
+ , . -> =>
++In this manual, Limbo syntax is described by a modified BNF +in which syntactic categories are named in an +italic +font, and literals in +typewriter +font. +Alternative productions are listed on separate lines, and +an optional symbol is indicated with +the subscript ``opt.'' +
++Limbo has three kinds of objects. +Data +objects exist in the storage associated with +a module; they can be manipulated by arithmetic operations, +assignment, selection of component entities, and other concrete +operations. +Each data object has a type that determines what can be stored +in it and what operations are applicable. +
++The second kind of object is the +function. +Functions are characterized by the types of the arguments they +accept and the values they return, and are associated with +the modules in which they are defined. +Their names can be made visible in their module's declaration, +or they can be encapsulated within the +adt +(abstract data types) of their modules, +or they can exist privately within their module. +
++Finally, Limbo programs are organized into +modules: +a named collection of constants, abstract data types, +data, and functions made available by that module. +A module declaration displays the +members visible to other modules; +the module's implementation +defines both the publicly visible members and its +private parts, including the data objects it uses. +A module that wishes to use +the facilities of another includes its declaration in order to +understand what it exports, but +before using them it explicitly loads the new module. +
++Limbo has several basic types, some built-in higher abstractions, +and other ways of composing new types. +In declarations and some other places, constructions naming +a type are used. +The syntax is: +
+type: + data-type + function-type +
+
+The syntax of data types is +
+data-type: + byte + int + big + real + string + tuple-type + array of data-type + list of data-type + chan of data-type + adt-type + ref adt-type + module-type + module-qualified-type + type-name + +data-type-list: + data-type + data-type-list , data-type +
+
+The five basic data types are denoted by +byte, +int, +big, +real, +and +string. +
++Bytes are unsigned 8-bit quantities. +
++Integers +(int) +are 32-bit signed quantities represented in two's complement +notation. +Large integers +(big) +are 64-bit signed quantities represented in two's complement notation. +
++Real numbers +(real) +are 64-bit quantities represented in the +IEEE long floating notation. +
++The +byte, +int, +big, +and +real +types are collectively called arithmetic types. +
++Strings are rows of Unicode characters. +They may be concatenated and extended character-by-character. +When a string is indexed with a single subscript, it yields an integer +with the Unicode encoding of the character; +when it is indexed by a range, it yields another string. +
++The +tuple +type, denoted +
+tuple-type: + ( data-type-list ) +
+
+The +array +type describes a dynamically-sized row of objects, all of the same +type; it is indexed starting from 0. +An array type is denoted by +
+ array of data-type +
+
+A +list +is a sequence of like-typed objects; its denotation is +
+ list of data-type +
+
+A +channel, +whose type is written +
+ chan of data-type +
+
chan of (int, string) +
c <-= (123, "Hello"); +
+An abstract data type or +adt +is an object that can contain data objects of several +different types and declare +functions that operate on them. +The syntax for declaring an +adt +is given later. +Once an +adt +has been declared, the identifier associated with it +becomes a data-type name. +
+adt-type: + identifier + module-qualified-type +
+
+There is also a +ref +adt +type representing a reference (pointer) to an +adt. +It is denoted +
+ ref adt-type +
+
+A module type name is an identifier: +
+module-type: + identifier +
+
+When an +adt +is declared within a module declaration, the type name of that +adt +is not generally visible to the rest of the program unless a specific +import +request is given (see §6.6, §10 below). +Without such a request, when +adt +objects implemented by a module are declared by a client +of that module, the +adt +type name is qualified: +
+module-qualified-type: + identifier -> identifier +
+
+Finally, data types may be named, using a +type +declaration; this is discussed in §6.4 below. +
+type-name: + identifier +
+
+A function type characterizes the arguments and return value of +a function. The syntax is +
+function-type: + fn function-arg-ret + +function-arg-ret: + ( formal-arg-listopt ) + ( formal-arg-listopt ) : data-type + +formal-arg-list: + formal-arg + formal-arg-list , formal-arg + +formal-arg: + nil-or-D-list : type + nil-or-D : self refopt identifier + nil-or-D : self identifier + * + +nil-or-D-list: + nil-or-D + nil-or-D-list , nil-or-D + +nil-or-D: + identifier + nil + +
+
fn (nil: int, nil: int): int + fn (radius: int, angle: int): int + fn (radius, angle: int): int +
fn (nil: string) +
+The +self +keyword has a specialized use within +adt +declarations. +It may be used only for the first argument +of a function declared within an +adt; +its meaning is discussed in §6.3 below. +
++The star character +* +may be given as the last argument in a function type. +It declares that +the function is variadic; during a call, actual arguments at its +position and following are passed in a manner +unspecified by the language. +For example, the type of the +print +function of the +Sys +module is +
fn (s: string, *): int +
+Limbo source programs that implement modules are stored in files, +conventionally named with the suffix +.b. +Each such file begins with a single +implement +directive naming the type of the module being implemented, +followed by a sequence of declarations. +Other files, conventionally named with the suffix +.m, +contain declarations for things obtainable from other modules. +These files are incorporated by an +include +declaration in the implementation modules that need them. +At the top level, a program consists of a sequence +of declarations. +The syntax is +
+program: + implement identifier ; top-declaration-sequence + +top-declaration-sequence: + top-declaration + top-declaration-sequence top-declaration + +top-declaration: + declaration + identifier-list := expression ; + identifier-list = expression ; + ( identifier-list ) := expression ; + module-declaration + function-definition + adt-declaration +
+
+Declarations are used both at the top +level (outside of functions) and also inside functions +and module declarations. +Some styles of declaration +are allowed only in certain of these places, +but all will be discussed together. +
++Declarations take several forms: +
+declaration: + identifier-list : type ; + identifier-list : type = expression ; + identifier-list : con expression ; + identifier-list : import identifier ; + identifier-list : type type ; + include string-constant ; + +identifier-list: + identifier + identifier-list , identifier + +expression-list: + expression + expression-list , expression +
+
+These forms constitute the basic way to declare and +initialize data: +
+ identifier-list : type ; + identifier-list : type = expression ; +
+
+For example, +
i, j: int = 1; + r, s: real = 1.0; +
+Another kind of declaration is a shorthand. +In either of +
+ identifier := expression ; + ( identifier-list ) := expression ; + +
+
x: int = 1; +
x := 1; +
(p, q) := (1, 2.1); +
+The +con +declaration +
+ identifier-list : con expression ; +
+
Seven: con 3+4; +
+The identifier +iota +has a special meaning in the expression in a +con +declaration. +It is equivalent to the integer constant +0 +when evaluating the expression for the first (leftmost) identifier declared, +1 +for the second, and so on numerically. +For example, the declaration +
M0, M1, M2, M3, M4: con (1<<iota); +
+The identifier +iota +is not reserved except inside the expression +of the +con +declaration. +
++An +adt +or abstract data type contains data objects and functions that +operate on them. +The syntax is +
+adt-declaration: + identifier : adt { adt-member-listopt } ; + +adt-member-list: + adt-member + adt-member-list adt-member + +adt-member: + identifier-list : cyclicopt data-type ; + identifier-list : con expression ; + identifier-list : function-type ; + pick { pick-member-list } +
+
Point: adt {
+ x, y: int;
+ add: fn (p: Point, q: Point): Point;
+ eq: fn (p: Point, q: Point): int;
+ };
+r, s: Point; + xcoord: int; + ... + xcoord = s.x; + r = r.add(r, s); +
+As this example indicates, +adt +members are accessed by mentioning an object with the +adt +type, a dot, and then the name of the member; +the details will be discussed in §8.13 below. +A special syntactic indulgence is available for functions declared within an +adt: +frequently such a function +receives as an argument the same object used to access it +(that is, the object before the dot). +In the example just above, +r +was both the object being operated on and the first argument to the +add +function. +If the first formal argument of a function declared in an +adt +is marked with the +self +keyword, then in any calls to the function, the +adt +object is implicitly passed to the function, and +is not mentioned explicitly in the actual argument list +at the call site. +For example, in +
Rect: adt {
+ min, max: Point;
+ contains: fn(r: self Rect, p: Point): int;
+ };
+
+ r1: Rect;
+ p1: Point;
+ ...
+ if (r1.contains(p1)) ...
++If +self +is specified in the declaration of a function, it must also be +specified in the definition as well. For example, +contains +would be defined +
Rect.contains(r: self Rect, p: Point)
+ {
+ . . .
+ }
++The +adt +type in Limbo +does not provide control over the visibility +of its individual members; if any are accessible, all are. +
++Constant +adt +members follow the same rules as ordinary constants (§6.2). +
++The +cyclic +modifier will be discussed in §11.1. +
++An +adt +which contains a +pick +member is known as a +pick +adt. +A +pick +adt +is Limbo's version of a +discriminated union. +An +adt +can only contain one +pick +member and it must be the last component of the +adt. +Each +identifier +enumerated in the +pick-tag-list +names a variant type of the +pick +adt. +The syntax is +
+pick-member-list: + pick-tag-list => + pick-member-list pick-tag-list => + pick-member-list identifier-list : cyclicopt data-type ; +
+
+pick-tag-list: + identifier + pick-tag-list or identifier +
+
+The +pick-member-list +contains a set of data members for each +pick-tag-list. +These data members are specific to those variants of the +pick +adt +enumerated in the +pick-tag-list. +The +adt +data members found outside of the +pick +are common to all variants of the +adt. +A +pick +adt +can only be used as a +ref +adt +and can only be initialized from a value of one of its variants. +For example, if +Constant +is a +pick +adt +and +Constant.Real +is one of its variant types then +
c : ref Constant = ref Constant.Real("pi", 3.1);
++The type declaration +
+ identifier-list : type data-type ; +
+
+A module declaration collects and packages declarations of +adt, +functions, constants and simple types, and creates an +interface with a name +that serves to identify the type of the module. +The syntax is +
+module-declaration: + identifier : module { mod-member-listopt } ; + +mod-member-list: + mod-member + mod-member-list mod-member + +mod-member: + identifier-list : function-type ; + identifier-list : data-type ; + adt-declaration ; + identifier-list : con expression ; + identifier-list : type type ; +
+
Linear: module {
+ setflags: fn (flag: int);
+ TRUNCATE: con 1;
+ Vector: adt {
+ v: array of real;
+ add: fn (v1: self Vector, v2: Vector): Vector;
+ cross: fn (v1: self Vector, v2: Vector): Vector;
+ dot: fn (v1: self Vector, v2: Vector);
+ make: fn (a: array of real): Vector;
+ };
+ Matrix: adt {
+ m: array of array of real;
+ add: fn (m1: self Matrix, m2: Matrix): Matrix;
+ mul: fn (m1: self Matrix, m2: Matrix): Matrix;
+ make: fn (a: array of array of real): Matrix;
+ };
+};
+linearmodule: Linear; +
linearmodule = load Linear "/usr/dmr/limbo/linear.dis";
+ if (linearmodule == nil) {
+ sys->print("Can't load Linear\n");
+ exit;
+ }
++To initialize data declared as part of a module +declaration, an assignment expression may be used at the top level. +For example: +
implement testmod;
+ testmod: module {
+ num: int;
+ };
+ . . .
+ num = 5;
++These declarations take the form +
+ identifier-list : import identifier ; +
+
+The string following the +include +keyword names +a file, which is inserted into the program's +text at that point. +The included +text is treated like text literally present. +Conventionally, included files declare +module interfaces and are named with the suffix +.m. +The directories to be searched for included files +may be specified to the Limbo compiler command. +Include files may be nested. +
++All executable code +is supplied as part of a function definition. +The syntax is +
+function-definition: + function-name-part function-arg-ret { statements } + +function-name-part: + identifier + function-name-part . identifier +
+
add_one(a: int): int
+ {
+ return a+1;
+ }
++Functions that are declared within an +adt +use the qualified form of definition: +
Point: adt {
+ x, y: int;
+ add: fn (p: Point, q: Point): Point;
+ eq: fn (p: Point, q: Point): int;
+ }
+ . . .
+ Point.add(p: Point, q: Point): Point
+ {
+ return Point(p.x+q.x, p.y+q.y);
+ }
++Expressions in Limbo resemble those of C, although some +of the operators are different. +The most salient difference between Limbo's expression +semantics and those of C is that Limbo +has no automatic coercions between types; in Limbo every +type conversion is explicit. +
++The basic elements of expressions are terms: +
+term: + identifier + constant + real-constant + string-constant + nil + ( expression-list ) + term . identifier + term -> term + term ( expression-listopt ) + term [ expression ] + term [ expression : expression ] + term [ expression : ] + term ++ + term -- +
+
. + -> + () [] ++ -- +
+The first five kinds of term are constants and identifiers. +Constants have a type indicated by their syntax. +An identifier used in an expression is often a previously declared +data object with a particular data type; when used as a term +in an expression +it denotes the value stored in the object, and the term has +the declared object's type. +Sometimes, as discussed below, identifiers used in expressions +are type names, function names, or module identifiers. +
++A comma-separated list of expressions enclosed in parentheses +is a term. +If a single expression is present in the list, +the type and value are those of the expression; +the parentheses affect only the binding +of operators in the expression of which the term +is a part. +If there is more than one expression in the list, +the value is a tuple. +The member types +and values are taken from those of the expressions. +
++A term of the form +
+ term . identifier +
+
+A term of the form +
+ term -> term +
+
+An example using an abridged version of an example above: given +
Linear: module {
+ setflags: fn(flag: int);
+ TRUNCATE: con 1;
+ Vector: adt {
+ make: fn(v: array of real): Vector;
+ v: array of real;
+ };
+ };
+lin := load Linear "/dis/linear.dis"; + a: array of real; + + v1: lin->Vector; + v2: Linear->Vector; + lin->setflags(Linear->TRUNCATE); + v1 = lin->(Linear->Vector).make(a); + v1 = lin->v1.make(a); + v1 = lin->v1.add(v1); + v1.v = nil; +
+When calling a function associated with an +adt +of another module, it is necessary to identify +both the module and the +adt +as well as the function. +The two calls to the +make +function illustrate two ways of doing this. +In the first, +
v1 = lin->(Linear->Vector).make(a); +
v1 = lin->v1.make(a); +
v1 = lin->Vector.make(a); # Wrong + v1 = lin->Linear->Vector.make(a); # Wrong +
+Using +import +makes the code less verbose: +
lin := load Linear "/usr/dmr/limbo/linear.dis"; + Vector, TRUNCATE, setflags: import lin; + a: array of real; + + v1: Vector; + v2: Vector; + setflags(TRUNCATE); + v1 = Vector.make(a); + v1 = v1.make(a); + v1 = v1.add(v1); + v1.v = nil; +
+The interpretation of an expression in the form +
+ term ( expression-listopt ) +
+
+A plain identifier as the +term +names a function defined +in the current module or imported into it. +A term qualified by using the selection operator +. +specifies a function member of an +adt; +a term using +-> +specifies a function defined in another module. +
++Function calls in Limbo +create a copy of each argument of value type, +and the execution of a function cannot +affect the value of the corresponding actual argument. +For arguments of reference type, +execution of the function may affect the value of the object +to which the reference refers, although it cannot +change the argument itself. +The actual arguments to a function are evaluated +in an unspecified order, +although any side effects caused by argument evaluation +occur before the function is called. +
++Function calls may be directly or indirectly recursive; +objects declared within each function are distinct from +those in their dynamic predecessors. +
++Functions (§4.3, §7) may either return a value +of a specified type, or return no value. +If a function returns a value, it has the specified type. +A call to a function that returns no value may appear only as the +sole expression in a statement (§9.1). +
++In a term of the form +
+ term [ expression ] +
+
+It is erroneous to refer to a nonexisting +part of an array or string. +(A single exception to this rule, discussed in §8.4.1 below, +allows extending a string by assigning a character at its end.) +
++In a term of the form +
+ term [ expression : expression ] +
+
+Thus, for both arrays and strings, the number of elements in +a[e1:e2] +is equal to +e2-e1. +
++A slice of the form +a[e:] +means +a[e:len a]. +
++When a string slice is assigned to another string or passed as an +argument, a copy of its value is made. +
++A slice of an array produces a reference to the designated subarray; +a change to an element of either the original array or +the slice is reflected in the other. +
++In general, slice expressions cannot be the subject of +assignments. +However, as a special case, an array slice expression of the +form +a[e1:] +may be assigned to. +This is discussed in §8.4.1. +
++The following example shows how slices +can be used to accomplish what would +need to be done with pointer arithmetic in C: +
fd := sys->open( ... );
+ want := 1024;
+ buf := array[want] of byte;
+ b := buf[0:];
+ while (want>0) {
+ got := sys->read(fd, b, want);
+ if (got<=0)
+ break;
+ b = b[got:];
+ want -= got;
+ }
++A term of the form +
+ term ++ +
+
+The term +
+ term -- +
+
+
++Monadic expressions are expressions with +monadic operators, together with a few more +specialized notations: +
+monadic-expression: + term + monadic-operator monadic-expression + array [ expression ] of data-type + array [ expressionopt ] of { init-list } + list of { expression-list } + chan of data-type + data-type monadic-expression + +monadic-operator: one of + + - ! ~ ref * ++ -- <- hd tl len +
+
+The +- +operator produces the negative of its operand, which +must have an arithmetic type. +The type of the result is the same as the type of +its operand. +
++The ++ +operator has no effect; it is supplied only for +symmetry. +However, its argument must have an arithmetic type +and the type of the result is the same. +
++The +! +operator yields the +int +value 1 if its operand +has the value 0, and yields 0 otherwise. +The operand must have type +int. +
++The +~ +operator yields the 1's complement of its +operand, which must have type +int +or +byte. +The type of the result is the same as that of its operand. +
++If +e +is an expression of an +adt +type, then +ref +e +is an expression of +ref +adt +type whose value refers to (points to) an anonymous object with value +e. +The +ref +operator differs from the unary +& +operator of C; it makes a new object and returns a reference +to it, rather than generating a reference to an existing object. +
++If +e +is an expression of type +ref +adt, +then +* +e +is the value +of the +adt +itself. +The value of +e +must not be +nil. +
++For example, in +
Point: adt { ... };
+ p: Point;
+ pp: ref Point;
+ p = Point(1, 2);
+ pp = ref p; # pp is a new Point; *pp has value (1, 2)
+ p = Point(3, 4); # This makes *pp differ from p
+ *pp = Point(4, 5); # This does not affect p
++A monadic expression of the form +
+ ++ monadic-expression +
+
+The term +
+ -- monadic-expression +
+
+
++The operand of the +hd +operator must be a non-empty list. +The value is the first member of the list +and has that member's type. +
++The operand of the +tl +operator must be a non-empty list. +The value is the tail of the list, +that is, the part of the list after its +first member. +The tail of a list with one member is +nil. +
++The operand of the +len +operator is a string, an array, or a list. +The value is an +int +giving the number of elements currently in the item. +
++The operand of the +tagof +operator is a monadic expression of type +ref +adt +that refers to a +pick +adt. +or the type name of a +pick +adt +or one of its variants. +The value is an +int +giving a unique value for each of the variants and for the +pick +adt +type itself. +
++The operand of the communication operator +<- +has type +chan +of +sometype. +The value of the expression +is the first unread object previously sent over that +channel, and has the type associated with the channel. +If the channel is empty, the program delays +until something is sent. +
++As a special case, the operand of +<- +may have type +array +of +chan +of +sometype. +In this case, all of the channels in the array are tested; +one is fairly selected from those that have data. +The expression yields a tuple of type +(int, +sometype +); +its first member gives the index of the channel from +which data was read, and its second member is the +value read from the channel. +If no member of the array has data ready, the expression delays. +
++Communication channels are treated more fully in §9.8 and +§9.13 below with the discussion of the +alt +and +spawn +statements. +
++In the expressions +
+ array [ expression ] of data-type + array [ expressionopt ] of { init-list ,opt } +
+
+init-list: + element + init-list , element + +element: + expression + expression => expression + * => expression +
+
+If an element of the form +* +=>e2 +is present, all members of the array not otherwise +initialized are set to the value +e2. +The expression +e2 +is evaluated for each subscript position, +but in an undefined order. +For example, +
arr := array[3] of { * => array[3] of { * => 1 } };
++If the expression giving the size of the array is omitted, its size +is taken from the largest subscript of +a member explicitly initialized. +It is erroneous to initialize a member twice. +
++The value of an expression +
+ list of { expression-list } +
+
+The value of +
+ chan of data-type +
+
ch: chan of int; # just declares, sets ch to nil + . . . + ch = chan of int; # creates the channel and assigns it +
+An expression of the form +
+ data-type monadic-expression +
+
+In arithmetic casts, the named type must be one of +byte, +int, +big, +or +real, +and the monadic-expression must have arithmetic type. +For example, +
byte 10 +
+Here the named data type is +string. +In a first form, the monadic expression has arithmetic type +(byte, +int, +big, +or +real) +and the value is a string containing the decimal representation +of the value, which may be either positive or negative. +A +real +operand is converted as if by format +%g, +and if the result is converted back to +real, +the original value will be recovered exactly. +
++In a second form, +the monadic expression has type +array +of +byte. +The value is a new string containing the Unicode characters +obtained by interpreting the bytes in the array as a UTF-8 representation +of that string. +(UTF-8 is a representation of 16-bit Unicode characters as one, +two, or three bytes.) +The result of the conversion is undefined if the byte array +ends within a multi-byte UTF-8 sequence. +
++In a first form, the monadic expression is a string, +and the named type is an arithmetic type. +The value is obtained by converting the string to +that type. Initial white space is ignored; after a possible +sign, conversion +ceases at the first character not part of a number. +
++In a second form, the named type is +array +of +byte +and the monadic-expression is a string. +The value is a new array of bytes containing the UTF-8 representation +of the Unicode characters in the string. +For example, +
s := "Ångström"; + a := array of byte s; + s = string a; +
+Here the named type is that of an +adt +or +ref +adt, +and the monadic expression is a comma-separated list of expressions +within parentheses. +The value of the expression is an instance of an +adt +of the named type whose data members are initialized with +the members of the list, or whose single data member +is initialized with the parenthesized expression. +In case the type is +ref +adt, +the value is a reference to the new +instance of the +adt. +
++The expressions in the list, read in order, correspond with the data +members of the +adt +read in order; their types and number must agree. +Placement of any function members of the +adt +is ignored. +For example, +
Point: adt {
+ x: int;
+ eq: fn (p: Point): int;
+ y: int;
+ };
+ . . .
+ p: Point;
+ p = Point(1, 2);
+p := Point(1, 2); +
+Binary expressions are either monadic expressions, +or have two operands and an infix operator; +the syntax is +
+binary-expression: + monadic-expression + binary-expression binary-operator binary-expression + +binary-operator: one of + * / % + - << >> < > <= >= == != & ^ | :: && || +
+
* / % + + - + << >> + < > <= >= + == != + & + ^ + | + :: + && + || +
+The +*, +/, +and +% +operators respectively accomplish multiplication, division, and remainder. +The operands must be of identical arithmetic type, and the result has that +same type. +The remainder operator does not apply to type +real. +If overflow or division by 0 occurs, the result is undefined. +The absolute value of +a%b +is less than the absolute value of +b; +(a/b)*b + a%b +is always equal to +a; +and +a%b +is non-negative if +a +and +b +are. +
++The ++ +and +- +operators respectively accomplish addition and subtraction +of arithmetic operands of identical type; +the result has the same type. +The behavior on overflow or underflow is undefined. +The ++ +operator may also be applied to strings; +the result is a string that is the concatenation of the operands. +
++The shift operators are +<< +and +>>. +The left operand may be +big, +int, +or +byte; +the right operand is +int. +The type of the value is the same as its left operand. +The value of the right operand must be non-negative +and smaller than the number of bits in the left operand. +For the left-shift operator +<<, +the fill bits are 0; +for the right-shift operator +>>, +the fill bits are a copy of the sign for the +int +case, and 0 for the +byte +case. +
++The relational operators are +< +(less than), +> +(greater than), +<= +(less than or equal), +>= +(greater than or equal), +== +(equal to), +!= +(not equal to). +The first four operators, which generate orderings, +apply only to arithmetic types +and to strings; the types of their operands +must be identical, except that a string may be +compared to +nil. +Comparison on strings is lexicographic over the +Unicode character set. +
++The equality operators +== +and +!= +accept operands of arithmetic, string, and reference types. +In general, the operands must have identical type, +but reference types and strings may be compared for identity with +nil. +Equality for reference types occurs when the operands +refer to the same object, or when both are +nil. +An uninitialized string, or one set to +nil, +is identical to the empty string denoted +"" +for all the relational operators. +
++The value of any comparison is the +int +value 1 if the stated +relation is true, 0 if it is false. +
++The logical operators +& +(and), +^ +(exclusive or) and +| +(inclusive or) +require operands of the same type, +which must be +byte, +int, +or +big. +The result has the same type and its +value is obtained by applying the operation +bitwise. +
++The concatenation operator +:: +takes a object of any data type +as its left operand and a list as its right operand. +The list's underlying type must be the same as +the type of the left operand. +The result is a new list with the left operand +tacked onto the front: +
hd (a :: l) +
+The logical +and +operator +&& +first evaluates its left operand. +If the result is zero, then the value of the +whole expression is the +int +value 0. +Otherwise the right operand is evaluated; if +the result is zero, the value of the whole +expression is again 0; otherwise it is 1. +The operands must have the same arithmetic type. +
++The logical +or +operator +|| +first evaluates its left operand. +If the result is non-zero, then the value of the +whole expression is the +int +value 1. +Otherwise the right operand is evaluated; if +the result is non-zero, the value of the whole +expression is again 1; otherwise it is 0. +The operands must have the same arithmetic type. +
++The remaining syntax for expressions is +
+expression: + binary-expression + lvalue-expression assignment-operator expression + ( lvalue-expression-list ) = expression + send-expression + declare-expression + load-expression + +assignment-operator: one of + = &= |= ^= <<= >>= += -= *= /= %= +
+
+lvalue-expression: + identifier + nil + term [ expression ] + term [ expression : ] + term . identifier + ( lvalue-expression-list ) + * monadic-expression + +lvalue-expression-list: + lvalue + lvalue-expression-list , lvalue +
+
+In general, the types of the left and right operands +must be the same; this type must be a data type. +The value of an assignment is its new left operand. +All the assignment operators associate right-to-left. +
++In the ordinary assignment with +=, +the value of the right side is assigned to the object +on the left. +For simple assignment only, the left operand may be a +parenthesized list of lvalues and the right operand +either a tuple or an +adt +whose data members correspond +in number and type to the lvalues in the list. +The members of the tuple, or +the data members of the +adt, +are assigned in sequence to +lvalues in the list. +For example, +
p: Point; + x, y: int; + (x, y) = p; +
+If the left operand of a simple assignment is an +adt +and the right side is a tuple, then the assignment +assigns the members of the tuple to the +adt +data members; these must correspond in number and type +with the members of the tuple. +
++The constant +nil +may be assigned to an lvalue of any reference type. +This lvalue will compare equal to +nil +until it is subsequently reassigned. +In the Inferno implementation of Limbo, such an assignment also +triggers the removal of the object referred to unless other references +to it remain. +
++The left operand of an assignment may be the constant +nil +to indicate that a value is discarded. +This applies in particular to any of the lvalues in +a tuple appearing on the left; to extend the examples above, +
(x, nil) = p; +
+A special consideration applies to +strings. +If an +int +containing a Unicode character is assigned to a subscripted +string, the subscript +is normally required to lie within the string. +As a special case, the subscript's value may be equal to +the length of the string (that is, just beyond its end); +in this case, the character is appended to +the string, and the string's length increases by 1. +
++A final special case applies to array slices in the form +e1[e2:]. +Such expressions may lie on the left of +=. +The right side must be an array of the same type as +e1, +and its length must be less than or equal to +(len e1)-e2. +In this case, the +elements in the array on the right replace the elements of +e1 +starting at position +e2. +The length of the array is unchanged. +
++A compound assignment with +op= +is interpreted in terms of the plain assignment; +
e1 op= e2; +
e1 = (e1) op (e2); +
+A +send-expression +takes the form +
+send-expression: + lvalue-expression <- = expression +
+
e1 <- = e2 +
+A +declare-expression +is an assignment that also declares identifiers on its left: +
+declare-expression: + lvalue-expression := expression +
+
+The value and type of a declare-expression are the same as those of the expression. +
++A +load-expression +has the form +
+load-expression: + load identifier expression +
+
+Execution of +load +brings the file containing the module into local memory and dynamically type-checks +its interface: the run-time system ascertains that +the declarations exported by the module are compatible +with the module declaration visible in the scope of the +load +operator (see §11.2). +In the scope of a module declaration, the types and constants +exported by the module may be referred to without a handle, but +the functions and data exported by the module +(directly at its top level, or within its +adt) +may be called only using a valid +handle acquired by the +load +operator. +
++The value of +load +is +nil +if the attempt to load fails, either because the file containing +the module can not be found, or because the found module does not +export the specified interface. +
++Each evaluation of +load +creates a separate instance of the specified module; +it does not share data with any other instance. +
++In several places a constant expression is required. +Such an expression contains operands that are +identifiers previously declared with +con, +or +int, +big, +real, +or +string +constants. +These may be connected by any of the following operators: +
+ - * / % & | ^ + == < > <= >= != << >> + && || + ~ ! +
+Expressions in Limbo are not reordered by the compiler; +values are computed in accordance with the parse of the expression. +However there is no guarantee of temporal evaluation order for expressions +with side effects, except in the following circumstances: +function arguments are fully evaluated before the function +is called; the logical operators +&& +and +|| +have fully defined order of evaluation, as explained above. +All side effects from an expression in one statement are +completed before the next statement is begun. +
++In an expression containing a constant subexpression (in the +sense of §8.5), the constant subexpression is evaluated at +compile-time with all exceptions ignored. +
++Underflow, overflow, and zero-divide conditions during integer +arithmetic produce undefined results. +
++The +real +arithmetic of Limbo is all performed in IEEE double precision, +although denormalized numbers may not be supported. +By default, +invalid operations, zero-divide, overflow, and underflow +during real arithmetic are fatal; inexact-result is quiet. +The default rounding mode is round-to-nearest-even. +A set of routines in the +Math +library module permits independent control of these modes within each thread. +
++The executable code within a function definition consists +of a sequence of statements and declarations. +As discussed in the Scope section §11 below, +declarations become effective at the place they appear. +Statements are executed in sequence except as discussed below. +In particular, the optional labels on some of the statements are used with +break +and +continue +to exit from or re-execute the labeled statement. +
+statements: + (empty) + statements declaration + statements statement + +statement: + expression ; + ; + { statements } + if ( expression ) statement + if ( expression ) statement else statement + labelopt while ( expressionopt ) statement + labelopt do statement while ( expressionopt ) ; + labelopt for ( expressionopt ; expressionopt ; expressionopt ) statement + labelopt case expression { qual-statement-sequence } + labelopt alt { qual-statement-sequence } + labelopt pick identifier := expression { pqual-statement-sequence } + break identifieropt ; + continue identifieropt ; + return expressionopt ; + spawn term ( expression-listopt ) ; + exit ; +
+
+label: + identifier : +
+
+Expression statements consist of an expression followed by +a semicolon: +
+ expression ; +
+
+The null statement consists of a lone semicolon. +It is most useful for supplying an empty body +to a looping statement with internal side effects. +
++Blocks are +statements +enclosed in +{} +characters. +
+ { statements } +
+
+The conditional statement takes two forms: +
+ if ( expression ) statement + if ( expression ) statement else statement +
+
+The simple looping statements are +
+ labelopt while ( expressionopt ) statement + labelopt do statement while ( expressionopt ) ; +
+
+The +for +statement has the form +
+ labelopt for ( expression-1opt ; expression-2opt ; expression-3opt ) statement +
+
+ expression-1 ; + while ( expression-2 ) { + statement + expression-3 ; + } +
+
+The +case +statement transfers control to one of several places +depending on the value of an expression: +
+ labelopt case expression { qual-statement-sequence } +
+
+qual-statement-sequence: + qual-list => + qual-statement-sequence qual-list => + qual-statement-sequence statement + qual-statement-sequence declaration + +qual-list: + qualifier + qual-list or qualifier + +qualifier: + expression + expression to expression + * +
+
+The +case +statement is executed by comparing +the expression at its head with the constants +in the qualifiers. +The test is for equality in the case +of simple constant qualifiers; +in range qualifiers, the test determines +whether the expression is greater than or +equal to the first constant and less than +or equal to the second. +
++None of the ranges or constants may overlap. +If no qualifier is selected and +there is a +* +qualifier, +then that qualifier is selected. +
++Once a qualifier is selected, control passes +to the set of statements headed by that +qualifier. +When control reaches the end of that set +of statements, control passes to the end +of the +case +statement. +If no qualifier is selected, the +case +statement is skipped. +
++Each qualifier and the statements following it +up to the next qualifier together form a separate +scope, like a block; declarations within this scope +disappear at the next qualifier (or at the end of +the statement.) +
++As an example, this fragment separates small numbers +by the initial letter of their spelling: +
case i {
+ 1 or 8 =>
+ sys->print("Begins with a vowel\n)";
+ 0 or 2 to 7 or 9 =>
+ sys->print("Begins with a consonant\n");
+ * =>
+ sys->print("Sorry, didn't understand\n");
+ }
++The +alt +statement transfers control to one of several groups +of statements depending on the readiness of communication +channels. +Its syntax resembles that of +case: +
+ labelopt alt { qual-statement-sequence } +
+
outchan := chan of string;
+ inchan := chan of int;
+ alt {
+ i := <-inchan =>
+ sys->print("Received %d\n", i);
+ outchan <- = "message" =>
+ sys->print("Sent the message\n");
+ }
++If a qualifier of the form +* +is present, then the statement does not block; +if no channel is ready the statements associated with +* +are executed. +
++If two communication operators are present +in the same qualifier expression, only the leftmost one is +tested by +alt. +If two or more +alt +statements referring to the same receive (or send) +channel are executed in different +threads, the requests are queued; +when the channel becomes unblocked, the thread +that executed +alt +first is activated. +
++As with +case, +each qualifier and the statements following it +up to the next qualifier together form a separate +scope, like a block; declarations within this scope +disappear at the next qualifier (or at the end of +the statement.) +Thus, in the example above, the scope of +i +in the arm +
i := <-inchan =>
+ sys->print("Received %d\n", i);
++As mentioned in the specification +of the channel receive operator +<- +in §8.2.8, that operator can take an array of channels as an argument. +This notation serves as a kind of simplified +alt +in which all the channels have the same type +and are treated similarly. +In this variant, +the value of the communication expression is a tuple +containing the index of the +channel over which a communication was received and +the value received. +For example, in +
a: array [2] of chan of string; + a[0] = chan of string; + a[1] = chan of string; + . . . + (i, s) := <- a; + # s has now has the string from channel a[i] +
+During execution of an +alt, +the expressions in the qualifiers are evaluated in an undefined +order, and in particular subexpressions may be evaluated before +the channels are tested for readiness. +Therefore qualifying expressions should not invoke side effects, +and should avoid subparts that might delay execution. +For example, in the qualifiers +
ch <- = getchar() => # Bad idea + ich <- = next++ => # Bad idea +
+The +pick +statement transfers control to one of several groups of statements +depending upon the resulting variant type of a +pick +adt +expression. The syntax resembles that of +case: +
+ labelopt pick identifier := expression { pqual-statement-sequence } +
+
+pqual-statement-sequence: + pqual-list => + pqual-statement-sequence pqual-list => + pqual-statement-sequence statement + pqual-statement-sequence declaration + +pqual-list: + pqualifier + pqual-list or pqualifier + +pqualifier: + identifier + * +
+
+Once a qualifier is selected, control passes +to the set of statements headed by that qualifier. +When control reaches the end of that set of statements, +control passes to the end of the +pick +statement. +If no qualifier is selected, the +pick +statement is skipped. +
++Each qualifier and the statements following it +up to the next qualifier together form a separate +scope, like a block; declarations within this scope +disappear at the next qualifier (or at the end of +the statement.) +
++The +identifier +and +expression +given in the +pick +statement are used to bind a new variable to a +pick +adt +reference expression, and within the statements associated with the +selected qualifier the variable can be used as if it were of the corresponding +variant type. +
++As an example, given a +pick +adt +of the following form: +
Constant: adt {
+ name: string;
+ pick {
+ Str or Pstring =>
+ s: string;
+ Real =>
+ r: real;
+ }
+ };
+ printconst(c: ref Constant)
+ {
+ sys->print("%s: ", c.name);
+ pick x := c {
+ Str =>
+ sys->print("%s\n", x.s);
+ Pstring =>
+ sys->print("[%s]\n", x.s);
+ Real =>
+ sys->print("%f\n", x.r);
+ };
+ }
++The +break +statement +
+ break identifieropt ; +
+
+The +continue +statement +
+ continue identifieropt ; +
+
+Similarly, execution of +continue +with an identifier transfers control to the end of the enclosing +while, +do, +or +for +labeled with the same identifier. +
++The +return +statement, +
+ return expressionopt ; +
+
f, g: fn(a: int);
+ f(a: int) {
+ . . .
+ return g(a+1);
+ }
+ f(a: int) {
+ . . .
+ g(a+1);
+ return;
+ }
++Running off the end of a function is equivalent to +return +with no expression. +
++The +spawn +statement creates a new thread of control. +It has the form +
+ spawn term ( expression-listopt ) ; +
+
+The +exit +statement +
+ exit ; +
+
+As discussed above, modules present +constants, functions, and types +in their interface. +Their names may be the same as names +in other modules or of local objects or types within +a module that uses another. +Name clashes are avoided because references +to the entities presented by a module are +qualified by the module type name or an object +of that module type. +
++For example, +after the module and variable declarations +
M: module {
+ One: con 1;
+ Thing: adt {
+ t: int;
+ f: fn();
+ };
+ g: fn();
+ };
+ m: M;
+th1: M->Thing; + th2: m->Thing; +
m->g(); + m->th1.f(); +
+The +import +declaration +
+ identifier-list : import identifier ; +
+
One, Thing: import M; +
th: Thing; +
g, Thing: import m; +
g(); +
m->g(); +
th: Thing; + th.f(); +
th: M.Thing; + m->th.f(); +
implement Mod;
+ . . .
+ Mod: module {
+ . . .
+ };
++The scope of an identifier is the lexical range of +a program throughout which the identifier means a particular +type of, or instance of, an object. +The same identifier may be associated with several +different objects in different parts of the same program. +
++The names of members of an +adt +occupy a separate, nonconflicting space from other identifiers; +they are declared in a syntactically distinct position, +and are always used in a distinguishable way, namely +after the +. +selection operator. +Although the same scope rules apply to +adt +members as to other identifiers, their names may +coincide with other entities in the same scope. +
++Similarly, the names of constants, functions, and +adt +appearing +within a +module +declaration are ordinarily qualified either with +the name of the module or with a module variable +using the +-> +notation. +As discussed above, the +import +declaration lifts these names into the current scope. +
++Identifiers declared in a top-declaration +(§5) have scope that lasts from the +declaration throughout the remainder of the +file in which it occurs, unless it is overridden +by a redeclaration of that name within an inner +scope. +Each function definition, and each block +within a function, +introduces a new scope. +A name declared within the block or function +(including a formal argument name of a function) +has a scope that begins +at the completion of its declaration and lasts until +the end of the block or function. +If an already-declared identifier is redeclared within +such an inner scope, the declaration previously in +force is used in any initialization expression +that is part of the new declaration. +
++As discussed above, within +case +alt +and +pick, +each qualifier +and the statements following it form an inner +scope just like a block. +
++The scope of a label is restricted to the +labeled statement, +and label names may coincide with those of other +entities in the same scope. +
++In general, names must be declared before they are used. +
++The first exception to this rule is that a +function local to a module need not have a +declaration at all; it is sufficient to give +its definition, and that definition may appear anywhere +in the module. +
++The general rule implies that no +adt +may contain, as a member, an +adt +not previously declared (including an instance of itself). +A second exception to this rule applies to +ref +adt +types. +An +adt +may contain a member whose type is a +ref +to itself, or to another +adt +even if the second +adt +has not yet been declared. +Unless a special notation is used, such +references are restricted: +all mutual or self references among +adt +are checked statically throughout all the +adt +visible in a module to determine which +members refer to other +adt. +Any member of an +adt +of +ref +adt +type that refers directly, or indirectly through a chain of references, +back to its own underlying type may not be assigned to individually; +it can gain a value only by an assignment to the +adt +as a whole. +For example, in +
Tree: adt {
+ l: ref Tree;
+ r: ref Tree;
+ t: ref Ntree;
+ };
+ Ntree: adt {
+ t: ref Tree;
+ };
+
+ t1 := Tree(nil, nil, nil); # OK
+ t2 := Tree(ref t1, ref t1, nil); # OK
+ t1 = Tree(ref t1, ref t2, nil); # OK
+ t1.l = ... ; # not OK
+
+ nt := ref Ntree(nil); # OK
+ nt.t = ... # not OK
++These restrictions suffice +to prevent the creation of circular data structures. +Limbo implementations guarantee to +destroy all data objects not involved in such circularity +immediately after they become non-referenced by active +tasks, whether because +their names go out of scope or because they are assigned new values. +This property has visible effect because certain system resources, +like windows and file descriptors, can be seen outside the program. +In particular, if a reference to such a resource is held only within an +adt, +then that resource too is destroyed when the +adt +is. +
++The default rules are burdensome because they impede the construction even +of harmless structures like trees. +Therefore an escape is provided: using the word +cyclic +before the type in an +adt +member removes the circular-reference restriction for that member. +For example, +
Tree: adt {
+ l: cyclic ref Tree;
+ r: cyclic ref Tree;
+ t: ref Ntree;
+ };
+ Ntree: adt {
+ t: cyclic ref Tree;
+ };
+
+ t1 := Tree(nil, nil, nil); # OK
+ t2 := Tree(ref t1, ref t1, nil); # OK
+ t1 = Tree(ref t1, ref t2, nil); # OK
+ t1.l = ... ; # OK now
+
+ nt := ref Ntree(nil); # OK
+ nt.t = ... # OK now
++In an assignment and in passing an actual argument to a function, +the types of the target and the expression being assigned or +passed must be equal (with certain exceptions, e.g. assignment of +nil +to a reference type). +When a function is defined, its type must be equal to the type +of a function with the same name if one is in scope. +Type equality is determined as follows. +
++Two basic types are equal if and only if they are identical. +
++Two tuple types are equal if and only if they are composed +of equal types in the same order. +
++Two array types are equal if and only if they are arrays +of equal types. +The size of an array is not part of its type. +
++Two list types are equal if and only if they are composed +of equal types. +
++Two channel types are equal if and only if they transmit +equal types. +
++Two +adt +types are equal if and only if their data members +have the same names and correspondingly +equal types, including any +cyclic +attribute. +The order of member declaration is insignificant, and +constant and function members of an +adt +do not enter into the comparison, +nor does the name of the +adt +type itself. +In particular, with the declarations +
A: adt { x: ref B; };
+ B: adt { x: ref A; };
++Two +ref +adt +types are equal if and only if they are references to equal +adt +types. +
++Two module types are equal if and only if their data and function members +have the same names and correspondingly equal types; the order +of their mention is insignificant. +Constant members and type members do not enter into the comparison. +
++Two function types are equal if and only if their return +values have the same type +and their argument lists have correspondingly equal types. +Any +self +attributes given to arguments much match. +Names given to arguments do not enter into the comparison. +
++A type name has the same type as the type from +which it was constructed. +
++When a module is loaded, the module stored +in the file system must have a type that is +compatible +with the type mentioned in the +load +expression. +The type of the stored module +type is compatible with the mentioned type if and only if +all data members of the two types are equal in name and type, +and all +adt +or functions actually mentioned by the program executing +load +have names and types equal to corresponding members of +the stored module. +
++Because Limbo was designed for the Inferno environment, several +of these examples consist of simplified versions of already simple +Inferno applications in a prototype Inferno implementation. +Some appreciation for the resources available in this environment +should become evident, but its full description is available +elsewhere; +the discussion here will focus on language features. +However, several of the programs use facilities +from the module +Sys, +which provides an interface to a file system and its methods +resembling those of Unix or Plan 9, +as well as other useful library facilities. +
++Some of the programs are annotated with line numbers; +they are there only for descriptive purposes. +
++This version of a shell program reads from a keyboard and +executes `commands' typed by the user. +Its own interface has the type of a +Command +module, and that is the type of the things it executes. +In particular, it can call modules like the +hello +example at the beginning of the paper. +
1 implement Command;
+
+2 include "sys.m";
+3 include "draw.m";
+
+4 sys: Sys;
+5 stdin: ref Sys->FD;
+
+6 Command: module
+7 {
+8 init: fn(nil: ref Draw->Context, nil: list of string);
+9 };
+10 init(ctx: ref Draw->Context, nil: list of string)
+11 {
+12
+13
+14 buf := array[256] of byte;
+
+15 sys = load Sys Sys->PATH;
+16 stdin = sys->fildes(0);
+
+17 for(;;) {
+18 sys->print("$ ");
+19 n := sys->read(stdin, buf, len buf);
+20 if(n <= 0)
+21 break;
+22 (nw, arg) :=
+ sys->tokenize(string buf[0:n], " \t\n");
+23 if(nw != 0)
+24 exec(ctx, arg);
+25 }
+26 }
++Local variables are declared on lines 12-14; line 15 +loads the +Sys +module and stores a handle for it in the variable +sys. +Line 16 creates an +FD +for the standard input by calling the +fildes +function of the +Sys +module using the +-> +operator; the notation +modhandle->func(...) +specifies a call to the function named +func +in the module currently referred to by +modhandle. +(In general there can be several modules of the same type and name +active, and there can also be unrelated modules containing identically +named functions. +The +import +declaration, described in §6.6 above, can be used to abbreviate +the references when names do not clash.) +
++The loop on lines 17-25 prints a prompt (line 18), reads a line from +the standard input (line 19), parses it into tokens (line 22), and +executes the command. +
++The function call +sys->tokenize +is worth discussing as an example of style. +It takes two strings as arguments. +The characters in the second string are interpreted as separators +of tokens in the first string. +It returns a tuple whose first member is the number of +tokens found, and whose second is a list of strings +containing the tokens found: its declaration is +
tokenize: fn (s: string, sep: string): (int, list of string); +
+The +sys->read +routine gathers an array of bytes into +buf. +Thus the expression for the first argument of +sys->tokenize +converts this array to a string by slicing the +array with +[0:n], +using the actual number of bytes +gathered by the +read, +and using a cast. +
++At lines 23-24, if there were any words found, +exec +is called: +
27 exec(ctx: ref Draw->Context, args: list of string)
+28 {
+29 c: Command;
+30 cmd, file: string;
+
+31 cmd = hd args;
+
+32 file = cmd + ".dis";
+33 c = load Command file;
+34 if(c == nil)
+35 c = load Command "/dis/"+file;
+
+36 if(c == nil) {
+37 sys->print("%s: not found\n", cmd);
+38 return;
+39 }
+40 c->init(ctx, args);
+41 }
++If either attempt to get a handle to the named module +succeeds, +c +will contain a valid handle to it; line 40 calls its +init +function, passing it the whole argument list. +When it returns, the +exec +function returns, and the main loop resumes. +
++This example shows two instances of a module +for interfacing to a TV remote control; one +is for the real remote, which in this case +is connected to a serial port on a set-top +box, and the other is simulated for testing +programs running on a regular operating +system. +The techniques of special interest are the +dynamic use of modules and the communication +using a channel. +
++The module is used by creating a channel and passing +it to the module's +init +function, +which returns a success/error indicator and starts an +asynchronous process to read the remote control. +The user of the module executes a receive +on the channel whenever it wishes to accept +a button-push. +
++The (abridged) module declaration is +
Ir: module
+{
+ # Codes buttons on IR remote control
+ Zero: con 0;
+ One: con 1;
+ . . .
+ Mute: con 23;
+ Error: con 9999;
+
+ init: fn(chan of int): int;
+ PATH: con "/dis/ir.dis";
+ SIMPATH: con "/dis/irsim.h";
+};
+implement Ir;
+
+include "ir.m";
+include "sys.m";
+FD, Dir: import Sys;
+
+sys: Sys;
+
+init(keys: chan of int): int
+{
+ cfd, dfd: ref FD;
+
+ sys = load Sys Sys->PATH;
+
+ cfd = sys->open("/dev/eia1ctl", sys->OWRITE);
+ if(cfd == nil)
+ return -1;
+ sys->fprint(cfd, "b9600");
+
+ dfd = sys->open("/dev/eia1", sys->OREAD);
+ cfd = nil;
+
+ spawn reader(keys, dfd);
+ return 0;
+}
+reader(keys: chan of int, dfd: ref FD)
+{
+ n, ta, tb: int;
+ dir: Dir;
+ b1:= array[1] of byte;
+ b2:= array[1] of byte;
+
+ # find the number of bytes already
+ # queued and flush that many
+ (n, dir) = sys->fstat(dfd);
+ if(n >= 0 && dir.length > 0) {
+ while(dir.length) {
+ n = sys->read(dfd,
+ array[dir.length] of byte,
+ dir.length);
+ if(n < 0)
+ break;
+ dir.length -= n;
+ }
+ }
+loop: for(;;) {
+ n = sys->read(dfd, b1, len b1);
+ if(n <= 0)
+ break;
+ ta = sys->millisec();
+ # Button pushes are pairs of characters
+ # that arrive closer together than
+ # 200 ms. Longer than that is likely
+ # to be noise.
+ for(;;) {
+ n = sys->read(dfd, b2, 1);
+ if(n <= 0)
+ break loop;
+ tb = sys->millisec();
+ if(tb - ta <= 200)
+ break;
+ ta = tb;
+ b1[0] = b2[0];
+ }
+ # map the character pair; the significant
+ # bits are the lowest 5.
+ case ((int b1[0]&16r1f)<<5) | (int b2[0]&16r1f) {
+ 975 => n = Ir->Zero;
+ 479 => n = Ir->One;
+ . . .
+ 791 => n = Ir->Mute;
+ * => n = Ir->Error;
+ }
+ # found a button-push; send the value
+ keys <-= n;
+ }
+ keys <-= Ir->Error;
+}
++Here is another implementation of the same interface. +Its +init +function performs the same kind of initialization +as the other version, but using the operating system's +keyboard files +/dev/cons +and +/dev/consctl. +In the Inferno environment, operations corresponding to the Unix +`stty' primitive are accomplished by writing messages to +a control file associated with the file that handles the data. +
implement Ir;
+
+include "ir.m";
+include "sys.m";
+FD: import Sys;
+
+sys: Sys;
+cctlfd: ref FD;
+
+init(keys: chan of int): int
+{
+ dfd: ref FD;
+
+ sys = load Sys Sys->PATH;
+
+ cctlfd = sys->open("/dev/consctl", sys->OWRITE);
+ if(cctlfd == nil)
+ return -1;
+ sys->write(cctlfd, array of byte "rawon", 5);
+
+ dfd = sys->open("/dev/cons", sys->OREAD);
+ if(dfd == nil)
+ return -1;
+
+ spawn reader(keys, dfd);
+ return 0;
+}
++The reader function for this module has the same structure as the first +example, but doesn't have to worry about a noisy infrared detector: +
reader(keys: chan of int, dfd: ref FD)
+{
+ n: int;
+ b:= array[1] of byte;
+
+ for(;;) {
+ n = sys->read(dfd, b, 1);
+ if(n != 1)
+ break;
+ case int b[0] {
+ '0' => n = Ir->Zero;
+ '1' => n = Ir->One;
+ . . .
+ 16r7f => n = Ir->Mute;
+ * => n = Ir->Error;
+ }
+ keys <-= n;
+ }
+ keys <-= Ir->Error;
+}
+implement Irtest;
+
+include "sys.m";
+include "draw.m";
+FD: import Sys;
+include "ir.m";
+
+Irtest: module
+{
+ init: fn(nil: ref Draw->Context, nil: list of string);
+};
+ir: Ir;
+sys: Sys;
+init(nil: ref Draw->Context, nil: list of string)
+{
+ c: int;
+ stderr: ref FD;
+ irchan := chan of int;
+
+ sys = load Sys Sys->PATH;
+ stderr = sys->fildes(2);
+
+ # If the real IR remote application can
+ # be found, use it, otherwise use the simulator:
+ ir = load Ir Ir->PATH;
+ if(ir == nil)
+ ir = load Ir Ir->SIMPATH;
+ if(ir == nil) {
+ # %r format code means the last system error string
+ sys->fprint(stderr, "load ir: %r\n");
+ return;
+ }
+ if(ir->init(irchan) != 0) {
+ sys->fprint(stderr, "Ir.init: %r\n");
+ return;
+ }
+ names := array[] of {
+ "Zero",
+ "One",
+ . . .
+ "Mute",
+ };
+ for(;;) {
+ c = <-irchan;
+ if(c == ir->Error)
+ sys->print("Error %d\n", c);
+ else
+ sys->print("%s\n", names[c]);
+ }
+}
+movie(entry: ref Dbinfo, cc: chan of int)
+{
+ i: int;
+ m: Mpeg;
+ b: ref Image;
+
+ m = load Mpeg Mpeg->PATH;
+ if (m == nil)
+ return;
+ # make a place on the screen
+ w := screen.window(screen.image.r);
+
+ mr := chan of string;
+ s := m->play(w, 1, w.r, entry.movie, mr);
+ if(s != "")
+ return;
+ # wait for the end of the movie
+ # while watching for button pushes
+ for(;;) {
+ alt {
+ <-mr =>
+ return;
+ i = <-cc =>
+ case i {
+ Ir->Select =>
+ m->ctl("stop");
+ Ir->Up or Ir->Dn =>
+ m->ctl("pause");
+ }
+ }
+ }
+}
++Statically allocated storage within a module is accessible to +all the functions of that module, +and there is no explicit mechanism in Limbo for synchronizing +concurrent updates to this storage from several tasks. +However, it is straightforward to build a variety of concurrency-control +mechanisms by using channel communications. +
++An example is a module that implements a +Monitor +abstract data type. +Each instance of +Monitor +has a +lock +and an +unlock +operation; +calling +lock +delays if another task holds the lock; calling +unlock +releases the lock and enables any other task attempting +to execute +lock. +
implement Mon;
+
+Mon: module
+{
+ Monitor: adt {
+ create: fn(): Monitor;
+ lock: fn(m: self Monitor);
+ unlock: fn(m: self Monitor);
+ ch: chan of int;
+ };
+};
+Monitor.create(): Monitor
+{
+ m := Monitor(chan of int);
+ spawn lockproc(m.ch);
+ return m;
+}
+Monitor.lock(m: self Monitor)
+{
+ m.ch <- = 0;
+}
+Monitor.unlock(m: self Monitor)
+{
+ <- m.ch;
+}
+lockproc(ch: chan of int)
+{
+ for (;;) {
+ <- ch; # wait for someone to lock
+ ch <- = 0; # wait for someone to unlock
+ }
+}
+mp: Mon; +Monitor: import mp; +mp = load Mon "..."; +l := Monitor.create(); +l.lock(); +# region of code to be protected; +# only one thread can execute here at once. +l.unlock(); +
+Limbo channels are unbuffered; a sender blocks until there +is a receiver. +This example shows a way to make a buffered +channel of strings from an unbuffered channel. +It is written as a module whose +bufchan +function takes a +chan +of +string +and a size as argument, and returns a new channel; +it creates an asynchronous task that accepts input from the argument +channel and saves up to +size +strings, meanwhile trying to send them to its user. +
implement Bufchan;
+Bufchan: module {
+ bufchan: fn(c: chan of string, size: int): chan of string;
+};
+
+xfer(oldchan, newchan: chan of string, size: int)
+{
+ temp := array[size] of string;
+ fp := 0; # first string in buffer
+ n := 0; # number of strings in buffer
+ dummy := chan of string;
+ sendch, recvch: chan of string;
+ s: string;
+
+ for (;;) {
+ sendch = recvch = dummy;
+ if (n > 0)
+ sendch = newchan;
+ if (n < size)
+ recvch = oldchan;
+ alt {
+ s = <-recvch =>
+ temp[(fp+n)%size] = s;
+ n++;
+
+ sendch <- = temp[fp] =>
+ temp[fp++] = nil;
+ n--;
+ if (fp>=size)
+ fp -= size;
+ }
+ }
+}
+bufchan(oldchan: chan of string, size: int): chan of string
+{
+ newchan := chan of string;
+ spawn xfer(oldchan, newchan, size);
+ return newchan;
+}
++The module could be used in the following way: +
Bufchan: module {
+ PATH: con "/appl/lib/bufchan.dis";
+ bufchan: fn(c: chan of string, size: int): chan of string;
+};
+bufc := load Bufchan Bufchan->PATH;
+sourcech := chan of string;
+
+# ... (here, hand off sourcech to a process that
+# reads strings from it and copies them to ch)
+ch: chan of string = bufc->bufchan(sourcech, 10);
+s := <- ch;
++This section summarizes the grammar of Limbo +above the lexical level; constants and identifiers +are left undefined. +
++
+program: + implement identifier ; top-declaration-sequence +
+
+top-declaration-sequence: + top-declaration + top-declaration-sequence top-declaration +
+
+top-declaration: + declaration + identifier-list := expression ; + identifier-list = expression ; + ( identifier-list ) := expression ; + module-declaration + function-definition + adt-declaration +
+
+declaration: + identifier-list : type ; + identifier-list : type = expression ; + identifier-list : con expression ; + identifier-list : import identifier ; + identifier-list : type type ; + include string-constant ; +
+
+identifier-list: + identifier + identifier-list , identifier +
+
+expression-list: + expression + expression-list , expression +
+
+type: + data-type + function-type +
+
+data-type: + byte + int + big + real + string + tuple-type + array of data-type + list of data-type + chan of data-type + adt-type + ref adt-type + module-type + module-qualified-type + type-name +
+
+tuple-type: + ( data-type-list ) +
+
+data-type-list: + data-type + data-type-list , data-type +
+
+adt-type: + identifier + module-qualified-type +
+
+module-type: + identifier +
+
+module-qualified-type: + identifier -> identifier +
+
+type-name: + identifier +
+
+function-type: + fn function-arg-ret +
+
+function-arg-ret: + ( formal-arg-listopt ) + ( formal-arg-listopt ) : data-type +
+
+formal-arg-list: + formal-arg + formal-arg-list , formal-arg +
+
+formal-arg: + nil-or-D-list : type + nil-or-D : self refopt identifier + nil-or-D : self identifier + * +
+
+nil-or-D-list: + nil-or-D + nil-or-D-list , nil-or-D +
+
+nil-or-D: + identifier + nil +
+
+module-declaration: + identifier : module { mod-member-listopt } ; +
+
+mod-member-list: + mod-member + mod-member-list mod-member +
+
+mod-member: + identifier-list : function-type ; + identifier-list : data-type ; + adt-declaration ; + identifier-list : con expression ; + identifier-list : type type ; +
+
+adt-declaration: + identifier : adt { adt-member-listopt } ; +
+
+adt-member-list: + adt-member + adt-member-list adt-member +
+
+adt-member: + identifier-list : cyclicopt data-type ; + identifier-list : con expression ; + identifier-list : function-type ; + pick { pick-member-list } +
+
+pick-member-list: + pick-tag-list => + pick-member-list pick-tag-list => + pick-member-list identifier-list : cyclicopt data-type ; +
+
+pick-tag-list: + identifier + pick-tag-list or identifier +
+
+function-definition: + function-name-part function-arg-ret { statements } +
+
+function-name-part: + identifier + function-name-part . identifier +
+
+statements: + (empty) + statements declaration + statements statement +
+
+statement: + expression ; + ; + { statements } + if ( expression ) statement + if ( expression ) statement else statement + labelopt while ( expressionopt ) statement + labelopt do statement while ( expressionopt ) ; + labelopt for ( expressionopt ; expressionopt ; expressionopt ) statement + labelopt case expression { qual-statement-sequence } + labelopt alt { qual-statement-sequence } + labelopt pick identifier := expression { pqual-statement-sequence } + break identifieropt ; + continue identifieropt ; + return expressionopt ; + spawn term ( expression-listopt ) ; + exit ; +
+
+label: + identifier : +
+
+qual-statement-sequence: + qual-list => + qual-statement-sequence qual-list => + qual-statement-sequence statement + qual-statement-sequence declaration +
+
+qual-list: + qualifier + qual-list or qualifier +
+
+qualifier: + expression + expression to expression + * +
+
+pqual-statement-sequence: + pqual-list => + pqual-statement-sequence pqual-list => + pqual-statement-sequence statement + pqual-statement-sequence declaration +
+
+pqual-list: + pqualifier + pqual-list or pqualifier +
+
+pqualifier: + identifier + * +
+
+expression: + binary-expression + lvalue-expression assignment-operator expression + ( lvalue-expression-list ) = expression + send-expression + declare-expression + load-expression +
+
+binary-expression: + monadic-expression + binary-expression binary-operator binary-expression +
+
+binary-operator: one of + * / % + - << >> < > <= >= == != & ^ | :: && || +
+
+assignment-operator: one of + = &= |= ^= <<= >>= += -= *= /= %= +
+
+lvalue-expression: + identifier + nil + term [ expression ] + term [ expression : ] + term . identifier + ( lvalue-expression-list ) + * monadic-expression +
+
+lvalue-expression-list: + lvalue + lvalue-expression-list , lvalue +
+
+expression: + term + monadic-operator monadic-expression + array [ expression ] of data-type + array [ expressionopt ] of { init-list } + list of { expression-list } + chan of data-type + data-type monadic-expression +
+
+term: + identifier + constant + real-constant + string-constant + nil + ( expression-list ) + term . identifier + term -> term + term ( expression-listopt ) + term [ expression ] + term [ expression : expression ] + term [ expression : ] + term ++ + term -- +
+
+monadic-operator: one of + + - ! ~ ref * ++ -- <- hd tl len tagof +
+
+init-list: + element + init-list , element +
+
+element: + expression + expression => expression + * => expression +
+
+send-expression: + lvalue-expression <- = expression +
+
+declare-expression: + lvalue-expression := expression +
+
+load-expression: + load identifier expression +
+