LIMBO(ID:2166/lim002)Doward, Winterbottom, and Pike, Bell (Lucent) 1995 So called for the Dantean naming scheme (Inferno, Limbo, Dis, Vita Nuova etc) - according to the VN website, "Rob Pike was reading Dante's Divine Comedy when the Computing Science Research Group at Bell Labs was working on Inferno" Strongly typed, provides automatic garbage collection, supports only very restricted pointers, and compiles into machine-independent byte code for execution on a virtual machine. The language is intended for applications running distributed systems on small computers. It supports modular programming, strong type checking at compile and run-time, interprocess communications 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. Clu-style exception handling added in 2003: "We have added exception handling to the Limbo language, replacing sys->rescue etc. This is intended to make it more straightforward to write fault-tolerant subsystems. The semantics broadly follow that used by the programming language CLU. There are many advantages: it is structured and fits into the language rather than being bolted on; the programmer, compilers and JIT can see the scope of exception handlers, allowing the system (for instance) to nil out values in the block on an exception, and get register allocation right; and the implementation is better. The source changes to Limbo applications are relatively small, and the result is tidier. " Ada-95 style fixed point maths added: "We have also added fixed-point arithmetic type and operators to Limbo. The intention is to simplify the implementation of fixed-point algorithms especially when interacting with devices that provide fixed-point values or when working on a platform without floating-point support. The underlying model is broadly that developed for Ada-95's fixed-point (with one or two artifacts left over from Ada-83 eliminated)." Places People: Related languages
References: What I shall tell, that is no cause for wonder, For I who saw it hardly can accept it." Dante Alighieri, Inferno, Canto XXV. Limbo is a new programming language, designed by Sean Dorward, Phil Winterbottom, and Rob Pike. Limbo borrows from, among other things, C (expression syntax and control flow), Pascal (declarations), Winterbottom's Alef (abstract data types and channels), and Hoare's CSP and Pike's Newsqueak (processes). Limbo is strongly typed, provides automatic garbage collection, supports only very restricted pointers, and compiles into machine-independent byte code for execution on a virtual machine. This paper is an introduction to Limbo. Since Limbo is an integral part of the Inferno system, the examples here illustrate not only the language but also a certain amount about how to write programs to run within Inferno. Disclaimer: I'm no expert on Limbo, so take this with a grain of salt. And some of this may be wrong because Limbo is still evolving. So is this introduction; comments and suggestions for improvement are welcome. External link: Online copy Extract: Introduction Introduction This document is a quick look at the basics of Limbo; it is not a replacement for the reference manual. The first section is a short overview of concepts and constructs; subsequent sections illustrate the language with examples. Although Limbo is intended to be used in Inferno, which emphasizes networking and graphical interfaces, the discussion here begins with standard text-manipulation examples, since they require less background to understand. Modules: A Limbo program is a set of modules that cooperate to perform a task. In source form, a module consists of a module declaration that specifies the public interface - the functions, abstract data types, and constants that the module makes visible to other modules - and an implementation that provides the actual code. By convention, the module declaration is placed in a separate .m file so it can be included by other modules, and the implementation is stored in a .b file. Modules may have multiple implementations, each in a separate implementation file. At run time, modules are loaded dynamically; the load statement fetches the code and performs run-time type checking. Once a module has been loaded, its functions can be called. Limbo is strongly typed; programs are checked at compile time, and further when modules are loaded. The Limbo compiler compiles each source file into a machine-independent byte-coded .dis file that can be loaded at run time. Functions and variables: Functions are associated with specific modules, either directly or as members of abstract data types within a module. Functions are visible outside their module only if they are part of the module interface. If the target module is loaded, specific names can be used in a qualified form like sys->print or without the qualifier if imported with an explicit import statement. Besides normal block structure within functions, variables may have global scope within a module; module data can be accessed via the module pointer. Data: The numeric types are: byte unsigned, 8 bits int signed, 32 bits big signed, 64 bits real IEEE long float, 64 bits The size and signedness of integral types are as specified above, and will be the same everywhere. Character constants are enclosed in single quotes and may use escapes like '\n' or '\udddd', but the characters themselves are in Unicode and have type int. There is no enumeration type, but there is a con declaration that creates a named constant. Limbo also provides Unicode strings, arrays of arbitrary types, lists of arbitrary types, tuples (in effect, unnamed structures with unnamed members of arbitrary types), abstract data types or adt's (in effect, named structures with function members as well as data members), reference types (in effect, restricted pointers that can point only to adt objects), and typed channels (for passing objects between processes). A channel is a mechanism for synchronized communication. It provides a place for one process to send or receive an object of a specific type; the attempt to send or receive blocks until a matching receive or send is attempted by another process. The alt statement selects randomly but fairly among channels that are ready to read or write. The spawn statement creates a new process that, except for its stack, shares memory with other processes. Processes are pre-emptively scheduled by the Inferno kernel. (Inferno processes have much in common with threads in other operating systems.) Limbo performs automatic garbage collection, so there is no need to free dynamically created objects. Objects are deleted and their resources freed when the last reference to them goes away. In general this release of resources happens immediately ("instant free''); release of cyclic data structures may be delayed. Operators and expressions: Limbo provides many of C's operators, but there is no ?: operator, and ++ and -- can only be postfix. Pointers, created with ref, are very restricted and there is no & (address of) operator; there is no address arithmetic and pointers can only point to adt objects. Array slicing is supported, however, and replaces many pointer constructions. There are no implicit coercions between types, and only a handful of explicit casts. The numeric types byte, int, etc., can be used to convert a numeric expression, as in nl := byte 10; and string can be used as a unary operator to convert any numeric expression or array of bytes to a string (in %g format). Statements: Statements and control flow in Limbo are similar to those in C. A statement is an expression followed by a semicolon, or a sequence of statements enclosed in braces. The similar control flow statements are if (expr) stat if (expr) stat else stat while (expr) stat for (expr; expr; expr) stat do stat while (expr) ; return expr ; exit ; The exit statement terminates a process and frees its resources. There is also a case statement analogous to C's switch; it also supports string and range tests. A break or continue followed by a label causes a break out of, or the next iteration of, the enclosing construct that is labeled with the same label. Comments begin with # and extend to the end of the line. There is no preprocessor, but an include statement can be used to include source code, usually module declaration files. Libraries: Limbo has a small but growing set of standard libraries, each implemented as a module. A handful of these (notably Sys, Draw, and Tk) are included in the Inferno kernel because they will be needed to support almost any Limbo program. Among the others are Bufio, a buffered I/O package based on Plan 9's Bio; Regex, for regular expressions; and Math, for mathematical functions. Some of the examples that follow provide the sort of functionality that might be a suitable module. environments such as Inferno and Java because they provide an architecture-independent representation of executable code. Their performance is critical to the success of such environments, but they are difficult to design well because they are subject to conflicting goals. On the one hand, they offer a way to hide the differences between instruction architectures; on the other, they must be implemented efficiently on a variety of underlying machines. A comparison of the engineering and evolution of the Inferno and Java virtual machines provides insight into the tradeoffs in their design and implementation. We argue that the design of virtual machines should be rooted in the nature of modern processors, not language interpreters, with an eye towards on-the-fly compilation rather than interpretation or special-purpose silicon. External link: Online copy Limbo The Inferno operating system is a Plan 9 spinoff intended for set-top boxes. Its programming language, Limbo [9], was heavily influenced by Alef. It removed the distinction between procs and tasks, effectively having just procs, though they were of lighter weight than what most people think of as processes. All parallelism is preemptive. It is interesting that despite this, the language provides no real support for locking. Instead, the channel communication typically provides enough synchronization and encourages programmers to arrange that there is always a clear owner for any piece of data. Explicit locking is unnecessary. Resources
|