We present nesC, a programming language for networked embedded systems that represent a new design space for application developers. An example of a networked embedded system is a sensor network, which consists of (potentially) thousands of tiny, lowpower “motes, ” each of which execute concurrent, reactive programs that must operate with severe memory and power constraints. nesC’s contribution is to support the special needs of this domain by exposing a programming model that incorporates event-driven execution, a flexible concurrency model, and component-oriented application design. Restrictions on the programming model allow the nesC compiler to perform whole-program analyses, including data-race detection (which improves reliability) and aggressive function inlining (which reduces resource consumption). nesC has been used to implement TinyOS, a small operating system for sensor networks, as well as several significant sensor applications. nesC and TinyOS have been adopted by a large number of sensor network research groups, and our experience and evaluation of the language shows that it is effective at supporting the complex, concurrent programming style demanded by this new class of deeply networked systems.

This paper presents a variant of the SML module system that introduces a strict distinction between abstract types and manifest types (types whose de nitions are part of the module speci cation), while retaining most of the expressive power of the SML module system. The resulting module system provides much better support for separate compilation. 1

The introduction of Java applets has taken the World Wide Web by storm. Information servers can customize the presentation of their content with server-supplied code which executes inside the Web browser. We examine the Java language and both the HotJava and Netscape browsers which support it, and find a significant number of flaws which compromise their security. These flaws arise for several reasons, including implementation errors, unintended interactions between browser features, differences between the Java language and bytecode semantics, and weaknesses in the design of the language and the bytecode format. On a deeper level, these flaws arise because of weaknesses in the design methodology used in creating Java and the browsers. In addition to the flaws, we discuss the underlying tension between the openness desired by Web application writers and the security needs of their users, and we suggest how both might be accommodated. 1.

A module system ought to enable assembly-line programming using separate compilation and an expressive linking language. Separate compilation allows programmers to develop parts of a program independently. A linking language gives programmers precise control over the assembly of parts into a whole. This paper presents models of program units, MzScheme's module language for assembly-line programming. Units support separate compilation, independent module reuse, cyclic dependencies, hierarchical structuring, and dynamic linking. The models explain how to integrate units with untyped and typed languages such as Scheme and ML.

This paper presents a program transformation that allows languages with polymorphic typing (e.g. ML) to be implemented with unboxed, multi-word data representations, more efficient than the conventional boxed representations. The transformation introduces coercions between various representations, based on a typing derivation. A prototype ML compiler utilizing this transformation demonstrates important speedups.

Two of the most important issues in distributed systems are the synchronization of concurrent threads and the application-level data transfers between execution spaces. At the design level, addressing these issues typically requires analyzing the components under a different perspective than is required to analyze the functionality. Very often, it also involves analyzing several components at the same time, because of the way those two issues cross-cut the units of functionality. At the implementation level, existing programming languages fail to provide adequate support for programming in terms of these different and cross-cutting perspectives. The result is that the programming of synchronization and remote data transfers ends up being tangled throughout the components code in more or less arbitrary ways. This thesis presents a language framework called D that untangles the implementation of synchronization

This dissertation provides a framework for modularity in programming languages. In this framework, known as Jigsaw, inheritance is understood to be an essential linguistic mechanism for module manipulation. In Jigsaw, the roles of classes in existing languages are "unbundled," by providing a suite of operators independently controlling such effects as combination, modification, encapsulation, name resolution, and sharing, all on the single notion of module. All module operators are forms of inheritance. Thus, inheritance is not in conflict with modularity in this system, but is indeed its foundation. This allows a previously unobtainable spectrum of features to be combined in a cohesive manner, including multiple inheritance, mixins, encapsulation and strong typing. Jigsaw has a rigorous semantics, based upon a denotational model of inheritance. Jigsaw provides a notion of modularity independent of a particular computational paradigm. Jigsaw can therefore be applied to a wide variet...

Standard ML is an excellent language for many kinds of programming. It is safe, efficient, suitably abstract, and concise. There are many aspects of the language that work well. However, nothing is perfect: Standard ML has a few shortcomings. In some cases there are obvious solutions, and in other cases further research is required.

A complete set of algebraic laws is given for Dijkstra’s nondeterministic sequential programming language. Iteration and recursion are explained in terms of Scott’s domain theory as fixed points of continuous functionals. A calculus analogous to weakest preconditions is suggested as an aid to deriving programs from their specifications.

"Object-Oriented Programming" and "Data Abstraction" have become very common terms. Unfortunately, few people agree on what they mean. I will offer informal definitions that appear to make sense in the context of languages like Ada, C++, Modula2, Simula, and Smalltalk. The general idea is to equate "support for data abstraction" with the ability to define and use new types and equate "support for object-oriented programming" with the ability to express type hierarchies. Features necessary to support these programming styles in a general purpose programming language will be discussed. The presentation centers around C++ but is not limited to facilities provided by that language.