Telescript (programming language)Telescript is an agent-oriented programming language written by General Magic as part of the overall Magic Cap system. Telescript programs used a modified C-like syntax known as High Telescript and were compiled to a stack-based language called Low Telescript for execution. Low Telescript ran within virtual machine interpreters, or "Telescript engines", on host computers.
General Magic had originally developed as a team within Apple Inc., and were spun off in 1990. When they began to generate some press buzz in 1992, Apple decided to enter the same market with their Newton tablet computer. General Magic were unable to find a niche within the market, and Telescript services were soon deprecated in favor of new products unrelated to mobile computing. HistoryIn 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] DescriptionUnderlying conceptsTelescript 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. Syntax and layoutAlthough 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 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, The PieSeller object, a Place, also contains a single method, 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 Telescript includes several built-in collection types, 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 Notes
ReferencesCitations
Bibliography
|
Portal di Ensiklopedia Dunia
