The NetPebbles research focus is on system design, but in order to freely experiment with the system-level issues such as efficient program mobility and so on, we needed our own scripting language. Our long term goal is to integrate NetPebbles programming language features into an existing scripting language. At present, NetPebbles provides a typeless, object-based scripting language called NPScript. The language borrows its syntax from the BASIC programming language, and it supports basic control flow constructs found in other scripting languages. In addition, it allows one to instantiate components and perform method invocations on those components. The component instances are persistent through the life of a NetPebbles script. The language does not provide RMI/RPC-like semantics or provide constructs to define new objects.
For creating components, NPScript provides the createComponent keyword. The syntax is as follows:
<varName>=createComponent(<interfaceName>,
<filter>) [at <locationName>]
where varName is the handle to the resulting instance, interfaceName is the InterfaceID that the component should support, and filter is a stringified boolean expression of component attribute/value pairs. Optionally, using the at keyword, one can also specify the locationName indicating where the component should be instantiated. Under the covers, the runtime contacts the component catalog and resolves the interfaceName and filter to a ComponentID. If a locationName is specified then the runtime migrates the script to that location and also downloads the component to that location. Otherwise, the runtime either migrates the script to the component host, or downloads the component to the current location (further details are discussed in section 5.2.1). The runtime then creates an instance of the component and stores a handle to it in varName. The syntax for performing method invocations is as follows:
[<resultVar>=] <varName>.methodName(type1,...,typeN) <arg1,..., argN>
where resultVar is the variable to store the results of the invocation, varName is the handle to the component instance, methodName(argType1,...,argTypeN) is the complete signature of the method to invoke, and <arg1,..., argN> is the list of arguments.
The language is inherently typeless - a programmer does not have to indicate the type of the variable before using it. The typeless nature of the language simplifies programmability. However, NetPebbles uses typed components written in Java, which require that data be appropriately converted to the correct type before the method is called. This requirement makes the runtime more complex because it has to convert the data values to the correct types before invoking methods on the components. Another artifact of using typed components is that two methods in the same interface can have the same name but different argument types. This makes the method resolution ambiguous at runtime if only the method name is specified in the scripting language. Thus, NetPebbles requires the programmer to completely specify a method with a name and types of arguments. The combination of a method name and its argument types uniquely identifies a method in an interface. It also provides information to the NetPebbles runtime to appropriately convert data to the types that the components expect.
As an effort to simplify programming, we are considering support for collections at the language level. The basic idea is to allow the programmer to create a collection and populate it with homogeneous components. The programmer can then perform any operation on the collection in a single statement without having to iterate through individual elements of the collection. Support for language constructs that allow the NetPebbles script to fork itself, or perform asynchronous method invocations are also being considered.