Telescript (programming language)

In 1990, Marc Porat convinced then-Apple-CEO John Sculley that the future of computing lay not in desktop personal computers, but much smaller portable devices combining computing power, communications systems, and data located on network-accessible servers.^[1] He noted that portable computers would always have less power than the machines they would connect to, and suggested that this be part of the design - instead of trying to build a portable computer that could perform the tasks of a desktop system, the portable device should invisibly use the computational power of the servers to produce a similar result.^[2][3]

Sculley agreed to allow Porat to begin researching the concepts under the code-name "Pocket Crystal". Key members of the early team were Porat, and famous Macintosh developers Bill Atkinson and Andy Hertzfeld. The team quickly found themselves ignored by upper management and left continually struggling for resources. They approached Sculley again with the idea of spinning off Pocket Crystal as a separate company. Sculley agreed to this, as well as the idea of inviting in new partners on the hardware side. The new company, General Magic (GM), was created in May 1990 with Apple, Sony and Motorola each holding a 10% stake. The company ranks soon filled out with other Macintosh alumni, including Joanna Hoffman, Susan Kare, Dan Winkler, Bruce Leak and Phil Goldman.^[1]

By 1992 GM had signed development agreements with a number companies to work with the Magic Cap environment, including Sony, Motorola, Matsushita, Philips, British Telecom and AT&T Corporation. This generated considerable press "buzz".^[3] Apple had by this time started the Newton project, a design for a larger hand-held tablet-like computer more similar to the full-sized iPad. With General Magic's success in the press, they re-positioned the Newton squarely in the same market and rushed it to release in 1993. They also sold their stake in General Magic and sued them. General Magic's partners did not release hardware until 1994, by which time the Newton had essentially defined what a personal digital assistant (PDA) should be, and PDA systems were being judged on their handwriting recognition capabilities. Magic Cap was a point and click interface (similar to HyperCard or the modern iOS).^[2]

By 1995 the company was a shell of its former self and most of the original developers had left. In 1996 Steve Markman was hired to take over, and he hired Kevin Surace to take the company in a new direction. A new team developed the Portico telephone-based personal assistant system, which lives on today as the basis of OnStar. The original handheld group was spun off in 1998 as DataRover Mobile Systems Incorporated and later renamed Icras in 2000,^[4] serving a number of vertical markets before shutting down in 2001.^[5] The remains of the original company were liquidated in 2004.^[3]

Telescript was modelled on the concept of small programs known as agents that would interact with computing services known as places all of which would run on a cluster of one or more servers that hosted what was called a Telescript cloud. The user's handheld device was one such place, albeit one with limited capabilities. The model assumed that most information and services would be provided by places running on larger server computers hosted by the communications providers like AT&T. Even early documents refer to this as running in the cloud.^[1] User-facing programs would consist of a number of such agents, which might run locally, on the provider's hosts, or even be forwarded to 3rd party servers. To coordinate communications, Telescript also included the concepts of a telename that uniquely identified users, and teleaddresses which identified the device even as it moved between networks.^[6]

For example, consider a shopping application that the user asks to find prices on a new barbecue grill they wish to purchase. In a traditional client–server model, the application would form a number of queries, send them to a number of services, and then collect the results and display them. In the Telescript model, the application would instead build a new agent populated with the data from the request, stamp it with their name and address, and then send that to a store place on a server for processing. That server could then handle the request directly, or hand off the agent to other places, like the actual vendors' places, for further processing. The results could be placed in the agent's internal data fields and sent back through the network to the user's device, or a new "messenger" agent could be spawned to carry only the result data and sent back to minimize network data transfer.^[7]

The model also differs from traditional solutions in the way that data exchange occurs in the case of interacting programs. For instance, if the user chooses to buy one of the barbecues they found in their previous search, in a conventional system the task of filling out the order forms and confirming payment would be accomplished through direct communications between the user's device and the remote server, requiring a "live" communications channel throughout the process. In the Telescript model, a new agent with the information needed to complete the purchase is sent to that vendor's store place, interacts with the store place or agents from the vendor, and then returns with the success or failure. The main communications takes place between the agents and places on the remote server, so communications over the network is required only at the start and end of the process.^[8]

Telescript was object-oriented (OO) and used a number of uncommon terms to describe object state and communications. Attributes correspond to what other languages refer to as instance variables or fields. Method calls were known as requests, and the act of running a method's implementation was known as performing it. All such calls always responded with a message indicating success or failure, it was up to the requesting object to optionally trap those and respond to them. Hints on how to pass the data into and out of method calls were known as constraints, and covered the common "by ref" and "by value", among others.^[9]

Telescript was generally stateless in terms of data lifetime. All data within the program, both instance and local variables, were always serialized. Agents could be invoked or suspended at any instant, and would not lose their state. This same mechanism also allowed agents to be easily communicated between hosts.

Although Telescript's control and layout was inspired by C, its precise syntax was considerably different. One obvious difference was the replacement of C-style curly braces with parentheses at the definition level, retaining curly braces for grouping statements within logic and flow control statements, and the use of the colon to separate a name from its definition. The following code defines the interface for objects of the type Pie:^{[10][N 1]}

  Pie: interface(Object) = (
       public
           name: String;
           initialize: op(name: String);
  );

Note the use of the keyword op, which corresponds to the function or sub found in other languages. The implementation of the Pie could be used in one or more class objects, which can be organized into moduless in a fashion similar to Visual Basic .NET's namespace construct. #include is used to import header files, but the import is local to the modules, not the file as a whole.^[11]

Telescript's agent and places concepts were invoked simply by sub-classing those two classes, Agent and Place, both of which were subclasses of Process. For code clarity, one could place both of these in a single file, and even gather them into a single module. The following code defines the agents needed to implement a store that sells Pies:^[12]

   PieStoreModule: module = (
   	#include "pie.i"
       
   	PieBuyer: class(Agent) = (
   		public
   			live: sponsored op() = {
   					*.go(*.destination);
   					myPie = place@PieSeller.sellPie();
   					*.go(*.originPlace);
   				};
   			);
   			
   	PieSeller: class(Place) = (
   		public
   			sellPie: op() Pie = {
   				aPie: Pie | Nil;
   				aPie = *.getPieFromStock;
   				if (aPie = nil) {
   					PieBuyer(*.distributorTicket, Permit(nil));
   					aPie = *.waitForPie();
   					return aPie;
   				};
   			};
   		);
   );

The PieBuyer object, an Agent, contains a single method, live, the standard startup method used by all Agents.^[13] Simply creating a PieBuyer and invoking it will cause the live method to be called, in a fashion similar to the new operation found in most OO languages, although this method is called after setup. The * replaces what is more commonly implemented as self or Me, referring to the object itself, in this case the PieBuyer agent. The code basically says that when it is created, the object should send itself (*.go) to the location sent to it during creation (*.destination). Once there, it should tell the matching place object, in this case a PieSeller, to sellPie. When that command is complete, the agent will return to its place of origin. The invoking application can then examine the results by inspecting the myPie variable.^[12]

The PieSeller object, a Place, also contains a single method, sellPie. It defines a local variable called aPie, defining it to be a Pie object, or "nothing", which is used in the case that there are no pies. It then attempts to set aPie to a value by calling its own getPieFromStock method (not shown here) and then checks if that returned a value. If it did not succeed, for instance, if the stock was empty, it then builds a new PieBuyer object of its own, sends that request off to another shop, and then waits for a response. That shop might forward the request off to another, and so on. When this chain of events concludes, either with a pie or unsuccessfully, the PieSeller place finally returns that to the calling PieBuyer.^[12]

Objects are normally "owned" by the place that created them. Ownership also confers capabilities and security settings. The language can take ownership of an object through the own {} construct, or in this case, use the sponsored keyword to indicate it should run within the ownership of the place it is running in. This might be used, for instance, to grant the agent the ability to see stock in the inventory, values that would otherwise be private. Using sponsored is exactly the same result as placing the code in an own {} block, but allows this to take place in the caller.^[14]

Telescript includes several built-in collection types, Set, List, Dictionary, and Collection, the last of which is essentially a List with text indexes (one half of a Dictionary). One common source of errors in Telescript was that while a collection as a whole could be passed back in an agent, individual items within it were owned by the place. Thus if one used return MyCollection[someIndex];, it would arrive back on the user's device as null. The solution was additional syntax, the DictOwned and ColOwned hints, which caused the ownership of returned values to be changed on return, and thus be serialized into the results when returning to the original place.^[15]

Sub-classes were known as flavors; the PieBuyer class outlined above is a flavor of Agent. Telescript also included the concept of mix-in classes, which offered features similar to multiple inheritance by allowing the creation of classes containing only code that could then be included in other classes. Mix-ins were not flavors.^[16]

Like many modern OO languages, Telescript separated interface and implementation, placing these in .i files for the interface, and .t files for the implementation (t as in "t"elescript). Uncommonly, the language also defined a third type of file, .d, which combined multiple .i files together.^[17] Compiled code was placed in a .s file, which was guided by linker instructions in a .l file.^[18] The External Application Framework allowed C++ code to be called by Telescript.^[19]