NJPLS at Stevens -- 10 October 2001 -- Schedule

10:00am Jeffrey Mark Siskind, NEC Research Instutute, Inc. ECE Department, Purdue University: The Architecture of a World-Wide Distributed Repository to Support Fine-Grained Sharing of Source Code

There has been an explosion in free software over the past few years. Vehicles like FSF, GNU, CVS, RPM, Linux, and freshmeat.net allow programmers to share hundreds of millions of lines of source code. These vehicles, however, support only coarse-grained source-code sharing. The unit of sharing is a complete package. And packages are monolithic. About the only thing one can easily do with packages obtained from such vehicles is install them. While a package might contain a collection of procedures and type declarations that implement some functionality that a programmer might wish to reuse in a different system, it is difficult to find which package contains that functionality, extract that functionality from its original package, and import it into a new system. In this talk, I present a new vehicle, called October, that is designed to support fine-grained source-code sharing: sharing at the level of individual procedure and type declarations. Unlike CVS, which allows many people to share in the development of the same system, October allows many people to share in the development of different systems.

October is organized like the Web. Instead of Web pages there are top-level definitions. Top-level definitions are stored in a distributed repository implemented by October servers that are analogous to Web servers. They are viewed and manipulated by October browsers that are analogous to Web browsers. October servers and browsers communicate via the October protocol which plays the role of HTTP and allows different server and browser implementations to interoperate. The October protocol is designed from the start with support for searching, caching, mirroring, and load balancing. These play the role of search engines, proxy servers, and Web caches. Search is currently based on string matching, though future plans call for type-based search supported by local and global type inference built into the October protocol and implemented by the October servers. Top-level definitions are stored as abstract syntax trees (ASTs) which play the role of HTML. Instead of URLs there are version locators. Top-level definitions are hyperlinked via embedded version locators. When building an executable, the browser crawls the repository to fetch all top-level definitions referenced directly or indirectly by the top-level definition being built.

October is designed to be programming-language and programmer-preference neutral. It is neither a new programming language nor a new compiler. Rather, it supports existing programming languages and compilers. Just as the Web supports different document styles via DTDs, October supports different programming languages and programmer preferences via programming language definitions (PLDs). A novel aspect of PLDs is that they separate the definition of the abstract syntax for a given language from the mapping between abstract and concrete syntax. This allows users to configure their browsers to dynamically render the code they view in a different concrete syntax according to their personal preference. PLDs are currently written to support Scheme, C, and Java.

The overall goal of October is to boost world-wide programmer productivity by encouraging an unprecedented degree of source-code sharing, shifting the prevalent mode of programming from implementation to augmentation. In this talk, I will describe how October is designed to support this goal, discuss how this goal motivates and influences the creation of a new infrastructure, present some of the technical problems and design tradeoffs addressed so far while creating this infrastructure, and give a live demo of the prototype implementation of October.

10:45am Dan Duchamp, Stevens: Coping With The Discrete Internet

The traditional model of the Internet is ``end-to-end'' -- two endpoints talk to each other directly, with nothing lying between them except routers that provide shortest-path packet forwarding. This model does not scale, so increasingly it is being violated by the placement of application-level intermediaries between endpoints. Some intermediaries are motivated by security (NAT, VPN), some by latency (web caches and load balancers), some by the multiplicity of link layers types (protocol converters), some by the multiplicity of endpoint devices (transcoders), and some by the consequences of size. An intermediary snoops on end-to-end conversations, typically TCP connections, understands part of the payload, and operates on the connection in significant ways.

Population of the Internet by a wide and growing variety of intermediaries gives rise to a ``Discrete Internet'' because a single application-to-application conversation is implemented as a sequence of hops not only at the IP routing level, but also among intermediaries at the transport and/or application levels. Implementing the Discrete Internet on top of the existing TCP/IP infrastructure is problematic. In particular, the TCP/IP model has nothing between the transport and application layers. Therefore, the transport protocol bears the burden of verifying delivery to the endpoint.

In this talk I will explain the ill consequences of using the same protocol for delivery verification as well as other services such as error recovery, ordering, congestion control, etc. I will then outline a proposed new ``connection layer'' lying between the application and transport layers. The connection layer explicitly recognizes the existence of a Discrete Internet, allowing creation and management of several transport connections that together form a single connection between two application endpoints, providing many advantages.

11:30am Break

11:45am Zhe Yang, NYU The annotation erasure property of two-level languages

The correctness of a partial evaluator, when formalized using a two-level language, can be captured by the annotation erasure property, which states that evaluating a two-level program in two stages yields the same result as evaluating its erasure in one stage. This property can be easily established in an ideal setting, where the object language is equipped with a confluent reduction semantics. Using the annotation erasure property, the correctness proof of some non-trivial, higher-order program-generation algorithms (a.k.a., macros!) amounts to a simple "erasure" argument, where the actual proof uses only simple equational reasoning. Does this sound too good to be true? In this talk, I will survey the difficulties in designing two-level languages with the annotation erasure property and in proving this property. I will show the design of a two-level language for a realistic object language, and sketch the proof of the annotation erasure for this language. I will try to explain the essence of erasure arguments. Finally, I will emphasize the importance of annotation erasure through existing and potential applications, and discuss how this property can be brought into modern multi-level or multi-stage languages.

12:30pm Lunch

1:45pm Business meeting

2:00pm David Naumann, Stevens: Confinement and representation independence for Java
Joint work with Anindya Banerjee

Encapsulation mechanisms, such as modules and classes, are intended to ensure that clients are not dependent on internal data representations used by services. But sharing of pointers often violates encapsulation. We give a notion of confinement that is sufficient to prove representation-independence for a substantial fragment of Java using a straightforward denotational semantics, and discuss practical issues for confinement disciplines.

2:45pm Break

3:15pm Healfdene Goguen, AT&T: A Visual Bridge from Design to Implementation
Joint work with Gregory Bond, AT&T Labs Research.

The Statecharts approach for visually modeling behavior has a long history. With its adoption by the OMG as part of the Unified Modeling Language standard, it has gained widespread recognition. In this talk we discuss why the semantics of UML Statecharts, while adequate for design, is inappropriate for implementation. To address the issues raised, we propose a new language, ECLIPSEcharts, that incorporates modifications and extensions to UML Statecharts, and we compare it with existing languages. We also draw motivating examples from ECLIPSE, an IP-based framework for multimedia communication services which uses our implementation of ECLIPSEcharts on a daily basis for design and implementation.

4:00pm Talks End

Adriana Compagnoni / abc@cs.stevens-tech.edu

Last modified: Tue Oct 9 12:55:05 EDT 2001