Skip to main content

Past Futures of Programming: General Magic's Telescript


Telescript was a programming language developed by General Magic in the nineties that allow the first generation of mobile devices to interact with services in a network.

This sounds similar to the way smartphones work today, but the paradigm that Telescript supported called "Remote Programming" instead of Remote Procedure Calling is really different to the way we build services and mobile applications today.

For this reason and because as far as I know there's not much knowledge about the language and the paradign online I decided to write a summary after reading all the content I could find. All resources are linked at the end of the article.

If you haven't heard of General Magic I highly recommend you to watch the documentary, here's the trailer:

In case you prefer content in video form, the following may give you an idea.

For an overview video and the earliest mention of the Cloud I can think of see:

An introduction by Andy Hertzfeld at 21:20 in this video:

Another (longer) talk by Andy at Standford two weeks after the one above, mostly focused on Magic Cap but mentions Telescript around 1:06:38:

From now on most of the text is quoted from the resources linked at the end, since my personal notes are just a few I will quote only my comments, they will look like this:

Hi, this is a comment from the author and not a quote from Telescript resources.

Since each resource attempts to be self contained there's a lot of content that is repeated with some variation.

I slightly edited the quoted text to avoid repetition. Emphasis is mine.

The Pitch

The convergence of computers and communication, and advances in graphical user interfaces are placing powerful new electronics products in the hands of consumers.

In principle, such products can put people in closer touch with one another -- for example, by means of electronic postcards; simplify their relationships by helping them make and keep appointments; provide them with useful information such as television schedules, traffic conditions, restaurant menus, and stock market results; and help them carry out financial transactions, from booking theater tickets, to ordering flowers, to buying and selling stock.

Unless public networks become platforms on which third-party developers can build communicating applications, the networks will respond much too slowly to new and varied requirements and so will languish. Unfortunately, today's networks are not platforms.

Telescript enables the creation of a new breed of network that supports the development of communicating applications by making the network a platform for developers. It provides the "rules of the road" for the information superhighway, which leads to the electronic marketplace.

The Electronic Marketplace

Telescript integrates an electronic world of computers and the networks that link them. This world is filled with Telescript places occupied by Telescript agents.

In the electronic world, each place or agent represents an individual or organization in the physical world, its authority. A place's or agent's authority is revealed by its telename, which can't be falsified.

A place, but not an agent, has a teleaddress, which designates the place's location in this electronic world and reveals the authority of the individual or organization operating the computer in which the place is housed.

The typical place is permanently occupied by an agent of the place's authority and temporarily occupied –visited– by agents of other authorities.

The Plan

In July 1995, NTT, AT&T, and Sony announced a joint venture to deploy a Telescript-based service in Japan.

In October 1995, France Telecom (the operater of the Minitel electronic marketplace, which supports more than 26,000 merchants and accessed in 1994 by 18 million users) announced its licensing of Telescript for use in France.

The Language

Telescript is:

  • Object-oriented: As in SmallTalk

  • Complete: Any algorithm can be expressed in the language.

  • Dynamic: A program can define or discover, and then use new classes during execution. While exploring the electronic marketplace, a Telescript agent may encounter an object whose class it has never seen. The agent can take the object home, where it continues to function.

  • Persistent. The Telescript engine secures all its data transparently, even the program counter that marks its point of execution. Thus, a Telescript program persists even in the face of computer failures.

  • Interpreted

  • Portable and safe: A computer executes an agent's instructions through a Telescript engine, not directly. An agent can execute in any computer in which an engine is installed, yet it cannot access directly its processor, memory, file system, or peripheral devices.

  • Communication-centric: Designed for carrying out complex networking tasks: navigation, transportation, authentication, access control, and so on.

Telescript supplements systems programming languages such as C and C++; it does not replace them. Only the parts of an application that require the ability to move from one place in a network to another –the agents– are written in Telescript.

Telescript is object-oriented. In fact, like the first object-oriented language, Smalltalk, Telescript is deeply object-oriented. That is, every piece of information, no matter how small, is an object. Thus, even a Boolean is an object.

Like many object-oriented programming languages, Telescript focuses on classes. A class is a "slice" of an object's interface, combined with a related "slice" of its implementation. An object is an instance of a class.

Standard OOP similar to Smalltalk/Java, check Telescript Object Model for details

Process objects provide Telescipt's multi-tasking functionality. Processes are pre-emptively multi-tasked, and scheduled according to priority.

Telescript implements the following principal concepts:

  • Places

  • Agents

  • Travel

  • Meetings

  • Connections

  • Authorities

  • Permits

Telescript extends the concept of remote programming, the ability to upload and execute programs to a remote processor, with migrating processes. A Telescript mobile agent is a migrating process that is able to move autonomously during its execution to a different processor and continue executing there.

Mobile agents conceptually move the client to the server, where stationary processes, or places, service their requests. When it is done in a place, an agent might choose to move itself to a different processor, carry results back to where it originated, or simply terminate.

Clearly, security is a major concern in this scenario. The operator of a Telescript processor wants some assurance that nothing bad will come of its decision to admit an incoming agent. The host platform wants to know who is responsible for the agent. The agent, on the other hand, would like to trust that private information it is carrying will not be disclosed arbitrarily. It needs to trust the operator of the platform.

Telescript provides some useful Mix-in classes that associate security-relevant attributes with objects of those classes, where the associated functionality is enforced by the engine. These include:

  • Unmoved. An agent cannot take such an object along with it when it does a go. Places, for example, are Unmoved.

  • Uncopied. An attempt to make a copy of such an object returns a reference to the original object rather than creating a copy.

  • Copyrighted. This class is provided as a language extension rather than part of the language. Nonetheless, it is built into engines. An attempt to instantiate such an object will fail during initialization if it is not properly authorized by a suitable Copyright Enforcer object.

  • Protected. Such an object cannot be modified once created, and any reference to such an object is like having a protected reference, except that ownership can be transferred. Packages are Protected.

Unauthorized processes, or processes that are not running under the region's authority, cannot create instances of the following classes:

  • File: A File object can create a handle to any file that the engine can access on the underlying operating system.

  • External Handle: An External Handle object can open a TCP/IP port on the underlying operating system.

  • Control Manager: A Control Manager object can be used to perform a number of management and control operations on an engine. For example, a Control Manager can be used to change attributes of processes, such as their authority, or to halt the engine.

The Current Approach: Remote Procedure Calling

Today networking is based upon remote procedure calling (RPC). A network carries messages -- data -- that either request services or respond to such requests. The sending and receiving computers agree in advance upon the messages they will exchange. Such agreements constitute a protocol.

A client computer with work for a server computer to accomplish orchestrates the work with a series of remote procedure calls. Each call comprises a request, sent from client to server, and a follow-up response, sent from server to client.

The New Approach: Remote Programming

A different approach to networking is remote programming (RP). The network carries objects -- data and procedures -- that the receiving computer executes.

The two computers agree in advance upon the instructions from which procedures are formed. Such agreements constitute a language.

A client computer with work for a server computer to accomplish orchestrates the work by sending to the server an agent whose procedure makes the required requests (e.g., "delete") using the data (e.g., "two weeks"). Deleting the old files -- no matter how many -- requires just the message that transports the agent between computers. All of the orchestration, including the analysis deciding which files are old enough to delete, is done "on-site" at the server.

The salient characteristic of remote programming is that client and server computers can interact without the network's help once it has transported an agent between them. Thus, interaction does not require ongoing communication.

The opportunity for remote programming is bidirectional. Server computers, like client computers, can have agents, and a server agent can transport itself to and from a client computer. Imagine, for example, that a client computer makes its graphical user interface accessible to server agents. The client computer might do this, for example, by accepting a form from a server agent, displaying the form to the user, letting the user fill it out, and returning the completed form to the agent. The completed form might instruct a file server's agent to retrieve files meeting specified criteria.

Remote programming is especially well suited to computers that are connected to a network not permanently, but rather only occasionally.

With agents, manufacturers of client software can extend the functionality offered by manufacturers of server software.

Introducing a new rpc-based application requires a business decision on the part of the service provider.

A network using remote programming requires a buying decision on the part of one user. Remote programming therefore makes a network, like a personal computer, a platform.

The Engine

All Telescript engines provide:

  • Runtime type checking with dynamic feature binding

  • Automatic memory management

  • Exception processing

  • Authenticated, unforgeable identity for each process, in the form of an authority

  • Protected references

  • Protection by encapsulation of private properties and features. This forms the basis for object-enforced access controls

  • quotas and process privileges using permits, including control over creation of new processes

  • security-oriented mix-in classes (Copyrighted, Unmoved, Protected, Uncopied)

  • mediated protocols for process rendezvous (for example, entering a place, and Meeting Agents)

With regard to installing bogus classes, the Telescript engine won't admit an agent carrying a class that has the same name as one that's already in the engine, unless it's the same class. In other words, within an engine, class names must be unique.




A place is occupied by Telescript agents. Whereas places give the electronic marketplace its static structure, agents are responsible for its dynamic activity.

A Telescript agent is an independent process. The Telescript environment executes the programs of the various agents that occupy the marketplace in parallel with one another.

Two agents must meet before they can interact. One agent initiates the meeting using meet, an instruction in the Telescript instruction set. The second agent, if present, accepts or declines the meeting.

As a consequence of meet, the agents receive references to one another. The references let them interact as peers.

While in the same place, two agents interact by meeting. While in different places, they interact by communicating.

An agent can travel to several places in succession. It might link trips in this way to obtain several services or to select one from among them. Booking theater tickets, for example, might be only the first task on our user agent's to-do list. The second might be to travel to the florist place and there arrange for a dozen roses to be delivered the day of the theater event.



Telescript places lend structure and consistency to the electronic marketplace.

Each place represents, in the electronic world, an individual or organization -- the place's authority -- in the physical world. Several places may have the same authority. A place's authority is revealed by its telename.



Agents travel using Telescript's go instruction.

The agent need merely present a ticket that identifies its destination. An agent executes go to get from one place to another. After an agent executes go, the next instruction in the agent's program is executed at the agent's destination, not at its source. Thus, Telescript reduces networking to a single program instruction.

If the trip cannot be made (for example, because the means of travel cannot be provided or the trip takes too long), the go instruction fails and the agent handles the exception as it sees fit. However, if the trip succeeds, the agent finds that its next instruction is executed at its destination.

An agent can move from place to place throughout the performance of its procedure because the procedure is written in a language designed to permit this movement.


A meeting lets agents in the same computer call one another's procedures.

Another instruction available to the Telescript programmer is meet, which enables one agent to meet another. The agent presents a petition, which identifies the agent to be met. An agent executes meet whenever it wants assistance. By meeting, the agents receive references to one another that enable them to interact as peers.

The instruction requires a petition, data that specify the agent to be met and the other terms of the meeting, such as the time by which it must begin. If the meeting cannot be arranged (for example, because the agent to be met declines the meeting or arrives too late), the meet instruction fails and the agent handles the exception as it sees fit. However, if the meeting occurs, the two agents are placed in programmatic contact with one another.


Telescript lets two agents in different places make a connection between them. A connection lets agents in different computers communicate.

Connections are often made for the benefit of human users of interactive applications. The agent that travels in search of theater tickets, for example, might send to an agent at home a diagram of the theater showing the seats available. The agent at home might present the floor plan to the user and send to the agent on the road the locations of the seats the user selects.


Every Telescript place or agent has a permit that limits its capabilities in the electronic marketplace.

Because agents move, their permits, like their credentials, are of special concern. An agent's permit is established when the agent is created programmatically, and it is renegotiated whenever the agent travels between regions. The destination region may deny the agent capabilities that it received at birth as long as the agent is in that region.

Two kinds of capability are granted an agent by its permit. One kind is the right to use a certain Telescript instruction.

Another kind of capability is the right to use a particular Telescript resource, but only in a certain amount. An agent is granted, among other things, a maximum lifetime, measured in seconds (e.g., a 5-minute agent); a maximum size, measured in bytes (e.g., a 1K agent); and a maximum overall expenditure of resources, the agent's allowance, measured in teleclicks (e.g., a 50¢agent)

Permits provide a mechanism for limiting resource consumption and controlling the capabilities of executing code. A permit is an object (of the built-in class Permit) whose attributes include, among others:

  • age: maximum age in seconds

  • extent: maximum size in octets

  • priority: maximum priority

  • canCreate: true if new processes can be created

  • canGo: true if the affected code can request the go operation

  • canGrant: true if the permit of other processes can be "increased"

  • canDeny: true if the permit of other processes can be "decreased"

Telescript uses four kinds of permits:

  • native permits are assigned by the process creator

  • local permits can be imposed by a place on an entering agent or on a process created in that place. Local permits only apply in that place

  • regional permits are like local permits but imposed by the engine place. Regional permits only apply within a particular engine or set of engines comprising a region

  • temporary permits, which are imposed on a block of code using the Telescript restrict statement


Agents and places can discern but neither withhold nor falsify their authorities. Anonymity is precluded.

Telescript verifies the authority of an agent whenever it travels from one region of the network to another. A region is a collection of places provided by computers that are all operated by the same authority.

To determine an agent's or place's authority, an agent or place executes the Telescript's name instruction.

The result of the instruction is a telename, data that denote the entity's identity as well as its authority. Identities distinguish agents or places of the same authority.

A place can discern the authority of any agent that attempts to enter it and can arrange to admit only agents of certain authorities.

An agent can discern the authority of any place it visits and can arrange to visit only places of certain authorities.

An agent can discern the authority of any agent with which it meets or to which it connects and can arrange to meet with or connect to only agents of certain authorities.

Telescript provides different ways for identifying the authority and class of the caller (i.e., the requester, or client, from the point of view of the executing code) that are useful in making identity-based access checks. These are obtained directly from the engine in global variables, and include:

  • The current process. An unprotected reference to the process that owns the computation thread that requested the operation.

  • The current owner. An unprotected reference to the process that will own (retain owner references to) any objects created. The owner is usually the current process, but can be temporarily changed, for code executed within an own block, to one's own owner. That is, to the owner of the object that actually supplies the code being executed.

  • The current sponsor. An unprotected reference to the process whose authority will get attached to new process objects, and who will be charged for them. Processes own themselves, so for new process creation, it doesn't make any difference who the current owner is. The engine uses the authority (and permit) of the current sponsor, usually the current process, to determine responsibility for new agents and places.

  • The client. This is the object whose code requested the current operation. The client's owner might be yet another process.

    See An Introduction to Safety and Security in Telescript: Encapsulation and Access Control to see why 4 identities are needed


Telescript protocols operate at two levels. The higher level encompasses the encoding (and decoding) of agents, the lower level their transport.

The Telescript encoding rules explain how an agent -- its program, data, and execution state -- are encoded for transport, and how parts of the agent sometimes are omitted as a performance optimization.

The protocol suite can operate over a wide variety of transport networks, including those based on the TCP/IP protocols of the Internet, the X.25 interface of the telephone companies, or even electronic mail.

Example Use Cases

Electronic Mail

An important enterprise in the electronic marketplace is the electronic postal system, which can be composed of any number of interconnected post offices.

Telescript is a perfect vehicle for the implementation of electronic mail systems.

Following the remote programming paradigm, messages, since they are mobile, are implemented as agents. Mailboxes, since they are stationary, are implemented as places. Each mailbox is occupied by an agent of the mailbox's authority. A message's delivery is a transaction between two agents: the sender's message and the agent attending the recipient's mailbox. The transaction transfers the message's content between the two.

A message is customized by the sender, a mailbox by the receiver.

Booking a Round-trip

Chris can thank one Telescript agent for booking his round-trip flight to Boston, another for monitoring his return flight and notifying him of its delay.

Read the details on How Agents Provide the Experience

Buying a Camera

John is in the market for a camera. He's read the equipment reviews in the photography magazines and Consumer Reports and he's visited the local camera store. He's buying a Canon EOS A2. The only question that remains is, from whom? John poses that question to his personal communicator. In 15 minutes, John has the names, addresses, and phone numbers of the three shops in his area with the lowest prices.

Read the details on Doing Time-Consuming Legwork

Planning an Evening

Mary and Paul have been seeing each other for years. Both lead busy lives. They don't have enough time together. But Mary has seen to it that they're more likely than not to spend Friday evenings together. She's arranged -- using her personal communicator -- that a romantic comedy is selected and ready for viewing on her television each Friday at 7 p.m., that pizza for two is delivered to her door at the same time, and that she and Paul are reminded, earlier in the day, of their evening together and of the movie to be screened for them.

Paul and Mary recognize the need to live well-rounded lives, but their demanding jobs make it difficult. Their personal communicators help them achieve their personal, as well as their professional, objectives. And it's fun.

Read the details on Using Services in Combination

Example Code

A shopping agent, acting for a client, travels to a warehouse place, checks the price of a product of interest to its client, waits if necessary for the price to fall to a client-specified level, and returns, either when the price is at that level or after a client-specified period of time.

CatalogEntry: class = (
     see initialize
     see adjustPrice
     product: String;
     price: Integer; // cents
     lock: Resource;

initialize: op (product: String; price: Integer) = {
  lock = Resource()

adjustPrice: op (percentage: Integer) throws ReferenceProtected = {
  use lock   {
    price = price + (price*percentage).quotient(100)

Warehouse: class (Place, EventProcess) = (
    see initialize
    see live
    see getCatalog
    catalog: Dictionary[String, CatalogEntry];

initialize: op (catalog: owned Dictionary[String, CatalogEntry]) = {

live: sponsored op (cause: Exception|Nil) = {
  loop {
    // await the first day of the month
    time: = Time();
    calendarTime: = time.asCalendarTime();
    calendarTime.month = calendarTime.month + 1; = 1;

    // reduce all prices by 5%
    for product: String in catalog {
      try { catalog[product].adjustPrice(-5) }
      catch KeyInvalid { }

  // make known the price reductions
  *.signalEvent(PriceReduction(), 'occupants)


See The Electronic Shopper for more code


Found it interesting?

Subscribe to instadeq's monthly newsletter to stay updated